Post by thread:[PIC] slave I2C problems, WCOL bit

Hello all, I am using a PIC 16F877 as an interrupt-driven I2C slave and have found one issue, which I would like to share with others. Sometimes, when the PIC is addressed for reading (i.e. master reads, PIC writes), it would fail to transmit the 2nd or subsequent data bytes back to the master. This would never happen for single-byte messages, though. The problem seems to be that sometimes, when the SSP interrupt is entered with SSPSTAT containing: S = 1 (START condition seen last in the bus) RW = 1 (master wants to read a byte) DA = 1 (last byte sent was data) BF = 0 (buffer is empty) and you write a byte to SSPBUF, the SSP module detects a collision and sets the WCOL bit, and SSPBUF is not updated. In theory this should never happen. According to app note 734: "In practice, there will be no write collisions if the application firmware only writes to SSPBUF during states when the BF bit is cleared and the Slave device is transmitting data to the Master." However here there is a write collision, even though BF was clear at the time SSPBUF is written to. It is possible to work around this by checking WCOL immediately after writing to SSPBUF (which, on the other hand, is exactly what the code from AN734 does), e.g.: _tryagain bcf SSPCON, WCOL movwf SSPBUF btfsc SSPCON, WCOL goto _tryagain However I don't understand why this is happening. Theoretically there should not be any write collisions if the buffer is empty. Anyone has seen this before? Best regards, G. ---- spam_OUTguilleTakeThisOuTiies.es -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 11/03/2005

{Quote hidden}>-----Original Message----- >From: .....piclist-bouncesKILLspam@spam@mit.edu [piclist-bouncesKILLspammit.edu] >Sent: 14 March 2005 11:25 >To: .....piclistKILLspam.....mit.edu >Subject: [PIC] slave I2C problems, WCOL bit > > >Hello all, > >I am using a PIC 16F877 as an interrupt-driven I2C slave and >have found one issue, which I would like to share with others. > >Sometimes, when the PIC is addressed for reading (i.e. master >reads, PIC writes), it would fail to transmit the 2nd or >subsequent data bytes back to the master. This would never >happen for single-byte messages, though. The problem seems to >be that sometimes, when the SSP interrupt is entered with >SSPSTAT containing: > >S = 1 (START condition seen last in the bus) >RW = 1 (master wants to read a byte) >DA = 1 (last byte sent was data) >BF = 0 (buffer is empty) > >and you write a byte to SSPBUF, the SSP module detects a >collision and sets the WCOL bit, and SSPBUF is not updated. > >In theory this should never happen. According to app note 734: > >"In practice, there will be no write collisions if the >application firmware only writes to SSPBUF during states when >the BF bit is cleared and the Slave device is transmitting >data to the Master." > >However here there is a write collision, even though BF was >clear at the time SSPBUF is written to. > >It is possible to work around this by checking WCOL >immediately after writing to SSPBUF (which, on the other hand, >is exactly what the code from AN734 does), e.g.: > >_tryagain > bcf SSPCON, WCOL > movwf SSPBUF > btfsc SSPCON, WCOL > goto _tryagain > >However I don't understand why this is happening. >Theoretically there should not be any write collisions if the >buffer is empty. > >Anyone has seen this before? This rang a bell so I checked an old 16F877 based project I worked on years ago. I had the same problem with multi-byte replies from the slave and it was fixed by checking both the BF bit and the CKP bit before writing to the buffer. The C source for sending a byte looked like this: case I2C_SEND: // Ensure buffer is empty. // Must also check SCL or a write collision can occur. if (!STAT_BF && !CKP) { if(TxBuffPtr > 0) // check for remaining data to send { // get next byte, and place in MSP buffer SSPBUF = TxBuffer[--TxBuffPtr]; } else { // shouldn't be here. Master incorrectly ACKed last byte // so send a dummy byte of 0xFF to avoid locking SDA low SSPBUF = 0xFF; } // enable SCL CKP = 1; } Another way around this is to check the WCOL bit after loading SSPBUFF, and keep trying until you don't get a collision. WCOL = 0; // Clear the WCOL flag. SSPBUF = data; // Write the byte in WREG while( WCOL ) // redo while there a write collision { WCOL=0; SSPBUF = data; // Write the byte in WREG } CKP = 1; Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. =======================================================================

{Quote hidden}>-----Original Message----- >From: EraseMEpiclist-bouncesspam_OUTTakeThisOuTmit.edu [piclist-bouncesspam_OUTmit.edu] >Sent: 14 March 2005 13:35 >To: Microcontroller discussion list - Public. >Subject: Re: [PIC] slave I2C problems, WCOL bit > > >>It is possible to work around this by checking WCOL immediately after >>writing to SSPBUF (which, on the other hand, is exactly what the code >>from AN734 does), e.g.: > >Hmm, I converted the AN734 code into an interrupt routine >using Olins modular system, and never had the sort of problems >you see. Just looked through the code, and it is as you say. I >cannot remember why it is possible to have a write collision. >It may be related to the following possibly happening - > >last bit of byte shifted out - set interrupt flag >PIC tries to load next byte - master not yet ack'd previous >byte so collision. The SSPIF flag is set on the falling edge of the ACKnowledge clock bit, so you *shouldn't* ever get into the ISR before the entire byte has been sent and acknowledged. Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. =======================================================================

Alan, I should have explained better. The problem does not arise with the code from AN734. But the reason why it does not arise with that code is because it is doing something that theoretically it does not need to do, according to the datasheet and to the application note itself. Guillermo At 14:34 14/03/2005, Alan B. Pearce wrote: {Quote hidden}> >It is possible to work around this by checking WCOL > >immediately after writing to SSPBUF (which, on the other hand, > >is exactly what the code from AN734 does), e.g.: > >Hmm, I converted the AN734 code into an interrupt routine using Olins >modular system, and never had the sort of problems you see. Just looked >through the code, and it is as you say. I cannot remember why it is possible >to have a write collision. It may be related to the following possibly >happening - > >last bit of byte shifted out - set interrupt flag >PIC tries to load next byte - master not yet ack'd previous byte so >collision. > >

At 13:56 14/03/2005, Michael Rigby-Jones wrote: [...] > > > >However I don't understand why this is happening. > >Theoretically there should not be any write collisions if the > >buffer is empty. > > > >Anyone has seen this before? > >This rang a bell so I checked an old 16F877 based project I worked on >years ago. I had the same problem with multi-byte replies from the >slave and it was fixed by checking both the BF bit and the CKP bit >before writing to the buffer. [...] I wonder what may be causing this behavior. If the buffer is empty before writing to SSPBUF (which is the case) yet we still get a collision when SSPBUF is written to, that looks like a silicon bug. However I could not find any information on this topic. Guillermo ---- @spam@guilleKILLspamiies.es -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 11/03/2005

>>last bit of byte shifted out - set interrupt flag >>PIC tries to load next byte - master not yet ack'd previous >>byte so collision. > >The SSPIF flag is set on the falling edge of the ACKnowledge clock bit, >so you *shouldn't* ever get into the ISR before the entire byte has been >sent and acknowledged. OK, I was just surmising there, but obviously there is some race condition that causes something like this to happen. I just went and had a pretty close look at the datasheet (rev C is what I have) and apart from the register description right at the beginning of the section on the MSSP, there is absolutely no discussion of the WCOL flag within the slave portion of the datasheet. It gets plenty of mention in the master section though.

>I should have explained better. The problem does not arise >with the code from AN734. But the reason why it does not arise >with that code is because it is doing something that >theoretically it does not need to do, according >to the datasheet and to the application note itself. Yeah, sure (see also Michael Rigby-Jones answer to mine). However it is evident that they have allowed for it in the operation of the chip (see the description of the SSPCON register at the start of the section on the MSSP), and the example code obviously had a problem until they did exactly that, presumably because they had exactly the problem you have, and that is how they got around it. I suspect a race condition inside the chip for exactly how it decides it is ready to accept the next character. The bit that worries me is that in the description of the slave mode operation there is not a single mention of the WCOL bit, suggesting that it should not happen unless you try and write before the SSPBF goes false.

Alan, At 16:59 14/03/2005, Alan B. Pearce wrote: > >I should have explained better. The problem does not arise > >with the code from AN734. But the reason why it does not arise > >with that code is because it is doing something that > >theoretically it does not need to do, according > >to the datasheet and to the application note itself. > >Yeah, sure (see also Michael Rigby-Jones answer to mine). However it is >evident that they have allowed for it in the operation of the chip (see the >description of the SSPCON register at the start of the section on the MSSP), Yes. The WCOL bit makes sense when you're controlling the I2C slave from the main loop. >and the example code obviously had a problem until they did exactly that, >presumably because they had exactly the problem you have, and that is how >they got around it. I suspect a race condition inside the chip for exactly >how it decides it is ready to accept the next character. I suspect the same. Lowering the bus frequency didn't make a difference (the same problem happened at 400 kHz, 100 kHz, and 10 kHz), however making the 'inter-character gap' wider helped, which also sustains this theory. > The bit that >worries me is that in the description of the slave mode operation there is >not a single mention of the WCOL bit, suggesting that it should not happen >unless you try and write before the SSPBF goes false. Yes, that is exactly what worries me too. Thanks for your comments, Guillermo ---- KILLspamguilleKILLspamiies.es -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 11/03/2005