Searching \ for '[PIC] : i2c Master Timing Problems' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/i2cs.htm?key=i2c
Search entire site for: ': i2c Master Timing Problems'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] : i2c Master Timing Problems'
2001\01\30@102656 by rostaman

flavicon
face
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_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\30@132313 by Olin Lathrop

face picon face
> 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, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\30@160308 by rostaman

flavicon
face
----         Olin Lathrop <.....olin_piclistKILLspamspam.....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_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\01\30@210603 by Olin Lathrop

face picon face
> > 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, olinspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\30@230743 by rostaman

flavicon
face
> 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 KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\30@231431 by rostaman

flavicon
face
> 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 RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\31@034344 by Vasile Surducan

flavicon
face
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}

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


2001\01\31@090421 by Olin Lathrop

face picon face
> 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, RemoveMEolinspamTakeThisOuTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu


2001\01\31@090426 by Olin Lathrop

face picon face
> 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, EraseMEolinspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu


2001\01\31@203109 by Matt Bennett

flavicon
face
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_OUTspamKILLspammitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...