i2c slave receiver data not acked sometimes

tom16 · ‎2009-07-27

Posted on July 28, 2009 at 08:26

tom16 · ‎2011-05-17

Posted on May 17, 2011 at 13:18

I'm experiencing a real mind bogging bug in my I2C routines, the situation is this:

- uP = STM32F103RBT6 rev Z (LQF64)

- Using Raisonance/GCC build tools

- uP using USART0, USART1, I2C1, I2C2, all using interrupts

- I2C interface with the error has highest interrupt priority ( group 0, subgroup 0 )

- I2C Works flawlessly when running in master mode

- When running in slave mode, sometimes the first databyte is not acked by the STM, as a result the whole message is discarded. The address byte is always acked ok, no calls to I2C_AcknowledgeConfig after that.

- My scope says there is nothing wrong with the electrical connection, no glitches or anything. Pullup is 4k7.

- Because of the many posts with people having troubles with the I2C interface on the STM32, rewrote the slave code to use DMA. Alas, the problem remained.

The really annoying thing is, that the problem seems to change( to the better or worse ) with each testbuild i run. It all suggests it is some kind of timing bug, but i cant find what causes the error and am at this point out of options.

- Has anyone experienced the same kind of error ?

- Is there anything that could be interfering with the generation of the ACK bit by the controller, apart from the ACK flag in I2C_CR1 ( even when using DMA ) ?

A bit of info to go with the scope images:

- The first message is me sending a request in master mode to the peer ( message 0x08 0x10 )

- The second is me receiving an answer from the peer in slave mode ( message 0x09 0x11 0x01 )

As stated, the communication always breaks down ( when it does ) after the first databyte the peer sends because of the STM32 not ACK'ING it.

tom16 · ‎2011-05-17

Posted on May 17, 2011 at 13:18

Ok, after yet some more debugging it now seems i solved my own bug *crosses fingers*.

The problem was that i had configured the second I2C interface in the same priority group, but with a lower sub priority.

Due to my limited knowledge of the NVIC however, i did not realize that there is a real difference between priority and subgroup as the latter does not preempt an interrupt already in progress which is in the same priority group. ( Am i correct? )

Anyway, even when using DMA on the first I2C interface with transfer complete interrupt on the highest priority does not solve this problem. I suppose this is because the DMA controller also uses the I2C interrupt to determine when it has to transfer a new data byte to RAM. ( And thus needs this interrupt to be on a higher/the highest priority also ) ( Am i correct? )