2010-10-21 09:53 AM
I2C - Unknown event interrupt
2011-05-17 05:12 AM
In the meantime i solved the unknown event problem. Seems to have something to do with the debugger connection. Without debugger no unknown events anymore but the sporadic bus failure is still there.
I now measured the bus and found some strange spikes on the SDA line after each 9th bit. I attached an image of the spike. I tested the communication on two different boards with different I2C slaves. But the spikes are always there. I also replaced my I2C code with the AN2824 code example but the result is still the same. Any suggestions ?2011-05-17 05:12 AM
Not sure if you are seeing what I ran into but the symptoms seem similar - when I was generating a restart condition on the bus, I would get the interrupt but the status register showed no source - this was 100% reproducable.
It turned out that if I added a small delay, the start flag propagated into the status register and everything was fine. I tried changing the ratio of the I2C clock and main processor clock and found that this affected how long it took for the start flag to propagate. Here is the specific code I use to get around this: case I2C_ADDRRPT: // the interrupt fires before the I2C status register is updated with the // status bit which hangs up this state. // wait for I2C block to propagate start bit to I2C status register for (ulTemp = 0; ulTemp < 20; ulTemp++) { vDelayUS(1); if (I2C1->SR1 & I2C_SR1_SB) break; } I then write the slave address to the data register which clears start bit in the status register.2011-05-17 05:12 AM
I have the exact problem, my solution is that whenever this erorr occures I do the same I2C operation again.
2011-05-17 05:12 AM
Do you have also these spikes on the SDA line ? How do you trigger on the failure ? Or do you repeat the I2C command whenver it fails previously ?
2011-05-17 05:12 AM
Yes, sometimes the SDA line spikes ... and the I2C registers an event that not supposed to happen and I2C driver gets stuck waiting for the real event.
I timeout the event if the timeout reached I return FAIL ... and from the main loop if I2C operation Failed it repeats the I2C command again ...
2011-05-17 05:12 AM
Ok nice to hear I am not alone :) The strange thing is that the Spike is on
every
9th bit.2011-05-17 05:12 AM
I think the spike the bus master releasing the SDA line so that the slave can drive it to acknowledge the transfer.
2011-05-17 05:12 AM
I think the spike the bus master releasing the SDA line so that the slave can drive it to acknowledge the transfer.
Grin. Basically exposing the propagation delay in the bus, and the latency of the slave device. They are probably also ramming the port (0 states) with the 50 MHz driver, instead of the 2 or 5 MHz ones that might be more appropriate.2011-05-17 05:12 AM