Searching \ for '[PIC] slave I2C problems, WCOL bit' 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: 'slave I2C problems, WCOL bit'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] slave I2C problems, WCOL bit'
2005\03\14@063953 by Guillermo Rodriguez Garcia

flavicon
face
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_OUTguilleTakeThisOuTspamiies.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


2005\03\14@075747 by Michael Rigby-Jones

picon face


{Quote hidden}

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.
=======================================================================

2005\03\14@083428 by Alan B. Pearce

face picon face
>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.

2005\03\14@084145 by Michael Rigby-Jones

picon face


{Quote hidden}

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.
=======================================================================

2005\03\14@094104 by Guillermo Rodriguez Garcia
flavicon
face
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}

>

2005\03\14@094425 by Guillermo Rodriguez Garcia

flavicon
face
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@guilleKILLspamspamiies.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


2005\03\14@100046 by Alan B. Pearce

face picon face
>>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.

2005\03\14@105934 by Alan B. Pearce

face picon face
>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.

2005\03\14@112516 by Guillermo Rodriguez Garcia

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

----
KILLspamguilleKILLspamspamiies.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


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