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

As noted a general call cannot be a read. However by not reflecting the R/W bit properly the designer has to check the address first and handle the GC condition rather than check the R/W first (or simultaneously with the address), so it comes down to the order in which things are done as to whether it works.  It's a bug IMO if the  documentation implies R/W should always be reflected correctly and it isn't.

Thanks for pointing this out!

Mark.

I appreciate the expert comments on this issue...and have a few additional thoughts...

1)  I understand that a GC can only be a write and agree that the MSSP module behavior can be worked around with some additional gymnastics on the part of the programmer......BUT you have to know what to expect from SSPxSTAT!       

2)  I do not think that the RnW bit behavior would be addressed by the I2C specification since the spec only covers the format of the data on the wire.   The behavior of the various status register bits in microcontrollers capable of implementing the protocol are not, I think,  within the scope of the I2C protocol spec.   This is no doubt why every micro vendor seems to use a slightly different way of having the I2C subsystem signal protocol events to the application software.

3) It is interesting that the I2C module (not ssp or mssp) on the 16 bit parts apparently provides an additional GCALL status register bit which could potentially reduce the complexity of the ISR a bit.

Regards,
Jim

Thanks for sticking with me on this one!   I appreciate the clarification.   I used the LPC17xx only because its the part that I'm currently using on another project (...we tried really hard to use a PIC32 but it just didn't have the I/O for the job!).    

I'm still not following the part where you say "....return different status codes for GC and AC, as did MSSP".      Which bit in SSPxSTAT of the MSSP indicates that the byte you just received was a GC vs AC?

Jim

This seems like the "...its not a bug its a feature argument".    I just don't see any scenario where the MSSP behavior wrt RnW  and GC is advantageous/useful/intuitive. 

Thanks again to all the experts who posted on this thread!

Jim

I discovered the same issue after days of searching and debugging.

The DS sucks in that regards as I studied it over and over and was none the wiser.

PIC18F44K22 and PIC18F43K20.

Even the Microchip app notes on I2C do not mention this AND they look at the RW# bit before decoding the addres.