MSSP I2C Slave GC - Be Warned!
Friends,
With the help of Microchip Tech Support I have finally gotten to the bottom of a vexing issue which may impact a limited subset of I2C users. I believe that this issue will affect all parts which use the MSSP module ...but may not be applicable to 16 bit parts which have an "I2C" module.
I encountered this issue while developing a multiple I2C slave/peripheral system where general calls (GC) are used by the master to issue commands to all modules in parallel and then unique addressed commands are used to read status from the slaves one at a time. During testing I found that doing only GC's works fine, doing only slave specific reads works fine, but when doing a mixture of GCs with slave specific reads the system behaved as if the GC writes were not received.
The nut of the issue is that for some reason the MSSP module is designed such that reception of a GC address byte DOES NOT UPDATE RnW BIT of SSPXSTAT. Instead the prior state of the RnW bit from the previous I2C transaction is preserved. This means that your I2C interrupt handling code must not rely exclusively on the state of the RnW bit in determining how to correctly handle an inbound packet.
It seems this behavior of the MSSP module is not widely known. Trolling multiple forums did not turn up anything. My local FAE and several tiers of tech. support and engineering were also apparently unaware. Eventually support got me to the "MSSP guru" who indicated that this behavior is designed into the MSSP module. As explained in the datasheet the RnW bit is only valid from an"address match" up until the next stop condition on the bus AND (not explained in the datasheet) reception of a GC NOT considered an "address match" .....even though one of the features of the MSSP module listed in the MSSP summary section is "- GC address matching".
Is it a Bug or a Feature?
Since reception of a GC apparently is enough of an address match to cause an interrupt, change the state of the DnA bit in SSPxSTAT, and update SSPBUF I really consider this a bug. Since the way that RnW behaves was designed into the MSSP, Microchip does not consider this a bug and thus the issue does not appear in the errata sheets for the affected parts.
Workaround:
With some additional code in the MSSP interrupt service routine you can compensate for this issue (...once you know it exists!). The basic approach is to....
a) Recognize the reception of a GC address (0x00) and remember that a GC is being handled up until the next stop condition on the bus.
b) For the duration of the GC I2C transaction (ie up until the next stop) ignore the state of the RnW bit in SSPxSTAT and instead behave as if RnW is zero. This is justified since GC cannot be a read.
Hope this saves someone else a lot of grief....
Cheers,
Jim
post edited by jiml - 2011/08/13 05:18:50