Post by thread:[PIC] : i2c Master Timing Problems

Hi, all. I am having trouble addressing my i2c slave with my 16f877's MSSP module, using code from Appendix C in "Serial PIC'n". When using my bit-banging code, things work fine. I use the same i2c pins, but have much better timing WRT setup and hold times. Has anybody had problems with the MSSP and needed to massage things? I'm trying to communicate between two 887s through about 10 feet of CAT5, with i2c lines twisted with power and ground. The bitrate is faster with the bit-banging, BTW. Here's the MSSP code from Serial PIC'n: send bcf PIR1, SSPIF ;make sure flag is clear banksel SSPCON2 ;select bank 1 bsf SSPCON2, SEN ;initiate START banksel PIR1 ;select bank 0 send2 btfss PIR1, SSPIF ;START completed? if yes, skip next goto send2 ;no, go try again bcf PIR1, SSPIF ;yes, clear completed flag movlw eeslv ;get slave address movwf temp ;tag it as write bcf temp, 0 movf temp, w movwf SSPBUF ;initiate send slave address send3 btfss PIR1, SSPIF ;send completed? if yes, skip next goto send3 ;no, go try again bcf PIR1, SSPIF ;clear completed flag banksel SSPCON2 ;select bank 1 btfsc SSPCON2, ACKSTAT ;ACK received from slave? if yes, skip goto send5 ;no, go terminate transaction banksel SSPBUF ;yes, select bank 0 movf data0, w ;fetch data to send movwf SSPBUF ;initiate send data send4 btfss PIR1, SSPIF ;send completed? if yes, skip next goto send4 ;no, go try again bcf PIR1, SSPIF ;yes, clear completed flag banksel SSPCON2 ;select bank 1 send5 bsf SSPCON2, PEN ;initiate STOP banksel PIR1 ;select bank 0 send6 btfss PIR1, SSPIF ;STOP completed? if yes, skip goto send6 ;no, go try again bcf PIR1, SSPIF ;yes, clear completed flag Sorry about my crappy email client. Anyway, the slave never gets an interrupt from this code. The o-scope shows the same timing pattern as my successful bit-banging code, but the trailing edges of the MSSP's SCK line are close to the SDA transitions. Don't think that makes a difference, but... Thanks for any help, Ross __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spam_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

> Anyway, the > slave never gets an interrupt from this code. The > o-scope shows the same timing pattern as my successful > bit-banging code, but the trailing edges of the MSSP's SCK > line are close to the SDA transitions. Don't think > that makes a difference, but... There is a bug in the MSSP where the master samples the ACK bit on the falling instead of rising edge of SCK. This can cause a race condition where the master sees a NACK instead of ACK. However, this bug shouldn't keep the slave from seeing the address byte. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, .....olinKILLspam@spam@embedinc.com, http://www.embedinc.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

---- Olin Lathrop <.....olin_piclistKILLspam.....EMBEDINC.COM> wrote: > > Anyway, the > > slave never gets an interrupt from this code. The > > o-scope shows the same timing pattern as my successful > > bit-banging code, but the trailing edges of the MSSP's SCK > > line are close to the SDA transitions. Don't think > > that makes a difference, but... > > There is a bug in the MSSP where the master samples the ACK bit on the > falling instead of rising edge of SCK. This can cause a race condition > where the master sees a NACK instead of ACK. However, this bug shouldn't > keep the slave from seeing the address byte. > Thanks for the info, Olin. What should the master do as a workaround, just blast the address then wait to read some 8-bit "ACK" back from the slave? Ross __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

> > There is a bug in the MSSP where the master samples the ACK bit on the > > falling instead of rising edge of SCK. This can cause a race condition > > where the master sees a NACK instead of ACK. However, this bug shouldn't > > keep the slave from seeing the address byte. > > > > Thanks for the info, Olin. What should the master do > as a workaround, just blast the address then wait > to read some 8-bit "ACK" back from the slave? No, that won't work because the master will get a NACK from the slave after sending the address byte, and therefore give up. The workaround is to put a capacitor on the data line to slow it down with respect to the clock. This was discussed a month or two ago. Check the archives. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, olinspam_OUTembedinc.com, http://www.embedinc.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email @spam@listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

> No, that won't work because the master will get a NACK from the slave after > sending the address byte, and therefore give up. The workaround is to put a > capacitor on the data line to slow it down with respect to the clock. This > was discussed a month or two ago. Check the archives. Well, I examined things more closely and noticed that the slave wasn't generating the ACK because its BF bit (SSPSTAT<0>) comes up set upon getting my address write interrupt. I clear that during initialization, and reset it when I read from the buffer, but by then it's too late, right? How do I get the slave to generate the ACK? Thanks very much for the help! Ross __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email KILLspamlistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

> No, that won't work because the master will get a NACK from the slave after > sending the address byte, and therefore give up. The workaround is to put a > capacitor on the data line to slow it down with respect to the clock. This > was discussed a month or two ago. Check the archives. > Oh, after looking at some other timing diagram, I see that the SSPIF interrupt from a master's address write will normally have the "buffer full" flag set upon entry at 0x04. I noticed that the overflow flag is not asserted, however, but still no ACK during the 9th clock pulse. Any ideas, y'all? Thanks! Ross __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Ross, One or two weeks ago it was a mail who offer a complete and functional I2c master/slave communication. Unfortunately I don't remember who was but the title was someting "I2c offer, not request" If you found it might help. Vasile On Tue, 30 Jan 2001, rostaman wrote: {Quote hidden}> Hi, all. > > I am having trouble addressing my i2c slave with > my 16f877's MSSP module, using code from Appendix > C in "Serial PIC'n". When using my bit-banging > code, things work fine. I use the same i2c pins, > but have much better timing WRT setup and hold times. > Has anybody had problems with the MSSP and needed > to massage things? I'm trying to communicate between > two 887s through about 10 feet of CAT5, with i2c lines > twisted with power and ground. The bitrate is faster > with the bit-banging, BTW. Here's the MSSP code from > Serial PIC'n: > > send bcf PIR1, SSPIF ;make sure flag is clear > banksel SSPCON2 ;select bank 1 > bsf SSPCON2, SEN ;initiate START > banksel PIR1 ;select bank 0 > send2 btfss PIR1, SSPIF ;START completed? if yes, skip next > goto send2 ;no, go try again > bcf PIR1, SSPIF ;yes, clear completed flag > movlw eeslv ;get slave address > movwf temp ;tag it as write > bcf temp, 0 > movf temp, w > movwf SSPBUF ;initiate send slave address > send3 btfss PIR1, SSPIF ;send completed? if yes, skip next > goto send3 ;no, go try again > bcf PIR1, SSPIF ;clear completed flag > banksel SSPCON2 ;select bank 1 > btfsc SSPCON2, ACKSTAT ;ACK received from slave? if yes, skip > goto send5 ;no, go terminate transaction > banksel SSPBUF ;yes, select bank 0 > movf data0, w ;fetch data to send > movwf SSPBUF ;initiate send data > send4 btfss PIR1, SSPIF ;send completed? if yes, skip next > goto send4 ;no, go try again > bcf PIR1, SSPIF ;yes, clear completed flag > banksel SSPCON2 ;select bank 1 > send5 bsf SSPCON2, PEN ;initiate STOP > banksel PIR1 ;select bank 0 > send6 btfss PIR1, SSPIF ;STOP completed? if yes, skip > goto send6 ;no, go try again > bcf PIR1, SSPIF ;yes, clear completed flag > > Sorry about my crappy email client. Anyway, the > slave never gets an interrupt from this code. The > o-scope shows the same timing pattern as my successful > bit-banging code, but the trailing edges of the MSSP's SCK > line are close to the SDA transitions. Don't think > that makes a difference, but... > > Thanks for any help, > Ross > > > __________________________________________________ > FREE voicemail, email, and fax...all in one place. > Sign Up Now! http://www.onebox.com > > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > email spamBeGonelistservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body > > -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestEraseMEspam_OUTmitvma.mit.edu

> Well, I examined things more closely and noticed that the > slave wasn't generating the ACK because its BF bit (SSPSTAT<0>) > comes up set upon getting my address write interrupt. As it should, because the address byte is now in SSPBUF. > I > clear that during initialization, and reset it when I read > from the buffer, but by then it's too late, right? No, as long as you don't get a second byte from the master before you read SSPBUF. One problem with Microchip's MSSP is that there is no flow control when a master is writing to a slave. The slave can do clock stretch when being read from, but has no way of slowing things down when being written to. I often use a third line for this when I want bi-directional flow controlled IIC. What is the bit rate of your IIC bus and what is the instruction rate of your slave? If you know the master will never send a message longer than some pre-determined length, then you could have your interrupt routine grab the bytes as they come in and stuff them into a buffer for later processing or for processing by the foreground loop. If you are running your slave at 20MHz and the IIC at 400KHz (I consider this the maximum useable IIC rate, due to the various problems), then you get 112 instructions per IIC byte transferred. That is more than enough to take the interrupt, read SSPBUF and stuff it into a buffer. It may not be enough if you have other interrupts that can cause a large latency or are trying to actually handle each byte before the next one comes in. > How do > I get the slave to generate the ACK? It will by itself if everything is going right. Again, keep in mind the MSSP bug where the master may see NACK instead of ACK. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, RemoveMEolinTakeThisOuTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestEraseME.....mitvma.mit.edu

> Oh, after looking at some other timing diagram, I see that the > SSPIF interrupt from a master's address write will normally have the > "buffer full" flag set upon entry at 0x04. I noticed that > the overflow flag is not asserted, however, but still no ACK during > the 9th clock pulse. Any ideas, y'all? You are reading the address byte from SSPBUF, which clears BF, right? You still have to read the address byte, even if you don't care what it is because the slave wouldn't have taken the byte if it wasn't the right address. The MSSP hardware in slave mode will automatically create ACK when all the conditions are right. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, EraseMEolinembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestEraseMEEraseMEmitvma.mit.edu

Vasile Surducan wrote: > > Ross, > One or two weeks ago it was a mail who offer a complete and functional > I2c master/slave communication. Unfortunately I don't remember who was > but the title was someting "I2c offer, not request" > If you found it might help. > Vasile > Ummm... that was me- the code referred to is here (taken mostly from the Microchip Application Notes AN734 and AN735): www.hazmat.com/~mjb/projects/walkingrobot/source/master.asm http://www.hazmat.com/~mjb/projects/walkingrobot/source/slave.asm Matt -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestspam_OUTKILLspammitvma.mit.edu