Author Topic: 24LC512 i2c hangs (rarely)  (Read 2044 times)

eurodude

  • Newbie
  • *
  • Posts: 3
    • View Profile
24LC512 i2c hangs (rarely)
« on: February 10, 2013, 01:13:57 AM »
Hello,

I am working with an SBC65EC connected through a PICkit 3 to MPLAB.  On rare occasions (say 1 in every 50 runs) I experience a problem where the code hangs in i2cGetByte at this line:

Code: [Select]
while ( !SSPSTAT_BF ) FAST_USER_PROCESS();  // wait until byte received
It got here because fseeBeginRead() failed while trying to read the FAT on the eeprom, and the subsequent call to XEEEndRead() is not able to complete, hanging in its call to i2cGetByte().  The fseeBeginRead() more specifically fails in its call to XeeSetAddr(), which experiences a bus collision when attempting to issue the i2c START.  After the failure to START, we are not properly set up to receive a byte and no condition sets the SSPSTAT_BF flag, resulting in the hang at the above line.

Tracing the problem further, I determined that the reason for the bus collision seems to be that when the START is attempted, the SCL1 line (probed at the eeprom's SCL pin) is high as it should be, but the SDA1 line (probed at the eeprom's SDA pin) is already low.

When this problem occurs, it persist across any soft resets of the processor, until the device is actually power cycled.  I've seen this with two different SBC65EC's.

Does anyone know how this can happen?  If the 24LC512 is holding SCL low and refusing to release it, why?  I have made sure that no other code controls the RC3 and RC4 lines, and the eeprom i2c has exclusive use of them.  And I have made no changes to the i2c, fsee and xeeprom code.

Any help with this would be appreciated very much.  Thanks.
« Last Edit: February 10, 2013, 10:39:35 AM by eurodude »

eurodude

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: 24LC512 i2c hangs (rarely)
« Reply #1 on: February 10, 2013, 01:14:04 PM »
I have proven that it is indeed the 24LC512 that was holding SDA low (by desocketing it *very carefully* without removing power - something I would never recommend, but my options were few in this case!)

After further investigation, it seems that the only way this is likely to happen is if an i2c sequential read fails to terminate with a NACK instead of an ACK.  Examining more closely, I can see no scenario that would cause the code to do this.

However, I can most definitely see a scenario in my use of the PICkit 3 that would.  If I happen to hit a breakpoint while a file read is in progress, and then I do a soft processor reset (which I often do) then i2c would be left in this bad state.  It also explains the infrequency of the issue.

So for anyone interested, this might serve as a useful heads up on a subtle pitfall of ICD or PICkit debugging!