cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F1 I2C start failure

clark2
Associate II
Posted on February 16, 2016 at 15:57

I am working with an STM32F103RC and trying to develop an I2C master application.  Currently the I2C bus is populated with only this master and an MCP23017 slave.

In my most recent test run the program eventually ended up in a locked loop waiting for SB to set in SR1.  The START bit is set, PE is set, the peripheral clock is enabled, both signals are in the passive state... how is this possible?  Is there a known (yet unpublished) bug in this peripheral which would allow this condition?  The obvious answer is ''yes'' unless I'm missing something.

I realize the prudent thing to do would be to have a timeout test on this wait, but why?

30 REPLIES 30
Posted on February 16, 2016 at 16:20

> The START bit is set, PE is set, the peripheral clock is enabled, both signals are in the passive state... how is this possible?  Is there a known (yet unpublished) bug in this peripheral which would allow this condition?  The obvious answer is ''yes'' unless I'm missing something.

The obvious... and usually wrong, answer.

What is the state of I2C_SR2.MSL? I guess, it's 0. What might have happened is loss of arbitration (the STM32 I2C is multimaster-capable), which would then be indicated by I2C_SR1.ARLO; the I2C is then waiting for the other master to issue clocks. Now I am not going to guess why did this happen, once there's only one master - there may be some issue with your hardware, for example.

JW

Amel NASRI
ST Employee
Posted on February 16, 2016 at 16:23

Hi leach.clark,

Could you please provide more details on the firmware you are using and if possible share minimum relevant code?

Are you using interrupt mode? Are there other interrupts in your application?

-Mayla-

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

clark2
Associate II
Posted on February 16, 2016 at 16:33

No arbitration loss is indicated.  SR1 and SR2 are all zeros.  I have enabled the error interrupt in order to catch such conditions.  I would expect MSL to be 0 until the address is transmitted...

Posted on February 16, 2016 at 16:46

It's hummm then... I did not encounter this in my rather trivial polling incarnation of I2C ''handler'' with no timeout just a trivial error handler based on the error-indicating flags in I2C_SR1. I don't use a 'F1xx, but I don't believe that makes any significant difference.

You might want to answer Mayla's questions, above.

JW

Posted on February 16, 2016 at 17:28

In which loop does the execution stall, in the very first check of SB bit, or later on? Can you see any activity on SDA or SCL with an oscilloscope?

As Radoslaw told in an other thread, using the symbols from the system header instead of ''magic numbers'' increases code readibility.

JW

clark2
Associate II
Posted on February 16, 2016 at 17:43

It stalls at line 126 of i2c.c

I just want to verify that the peripheral works as expected.

clark2
Associate II
Posted on February 16, 2016 at 17:46

The program runs fine for hours.  Bus activity is verified with a logic analyzer.

clark2
Associate II
Posted on February 16, 2016 at 17:54

0690X00000605M6QAI.png