• AVR Freaks

MSSP I2C Slave GC - Be Warned!

Author
jiml
Starting Member
  • Total Posts : 38
  • Reward points : 0
  • Joined: 2003/11/07 12:38:42
  • Status: offline
2011/08/13 05:15:27 (permalink)
0

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
#1

11 Replies Related Threads

    BitWise
    Super Member
    • Total Posts : 1238
    • Reward points : 0
    • Joined: 2004/11/09 13:24:20
    • Location: UK
    • Status: offline
    Re:MSSP I2C Slave GC - Be Warned! 2011/08/13 06:30:32 (permalink)
    0
    An I2C operation with the GC address can only be a write to the slaves - reading from multiple slaves simultaneously doesn't make sense.

    So if you check the value of the address received when the slave interrupt occurs then you can determine if you need to look at the R/W bit.


    if (address == GC)
      write to multiple slaves
    else
      if (r/w == r)
        read from this slave
      else
        write to this slave

    post edited by BitWise - 2011/08/13 06:32:59

    Throughout your life advance daily, becoming more skillful than yesterday, more skillful than today. This is never-ending.

    Yamamoto Tsunetomo (1659-1719)
    #2
    markp
    Super Member
    • Total Posts : 397
    • Reward points : 0
    • Joined: 2006/01/26 13:54:56
    • Location: 0
    • Status: offline
    Re:MSSP I2C Slave GC - Be Warned! 2011/08/13 13:25:52 (permalink)
    +1 (1)
    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.
    #3
    markp
    Super Member
    • Total Posts : 397
    • Reward points : 0
    • Joined: 2006/01/26 13:54:56
    • Location: 0
    • Status: offline
    Re:MSSP I2C Slave GC - Be Warned! 2011/08/14 01:39:07 (permalink)
    0
    I agree. In fact having a global address that could be read simultaneously could be quite useful to an embedded designer. For example 8 slaves slave could have each have an ADC which is triggered with a single write to address 0x00, and then a single read from address 0x00 to get all 8 conversion complete status bits back in one hit. It is more consistent and more flexible IMO.
    #4
    jiml
    Starting Member
    • Total Posts : 38
    • Reward points : 0
    • Joined: 2003/11/07 12:38:42
    • Status: offline
    Re:MSSP I2C Slave GC - Be Warned! 2011/08/15 15:25:48 (permalink)
    0
    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

    #5
    jiml
    Starting Member
    • Total Posts : 38
    • Reward points : 0
    • Joined: 2003/11/07 12:38:42
    • Status: offline
    Re:MSSP I2C Slave GC - Be Warned! 2011/08/15 16:42:18 (permalink)
    0
    fdan00...thanks for the NXP reference.   I checked the LPC17xx users manual (UM10360.pdf) and come to a different conclusion.    In table 400 the relevant states are shown for an I2C slave receiver and there are specific and unique codes (0x90 and 0x98)  assigned for the case of reception of a data byte after being addressed via GC.    These are distinct from states (0x80 and 0x88) which are related to reception of a data byte after being addressed by (one of three!) configurable unique slave addresses.     None of these state codes overlap with those defined for the Slave transmitter (Table 401) so it seems clear (to me!) that the I2CSTAT register on these processors must correctly keep track of both whether the transaction is a read or write AND whether it was initiated by a GC or by unique slave address.

    This,  I think,  a contrast to the MSSP which does not correctly maintain the state of the RnW bit during a GC transaction.    Instead the RnW bit is simply carried over from the previous non-GC transaction.   How is this consistent w/ the NXP implementation?

    Cheers,
    Jim
     
    #6
    jiml
    Starting Member
    • Total Posts : 38
    • Reward points : 0
    • Joined: 2003/11/07 12:38:42
    • Status: offline
    Re:MSSP I2C Slave GC - Be Warned! 2011/08/15 18:17:31 (permalink)
    0
    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

    #7
    jiml
    Starting Member
    • Total Posts : 38
    • Reward points : 0
    • Joined: 2003/11/07 12:38:42
    • Status: offline
    Re:MSSP I2C Slave GC - Be Warned! 2011/08/16 04:15:48 (permalink)
    0
    Sorry I missed your 2nd post from last night...

    "(I would have had it reset)" -  Yes!  This seems like it would work fine.  Maybe have the RnW always reset on reception of a Start condition.

    "...but it is not without merit." - Hmmmm.   Can you suggest a use-case where the MSSP behavior wrt RnW and GCs is beneficial?

    Cheers,
    Jim

    #8
    jiml
    Starting Member
    • Total Posts : 38
    • Reward points : 0
    • Joined: 2003/11/07 12:38:42
    • Status: offline
    Re:MSSP I2C Slave GC - Be Warned! 2011/08/16 18:18:42 (permalink)
    0
    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

    #9
    dhenry
    Super Member
    • Total Posts : 4994
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Location: Colorado
    • Status: offline
    Re:MSSP I2C Slave GC - Be Warned! 2011/08/16 21:13:34 (permalink)
    +1 (1)
    Recorded for search: fdan00 expert
    #10
    user2x
    Super Member
    • Total Posts : 219
    • Reward points : 0
    • Joined: 2011/02/10 20:43:36
    • Location: 0
    • Status: offline
    Re:MSSP I2C Slave GC - Be Warned! 2017/06/21 13:58:13 (permalink)
    0
    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.
    #11
    Mysil
    Super Member
    • Total Posts : 3321
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: offline
    Re:MSSP I2C Slave GC - Be Warned! 2017/06/21 15:30:15 (permalink)
    +1 (1)
    Hi,
    I do not think LPC17xx is a part of I2C specification. Even if it is a product of the same company that maintain the I2C specification, it isn't nessesarily a reference implementation.
     
    Whether the behaviour of the MSSP is by design, or by accident, I do not know, but I am not surprised.
    The SSP and MSSP used in 8 bit PIC devices try to do a little of everything, and was designed in a environment where SFR register bits is a scarce resource, reflecting in how bits are reused for different purpose in different modes.
    My own slave code test the D_nA bit first, so I think it may skid by on this one.
     
    Comparing the MSSP with a 32 bit device designed some 10 years later, is hardly fair.
    That said, one may wonder if they should have figured out how the hardware work in the mean time,
    but documenting such details in a way thet is easily found when needed, without cluttering up descriptions with details that overwhelm every reader, will be a challenge in any case.
     
    (Even finding back to what I have written three years ago, in Microchip Forum, or in my own computer, is nearly impossible at times.)
     
    Regards,
       Mysil
    #12
    Jump to:
    © 2019 APG vNext Commercial Version 4.5