cancel
Showing results for 
Search instead for 
Did you mean: 

I2C master glitching following long read

jpnorair2
Associate II
Posted on July 18, 2013 at 18:22

Hello: I've noticed a long list of grievances regarding the I2C macrocell in the STM32.  I think I have a new and different one.  I'm using an STM32L151.

Over the last week I have gotten the STM32L I2C mostly working by implementing everything just-so, and also adding a lot of fault-tolerance and retry features into the driver.  There is still one issue.  After I do a long read from the device, in this case it is roughly 1000 bytes, the I2C macrocell on the STM32L gets glitchy.  Without the long-read operation, there is no glitching.

The glitch that occurs appears to be in the I2C state machine itself.  The TXE and BTF flags will not flip reliably or according to the specification.  Instead, the Start Flag (SB) will flip after the address byte is transferred.  Even if I manually disable the Start operation in CR1, the Start Flag will flip.  During this interrupt storm, sometimes TXE will mysteriously go high after freezing the bus on a breakpoint -- but not before.

I'm going to attempt to workaround the problem by resetting via SWRST in CR1 after any long transfer, and maybe this will be sufficient.  Nonetheless, I felt I should report this, because maybe someone else has a better answer.  To me, it looks like an erratum of the I2C macrocell.

#i2c
1 REPLY 1
jpnorair2
Associate II
Posted on July 24, 2013 at 00:11

The successful workaround was to insert a delay slot after the long transfer.  The length of the required delay slot seems to be proportional to the amount of data transferred, but I have not yet figured-out the exact relationship.  I am also not certain if the STM32L is at fault, or if it is the slave device.  I will investigate further.