I2C on 18F14K50 Not Sending SSPBUF

[scott larson]

Hi All,

I'm using an 18F14K50 running at 3.3V, programming with C18 in MPLAB.
Circuit is programmed and powered via PicKit 3.

I'm trying to communicate with a I2C EEPROM (24xx1025).

Currently I can send a Start Condition and load SSPBUF with the first
byte to send, then I wait for the R_W bit to go low before writing to
SSPBUF again. No interrupts are enabled, I2C is done via polling the
SSPSTAT bits.
I'm looking at SDA and SCL on a 'scope.

Problem: the I2C doesn't pump out the second byte.
I've checked the device errata, but there is nothing related to this.

I've looked at the generated assembly code and it looks fine. It's
very similar to the I2C write sequence shown here:
http://www.piclist.com/techref/microchip/w-r_i2c.gif
In fact, this is what I used to write my C code.

One solution I've figured out is to wait for R_W bit to go low again
(as shown in the code). Can anyone point out anything I'm doing wrong,
or forgetting to do?


Below is a portion of the C code (excuse any whitespace issues, I've
got tabs set to 4 spaces, but gmail may butcher it):

uint8_t I2Ctest(uint8_t control, uint8_t addressH, uint8_t addressL,
uint8_t data) {
   IdleI2C();                      //ensure module is idle
   I2C_START();                    //initiate START condition
   while( SSPCON2bits.SEN ) {;}    // wait until start condition is over

   SSPBUF = control;              //write control byte
   while(SSPSTATbits.R_W) {;}       //wait until write completes
   while(SSPSTATbits.R_W) {;}       //wait until write completes - IF
THIS IS HERE, THE SECOND BYTE WILL BE WRITTEN

    SSPBUF = addressH;              //write address high
    while(SSPSTATbits.R_W) {;}       //wait until write completes
    ...

End code

Any help/advice will be appreciated,
Scott Larson

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Scott wrote:
> Currently I can send a Start Condition and load SSPBUF with the first
> byte to send, then I wait for the R_W bit to go low before writing to
> SSPBUF again. No interrupts are enabled, I2C is done via polling the
> SSPSTAT bits.  I'm looking at SDA and SCL on a 'scope.
>
> Problem: the I2C doesn't pump out the second byte.

I'm not really following what exactly is happening, but polling the RW bit
is something you do in slave mode, not in master mode if I recall correctly.
In the past there have been problems with the IIC hardware, so I now often
just do the master in firmware where I can make sure everything is done
sequentially and avoid any race conditions.

> excuse any whitespace issues, I've
> got tabs set to 4 spaces,

No.  There is no excuse.  It's your job to convert to hard spaces and make
sure it is readably formatted before asking 2000 people to look at it.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[scott larson]

On Thu, Oct 22, 2009 at 8:19 AM, Olin Lathrop <olin_piclist@...> wrote:

> Scott wrote:
>> Currently I can send a Start Condition and load SSPBUF with the first
>> byte to send, then I wait for the R_W bit to go low before writing to
>> SSPBUF again. No interrupts are enabled, I2C is done via polling the
>> SSPSTAT bits.  I'm looking at SDA and SCL on a 'scope.
>>
>> Problem: the I2C doesn't pump out the second byte.
>
> I'm not really following what exactly is happening, but polling the RW bit
> is something you do in slave mode, not in master mode if I recall correctly.
> In the past there have been problems with the IIC hardware, so I now often
> just do the master in firmware where I can make sure everything is done
> sequentially and avoid any race conditions.
>

According to the datasheet, in Master mode:
R_W = 1 -- Transmit is in progress
R_W = 0 -- Transmit is not in progress

The datasheet is not clear at all about I2C Firmware Controlled Master
mode vs. Master mode. It states "Master mode of operation is supported
by interrupt generation on the detection of the Start and Stop
conditions. The Stop (P) and Start (S) bits are cleared from a Reset
or when the MSSP module is disabled. Control of the I2C bus may be
taken when the P bit is set, or the bus is Idle, with both the S and P
bits clear" and "In Firmware Controlled Master mode, user code
conducts all I2C bus operations based on Start and Stop bit
conditions." Could you please enlighten me on the differences,
particularly how one goes about setting Start and Stop conditions as
well as writing to SSPBUF.

Thanks,
Scott

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Scott wrote:
> According to the datasheet, in Master mode:
> R_W = 1 -- Transmit is in progress
> R_W = 0 -- Transmit is not in progress

Hmm, I don't remember seeing that, but I just quickly grabbed a old 18F
datasheet and didn't look up your particular PIC, whatever that was.

In any case, "transmit in progress" sounds different to me from "SSPBUF
ready to accept another byte", which is how you apparently are trying to use
the bit.  Isn't there some xxIF bit in one of the PIR registers that is
specifically meant to tell you when SSPBUF can take another byte?

> The datasheet is not clear at all about I2C Firmware Controlled Master
> mode vs. Master mode.

Huh?  Something isn't making any sense.  The datasheet explains how the MSSP
works, including when it is used in IIC master mode.  It's not the
datasheet's purpose to tell you how to do IIC in firmware, and I'll be
rather surprised if newer versions contain anything about that.

Perhaps you are confusing the datasheet with the compiler or library manual?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Alan B. Pearce-2]

>> According to the datasheet, in Master mode:
>> R_W = 1 -- Transmit is in progress
>> R_W = 0 -- Transmit is not in progress
>
>Hmm, I don't remember seeing that, but I just quickly grabbed
>a old 18F datasheet and didn't look up your particular PIC,
>whatever that was.
>
>In any case, "transmit in progress" sounds different to me from
>"SSPBUF ready to accept another byte", which is how you apparently
>are trying to use the bit.  Isn't there some xxIF bit in one of
>the PIR registers that is specifically meant to tell you when
>SSPBUF can take another byte?

Sounds to me like the incorrect bit is being checked too - but I also
haven't checked the datasheet.

BUT what it does sound like is that the I2C hardware is waiting for the
slave device to respond with the 9th bit which is the acknowledge bit, and
if that doesn't happen, then the second byte won't get transmitted.

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[scott larson]

On Thu, Oct 22, 2009 at 11:56 AM, Alan B. Pearce
<Alan.B.Pearce@...> wrote:

>>> According to the datasheet, in Master mode:
>>> R_W = 1 -- Transmit is in progress
>>> R_W = 0 -- Transmit is not in progress
>>
>>Hmm, I don't remember seeing that, but I just quickly grabbed
>>a old 18F datasheet and didn't look up your particular PIC,
>>whatever that was.
>>
>>In any case, "transmit in progress" sounds different to me from
>>"SSPBUF ready to accept another byte", which is how you apparently
>>are trying to use the bit.  Isn't there some xxIF bit in one of
>>the PIR registers that is specifically meant to tell you when
>>SSPBUF can take another byte?
>
> Sounds to me like the incorrect bit is being checked too - but I also
> haven't checked the datasheet.
>
> BUT what it does sound like is that the I2C hardware is waiting for the
> slave device to respond with the 9th bit which is the acknowledge bit, and
> if that doesn't happen, then the second byte won't get transmitted.
>

In Master mode, the BF and R_W bits go high on a write to SSPBUF. BF
goes low after the 8th bit is written. After the 9th (/ACK) bit is
clocked in, R_W goes low and SSPIF is set. Seems to me that either one
of these bits can be polled to determine when SSPBUF can be written to
again.

On my scope, I can see that the slave does ACK after the first byte is written.

I also wrote an interrupt-based I2C routine that acts on the SSPIF
flag, and this works just fine. I'm still curious to know why polling
R_W once doesn't work, but polling it twice does work...

-Scott

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Alan B. Pearce wrote:
> BUT what it does sound like is that the I2C hardware is waiting for
> the slave device to respond with the 9th bit which is the acknowledge
> bit, and if that doesn't happen, then the second byte won't get
> transmitted.

I don't think it works that way since the master controls the clock.  In
other words, the bit time for the ACK bit is set by the master and the slave
either pulls the line low or not.  The master doesn't wait for the slave to
send the bit, it just samples the line at the appropriate time.

Higher level protocol logic may decide to retry until the slave responds,
but I don't think that is built into the MSSP.  It only tells the firmware
whether the ACK bit was recieved high or low.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Scott wrote:
> In Master mode, the BF and R_W bits go high on a write to SSPBUF. BF
> goes low after the 8th bit is written. After the 9th (/ACK) bit is
> clocked in, R_W goes low and SSPIF is set. Seems to me that either one
> of these bits can be polled to determine when SSPBUF can be written to
> again.

Isn't BF the buffer full bit?  If so, isn't that the obvious bit to use to
determine whether the buffer is full or not?  RW may have some different
logic.  If they give you a bit specifically to tell you whether the write
buffer is full, using anything else is just asking for trouble.

> I also wrote an interrupt-based I2C routine that acts on the SSPIF
> flag, and this works just fine.

Wow, who'd have thought that if you use the bits according to their purpose
the code works correctly!?

> I'm still curious to know why polling
> R_W once doesn't work, but polling it twice does work...

Because it's meant for something else and doesn't work the way you think,
obviously.  This should be no surprise given they gave you a separate bit
just for what you are trying to do.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist