I2C hangs in power board firmware (fixed)

[Jeremy Morse]

Hi,

While doing some work on the power board firmware I observed some
unpleasant behaviour when reading current/voltage over USB. Specifically
some measurements were read as zero, and on other occasions the readings
latched and were no longer updated. Both of these are bad things. I
think I've now fixed this [0], but explaining it is good, and you might
need to be aware this can happen with the v0 power board firmware.

Both USB and i2c on the power board use polling; early on I encountered
some grief where USB transactions would fail if i2c transactions were
being made. Possibly because the i2c code would block for ~160uS. I
moved the i2c stuff to a non-blocking FSM, and that problem went away.
At the time I figured that any timing issues where the i2c master didn't
have data yet would be solved with clock-stretching.

However, the failure modes mentioned above then presented themselves,
although only when one has a loop continuously reading the
voltage/current readings from the power board. Inspection showed that
the zero-readings were caused by the i2c peripheral signalling 'BERR'
(bus error), and the hang by it reporting 'ARLO' (arbitration lost).

Further prodding revealed that if the i2c state machine isn't serviced
between reading the 1st and 2nd byte of a current/voltage sample, then
the 2nd byte gets an i2c ACK instead of a NACK. It seems the clock
stretching still occurs, but the peripheral has by that point put itself
into an invalid state, as it expects another byte from the slave.

Further reading of the manual [1] from page 753 to page 756 shows that
there's a specific sequence / set of bits that have to be set to receive
two bytes in master mode when polling. This sequence ensures that, from
a point in time when the clock is still stretched, the peripheral reads
two bytes and nack's the 2nd one with no further servicing. I've
implemented this [0] and haven't seen any of the errors mentioned above
since, having polled the voltage/current readings on the power board at
full pelt for an hour now.

I think the impact of this fault is low -- you have to be seriously
thrashing the power board to make it happen. The hardware UVLO should
kick in to stop the battery being fully discharged. The most risky thing
is that in the case of an i2c hang, the power board keeps ticking but
the software current limit is effectively disabled.

[0] 25918c43
[1]
http://www.st.com/web/en/resource/technical/document/reference_manual/CD00171190.pdf

--
Thanks,
Jeremy