RT1062 I2C Pin Low Flag Issue

[nick002025]

I am running into some issues with the non blocking FreeRTOS driver in MCUXpresso with I2C when the I2C line is subjected to a noisy environment. 

The interrupt is constantly firing with stop bit detect flag set but the library state machine is in kSendCommandState state so the interrupt flag is never cleared. 

In this state, the SCL is held low by a end device but I cannot process a bus reset while stuck in the interrupt.

I am trying to implement the PLTF, Pin Low Timeout Flag but it never transitions to a 1. I have the MCFGR3.PINLOW value set to approximately 100uS. I do not see any other requirements for this feature in the reference manual, but I could be missing it. Any ideas?

[kerryzhou]

Hi @nick002025 ,

     Please help to check, whether your I2C wire have the external pull-up resistor?

     Do you also check the I2C wave in your noisy environment. It may break the normal I2C wave, then it cause the issues in the code, when your code find issues, you can sendout STOP and clear the related error flags.

   I think your hardware should make sure your I2C wave is normal, you need to use the wire which can avoid the noise.

  Wish it helps you!

Best Regards,

Kerry

[nick002025]

Yes, the I2C bus has appropriate pull-up resistors. In normal operation, the shape of the waveform on both SDA and SCL are fine. In a noisy environment (simulated by toggling AC Relay near I2C line), there are numerous noise spikes on both lines which cause multiple issues on both end devices and master devices. 

What i described in the initial post is a problem though. When you are trapped in interrupt calls one after another, app code cannot detect the error and send a stop bit, or extra bit-banged clock pulses. The problem is the state machine implementation in the i2c driver not being robust enough. Each state should have a maximum timeout which prevents the constant interrupt issue.

[kerryzhou]

Hi @nick002025 ，

    Thanks for your information.

    So, if the hardware can't avoid the noisy, you want the software side to fix it, eg, do stop, right?

   Yes, the SDK code is just the demo, and is used for the normal situation, maybe can't meet your robust requirement. So, can you try to add some error detect code in your application code, then when you trapped in the interrupt, you can check the related error flag, and clean the flags, and send out a stop directly? Just for your own situation, give the related workaround code.

Wish it helps you!

Best Regards,

Kerry