Need help on STM32F207 errata position 2.3.2 (I2C)

[mmensch]

Posted on February 29, 2016 at 11:01

Hello,

 we are using STM32F207ZGT6J with rev code X and we are in trouble with I2C communication. It runs fine for hours with tens of messages per second and then suddenly it doesn't generate a start condition anymore. After hours of testing I finally came to take a look at errata sheet and found this:

.ExternalClassD82D6804970A46C480A13D14A722393F {;} .ExternalClassD82D6804970A46C480A13D14A722393F li {list-style:none;margin:0;} .ExternalClassD82D6804970A46C480A13D14A722393F p {margin:0;} .ExternalClassD82D6804970A46C480A13D14A722393F span.foldopened, .ExternalClassD82D6804970A46C480A13D14A722393F span.foldclosed {font-size:xx-small;border-width:1;font-family:monospace;padding:0em 0.25em 0em 0.25em;background:#e0e0e0;cursor:pointer;} .ExternalClassD82D6804970A46C480A13D14A722393F span.foldopened {color:white;visibility:visible;} .ExternalClassD82D6804970A46C480A13D14A722393F span.foldclosed {color:#666666;visibility:hidden;} .ExternalClassD82D6804970A46C480A13D14A722393F span.foldspecial {color:#666666;font-size:xx-small;border-style:none solid solid none;border-color:#CCCCCC;border-width:1;font-family:sans-serif;padding:0em 0.1em 0em 0.1em;background:#e0e0e0;cursor:pointer;} .ExternalClassD82D6804970A46C480A13D14A722393F span.l {color:red;font-weight:bold;} .ExternalClassD82D6804970A46C480A13D14A722393F a.mapnode:link, .ExternalClassD82D6804970A46C480A13D14A722393F a.mapnode:visited, .ExternalClassD82D6804970A46C480A13D14A722393F a.mapnode:active, .ExternalClassD82D6804970A46C480A13D14A722393F a.mapnode:hover {text-decoration:none;color:black;} .ExternalClassD82D6804970A46C480A13D14A722393F a.mapnode:hover {background:#eeeee0;} 2.3.2  Start cannot be generated after a misplaced Stop

Description

If a master generates a misplaced Stop on the bus (bus error), the peripheral cannot generate a Start anymore.

Workaround

In the I²C standard, it is allowed to send a Stop only at the end of the full byte (8 bits + acknowledge), so this scenario is not allowed. Other derived protocols like CBUS allow it, but they are not supported by the I²C peripheral.

A software workaround consists in asserting the software reset using the SWRST bit in the I2C_CR1 control register.

For me there are a number of questions on this text:

- How can there be a misplaced stop condition in master mode? Stop conditions are placed by hardware so they should be in place always or never. (We have a single master system with this F207 being the master)

- How can I determine that this situation occured?

- What exactly is reset when using SWRST? Is it the same effect as using RCC_APB1RSTR_I2C1RST ?

- Are there more recent revisions that don't have this error? Or other STM32-controllers that are pin compatible to STM32F207?

Thanks a lot for any help

Martin

[Amel NASRI]

Posted on February 29, 2016 at 15:13

Hi Mr_M_from_G,

I would like to provide you more details regarding the errata ''Start cannot be generated after a misplaced Stop'':

The description of this limitation is: If a master generates a misplaced Stop on the bus (bus error) while the STM32 I2C peripheral tries to switch to master mode by setting the START bit, the Start condition is not properly generated.

This limitation occurs when following conditions are applicable:

  1- set START bit while BUSY=1 and MSL=0

  2- and current master generates a STOP on the bus

If you have these conditions, the workaround can be applied. Otherwise, you have to look deeper to know the root cause of the problem you are facing.

Please note that if any limitation is fixed, this will be mentioned in the errata sheet.

-Mayla-

[flyer31]

Posted on February 29, 2016 at 16:28

I assume your STM32 chip is bus master? This is the typical behaviour if one of your slaves on a read by some accident misses an SCL and then the last data bit is zero - in this case this slave will keep the SDA line pulled down and wait for another SCL which is not coming: The STM32 master in such a case cannot generate the start condition and will switch back to slave mode - in this case the bus is blocked.

To release such a blocking, unfortunately you have to use a quite cumbersome procedure: Switch the SCL pin back to manual mode (remove the alternate setting), then pulse out 8-9 SCL pulses ''manually'' ... then switch SCL pin back to I2C mode and continue with standard I2C. It is the pity that there is no other solution, as this is a quite cumbersome approach ...

[mmensch]

Posted on March 02, 2016 at 09:46

Hello Mayla,

thank you for these closer details.

I reviewed my code and there is a certain chance that I initiate a new start bit while a communication is still ongoing. I now check MSL and BUSY to be clear before I set START. Unfortunately this has another bad effect. As I need to read SR2 to get MSL and BUSY there is also a chance to clear ADDR before the isr is executed. It seems that this happens here with my system because communication hangs after the device address is on the bus.

Now I would like to ask if there is a way to determine that a communication is completely finished including stop condition was on the bus? Either inside the isr ie. there is a trigger flag for a generated stop condition also in master mode or outside isr ie I can poll for this situation unsychronized with the isr without any danger for race conditions? I really read ref manuals and application notes up and down but I couldn't find any flow diagram or so that is addressing this need.

Any help is welcome

Thank you

Martin