Again I2C baremetal K64

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Again I2C baremetal K64

Jump to solution
1,221 Views
luimarma
Contributor III

I am developing a baremetal application for K64 processor using the drivers provided by SDK 2.x, the I2C driver is latest version of fsl_i2c (2.0.7).

I have a problem often reported in this forum, and I found the same solution replied all over the time, but I do not know how to implement it when the driver is already in use.

In some installation environments the i2c bus becomes weak and time to time causes that a slave looses the arbitration and hangs the bus with the I2C bus remainig busy. This can only be solved by power cycling the system.

Many people reported that a solution to this is to cycle up and down the SCL line until the slave reset and releases the bus.

I believe that this is not inplemented in the driver and I do not know how to switch to GPIO the SCL and SDA line and switch it back to the diriver control after the bus is released.

Anyone can help with some guiding?

Thanks in advance,

Lu

1 Solution
1,030 Views
FelipeGarcia
NXP Employee
NXP Employee

Hi Lu,

 

As you mention If the data line (SDA) is stuck LOW, the master should send nine clock pulses. The device that held the bus LOW should release it sometime within those nine clocks. If not, then use the HW reset or cycle power to clear the bus.

 

What you need to do is to switch SCL and SDA lines to GPIO output and input respectively. To do this you will need to change PORTx_PCRn(MUX) and GPIOx_PDDR. Then you generate clock cycles at the same frequency as is normally used.

 

Please check the below community threads, I believe they can be helpful for you.

I2C device dead-lock recovery

https://community.nxp.com/thread/394582 

Have a great day,
Felipe

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

View solution in original post

2 Replies
1,031 Views
FelipeGarcia
NXP Employee
NXP Employee

Hi Lu,

 

As you mention If the data line (SDA) is stuck LOW, the master should send nine clock pulses. The device that held the bus LOW should release it sometime within those nine clocks. If not, then use the HW reset or cycle power to clear the bus.

 

What you need to do is to switch SCL and SDA lines to GPIO output and input respectively. To do this you will need to change PORTx_PCRn(MUX) and GPIOx_PDDR. Then you generate clock cycles at the same frequency as is normally used.

 

Please check the below community threads, I believe they can be helpful for you.

I2C device dead-lock recovery

https://community.nxp.com/thread/394582 

Have a great day,
Felipe

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

1,030 Views
luimarma
Contributor III

First of all thanks for your reply and sorry not to get back to this matter until now, but as the problem does not appear all the time I have had to check and recheck a lot.

I have followed your advice and also reviewed again the mentioned posts. For me the key point was to setup the PORTx_PCRn(MUX) and GPIOx_PDDR for GPIO and  after the bus release set it back for I2C.

Now I got this working, the only thing that makes me wonder is why sometimes even I pulse the CLK line the bus is not released by the slave. In this situation it does not care if I pulse it 9 or 200 times it will just not release it, but if I retry the I2C command (what obviousely takes me to the same I2C_BUSY situation) then try to release again with the CLK pulses, then it gets released after 8 extra commands, and always after the second pulse.

Any idea about why is this happening that can lead me to a more predictable solution? 

Thanks,

Lu

0 Kudos