Post by thread:[PIC]: Warning, IIC bug

There is a small problem in Microchip's current implementation of the MSSP module. The master reads the ACK bit on the wrong (rising) edge of the clock line, thereby causing a race condition. The slave can react to the rising edge of clock and release the data line before the master reads the data line. This causes the master to read the ACK bit as a NACK. The work around is to make the RC time constant of the data line longer than that of the clock line. This causes the data line to hold its state for a short time after it is realease by the slave. I discovered this when IIC communication between two PICs always worked when either was replaced by the emulator, but didn't work when both were real chips. I eventually figured out that this was due to the extra capacitance the emulator provided on the data line. The system also worked with real chips when a scope probe was attached to the data line. At first I experimented with a 22pF cap on the data line, but found one board that was marginal at that value. All the boards I had (about a dozen) worked with 47pF on the data line, but there is no guarantee that this value would cover all cases. I eventually decided to use 220pF on the data line and ran the IIC bus at 100KHz bit rate and 2.5K ohm pullups. I feel very comfortable that this will work in all the production units. This also means that the MSSP module is probably not reliable in master mode at 1MHz. At that speed, the required time delay is such a large portion of the overall bit time that other problems will likely result. I personally consider 400KHz now the upper limit of the MSSP module in master mode. And yes, Microchip has acknowledged this problem and will try to fix it in future versions of the MSSC module. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, spam_OUTolinTakeThisOuTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Olin Lathrop wrote: >There is a small problem in Microchip's current implementation of the MSSP >module. The master reads the ACK bit on the wrong (rising) edge of the >clock line, thereby causing a race condition. The slave can react to the >rising edge of clock and release the data line before the master reads the >data line. This causes the master to read the ACK bit as a NACK. Small problem? That is terrible! Thanks a bunch Olin, things like this can drive me nuts, and waste a terrible much time. I have not yet played with IIC, but I will later. >The work around is to make the RC time constant of the data line longer than >that of the clock line. This causes the data line to hold its state for a >short time after it is realease by the slave. Smart solution :) >I personally consider 400KHz now the >upper limit of the MSSP module in master mode. OK, we can´t have it all... >And yes, Microchip has acknowledged this problem and will try to fix it in >future versions of the MSSC module. Good of them. As I have told here before, some companies do not acknowledge there ever is/was a problem, but still fix it in later chip release... I feel more confident with companies like Microchip :) Did they say anything about fixing the module in existing chips, such as 16F87x? Or will the debugged MSSP only show up in upcoming chips? Thanks /Morgan -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

>> Did they say anything about fixing the module in existing chips, such as 16F87x? Or will the debugged MSSP only show up in upcoming chips? << Here is the part of the response from Microchip that mentions fixing the problem: > I agree that the sample should happen on the rising edge and it > should be implemented with the current IIC enhancements that are > being made. This gives the impression that the fix will go in all future MSSP modules, except the ones that are already too far along the pipe to correct now. I would assume this includes new revs of existing chips because these most likely use a common logic definition of the MSSP. But, this is all speculation on my part. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, .....olinKILLspam@spam@embedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Olin: Thanks for posting the "small problem". We are just getting into using MSSP I2C and had heard of the existence of some sort of bug, but we weren't sure exactly what it would turn out to be. I'm sure that you saved us a bunch of debug time by sharing the information. BTW, although I've come across assembly language implementations (via AN734, AN735, and Matt Bennet's versions of same), I wondered if anyone knows of any 'C' implementations. Thanks in advance. Sam.... > {Original Message removed}

did you connect the C to GND from the data line? also, did you try it 400KHz? TIA Jim ----- Original Message ----- From: "Sam Linder" <SamLKILLspamIN-INC.COM> To: <.....PICLISTKILLspam.....MITVMA.MIT.EDU> Sent: Thursday, December 14, 2000 11:17 PM Subject: Re: [PIC]: Warning, IIC bug > Olin: > Thanks for posting the "small problem". We are just getting into using MSSP > I2C and had heard of the existence of some sort of bug, but we weren't sure > exactly what it would turn out to be. I'm sure that you saved us a bunch of > debug time by sharing the information. > > BTW, although I've come across assembly language implementations (via AN734, > AN735, and Matt Bennet's versions of same), I wondered if anyone knows of > any 'C' implementations. Thanks in advance. > Sam.... > > > > {Original Message removed}

> did you connect the C to GND from the data line? Yes. > also, did you try it 400KHz? No. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, EraseMEolinspam_OUTTakeThisOuTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.