STM32F1 I2C start failure

[clark2]

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?

[waclawek.jan]

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]

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-

[clark2]

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...

[waclawek.jan]

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

[clark2]

Posted on February 16, 2016 at 16:48

Here is the source code. In this version, I am using DMA for transfers > 1 byte. The only interrupt in use is the ITERREN. I would like to use DMA and interrupts to implement a non-blocking driver, but I have encountered issues with that and I'm just trying to get something that will stay running for the moment...

________________ Attachments : i2c.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0tX&d=%2Fa%2F0X0000000bfA%2FtvGgE_JjpQgvyva7jsDgMPX6dZ74REm.Rq.Pe.SID7s&asPdf=falsei2c.h : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0tS&d=%2Fa%2F0X0000000bfB%2FUegMYwbT_l6zFii.f8l6TbF2gzfnRpLJWZvaPLQ7evo&asPdf=falsemain.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0tN&d=%2Fa%2F0X0000000bf9%2FkvFufCb67gxph8s69q4soizKVz2hEfKvynBS4TqG6LY&asPdf=falsemem_access.h : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0tI&d=%2Fa%2F0X0000000bf8%2FKYedscfmz3EXZ7na5kWVJ9peRR05FJUJrfVHLSownVA&asPdf=false

[waclawek.jan]

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]

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]

Posted on February 16, 2016 at 17:46

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

[clark2]

Posted on February 16, 2016 at 17:54