return value of I2C_WRITE()

[tmcdougall]

I am having problems with the return value from the i2c_write() function. I am using the 18f252, and version 3.163 of PCH. The manual indicates that the return value from this function is the ack status, that is either 0, ACK, or 1, NACK.

I am not seeing this at all. I am seeing a byte being returned and most vexing of all is it is not returning the proper value for the ACK status. I have looked at the value of the data being transmitted on a logic analyzer and it is clear that the ACK bit is not beign returned correctly.

Any assistance anyone may have is appreciated.

TLM
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515659

[Kenny]

:=I am having problems with the return value from the i2c_write() function. I am using the 18f252, and version 3.163 of PCH. The manual indicates that the return value from this function is the ack status, that is either 0, ACK, or 1, NACK.
:=
:=I am not seeing this at all. I am seeing a byte being returned and most vexing of all is it is not returning the proper value for the ACK status. I have looked at the value of the data being transmitted on a logic analyzer and it is clear that the ACK bit is not beign returned correctly.
:=
:=Any assistance anyone may have is appreciated.
:=
:=TLM

Some things to check.
1. The write address should have R/W bit set to 0, ie the write address should be an even number.

2. The ACK will only be given by the slave device by pulling SDA low on the 9th clock pulse only if there is an address match. There is no byte returned to the master, only the ACK.
Make sure there is no address conflict with other slave devices.
Yes, that can happen. I attended a Philips i2c seminar in the late 1980's and pointed this out. I was already using i2c and discovered a conflict by accident. For those interested it's
SAA1064 7-segment led display driver addresses 01110AA
PCF8574A port expander addresses 0111AAA.
With PCF8574A address bit A2 = 0, there is a conflict if the A0 and A1 bits match.

3. Pullup resistors on SDA and SCL should be around 2k2 (see i2c specs).

Hope this helps
Kenny
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515666

[tmcdougall]

:=:=I am having problems with the return value from the i2c_write() function. I am using the 18f252, and version 3.163 of PCH. The manual indicates that the return value from this function is the ack status, that is either 0, ACK, or 1, NACK.
:=:=
:=:=I am not seeing this at all. I am seeing a byte being returned and most vexing of all is it is not returning the proper value for the ACK status. I have looked at the value of the data being transmitted on a logic analyzer and it is clear that the ACK bit is not beign returned correctly.
:=:=
:=:=Any assistance anyone may have is appreciated.
:=:=
:=:=TLM
:=
:=Some things to check.
:=1. The write address should have R/W bit set to 0, ie the write address should be an even number.
:=
:=2. The ACK will only be given by the slave device by pulling SDA low on the 9th clock pulse only if there is an address match. There is no byte returned to the master, only the ACK.
:=Make sure there is no address conflict with other slave devices.
:=Yes, that can happen. I attended a Philips i2c seminar in the late 1980's and pointed this out. I was already using i2c and discovered a conflict by accident. For those interested it's
:=SAA1064 7-segment led display driver addresses 01110AA
:=PCF8574A port expander addresses 0111AAA.
:=With PCF8574A address bit A2 = 0, there is a conflict if the A0 and A1 bits match.
:=
:=3. Pullup resistors on SDA and SCL should be around 2k2 (see i2c specs).
:=
:=Hope this helps
:=Kenny
:=
:=
:=
:=
:=
:=
I should add a little more detail I think.

The PIC is operating in slave mode. I adopted the example code provided in ex_slave.c. I can see the ack being received after sending a byte when I look at it on a logic analyzer but the value returned is not correct.

I have just about given up on the CCS function and I am writing my own IIC code.

Thanks for your help.

TLM
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515667

[Kenny]

:=:=:=I am having problems with the return value from the i2c_write() function. I am using the 18f252, and version 3.163 of PCH. The manual indicates that the return value from this function is the ack status, that is either 0, ACK, or 1, NACK.
:=:=:=
:=:=:=I am not seeing this at all. I am seeing a byte being returned and most vexing of all is it is not returning the proper value for the ACK status. I have looked at the value of the data being transmitted on a logic analyzer and it is clear that the ACK bit is not beign returned correctly.
:=:=:=
:=:=:=Any assistance anyone may have is appreciated.
:=:=:=
:=:=:=TLM
:=:=
:=:=Some things to check.
:=:=1. The write address should have R/W bit set to 0, ie the write address should be an even number.
:=:=
:=:=2. The ACK will only be given by the slave device by pulling SDA low on the 9th clock pulse only if there is an address match. There is no byte returned to the master, only the ACK.
:=:=Make sure there is no address conflict with other slave devices.
:=:=Yes, that can happen. I attended a Philips i2c seminar in the late 1980's and pointed this out. I was already using i2c and discovered a conflict by accident. For those interested it's
:=:=SAA1064 7-segment led display driver addresses 01110AA
:=:=PCF8574A port expander addresses 0111AAA.
:=:=With PCF8574A address bit A2 = 0, there is a conflict if the A0 and A1 bits match.
:=:=
:=:=3. Pullup resistors on SDA and SCL should be around 2k2 (see i2c specs).
:=:=
:=:=Hope this helps
:=:=Kenny
:=:=
:=:=
:=:=
:=:=
:=:=
:=:=
:=I should add a little more detail I think.
:=
:=The PIC is operating in slave mode. I adopted the example code provided in ex_slave.c. I can see the ack being received after sending a byte when I look at it on a logic analyzer but the value returned is not correct.
:=
:=I have just about given up on the CCS function and I am writing my own IIC code.
:=
:=Thanks for your help.
:=
:=TLM

Ah, I see. I also couldn't get ex_slave.c to work, not sure whether there was an inherent problem or my lack of skill. I have seen posts where people say they have it working.
Anyway, I wrote my own code too. Place 'i2c slave' in the search and you will see it together with lots of other posts on the subject.
Microchip AN734 is the reference for this.
Part relevant to your problem is:
Slave receives data from Master (Master Write Operation):
"When R/W bit of incoming address byte is clear and address match occurs, the R/W bit of SSPSTAT is cleared and the received address is loaded into SSPBUF. When the address byte overflow condition exists, then the not /ACK pulse is given (high). An overflow condition is defined as either bit BF is set or bit SSPOV is set.
An SSP interrupt is generated for each data transfer byte, SSPIF must be cleared by software (taken care of by compiler).
SSPBUF will be loaded if the SSPOV bit is set and the BF flag is cleared.
If a read of SSPBUF was performed, but the user did not clear the state of the SSPOV bit before the next receive occurred, the /ACK is not sent and the SSPBUF is updated".

Regards
Kenny
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515669

[Pete Smith]

:=
:=Some things to check.
:=1. The write address should have R/W bit set to 0, ie the write address should be an even number.
:=
:=2. The ACK will only be given by the slave device by pulling SDA low on the 9th clock pulse only if there is an address match. There is no byte returned to the master, only the ACK.
:=Make sure there is no address conflict with other slave devices.
:=Yes, that can happen. I attended a Philips i2c seminar in the late 1980's and pointed this out. I was already using i2c and discovered a conflict by accident.

I've found a conflict between the Philips PCF8583 RTC, and the RAMTRON 16k FRAM IC.

I didn't even think of checking the IDs of the ICs before I built the prototype board. When I got it back, I built it up, and it was totally unable to read the RTC.

I then looked at the docs, and both devices had the same ID, so won't live on the same bus :-/

I now have to have _2_ I2C buses.

Pete.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515677

[Kenny]

:=
:=:=
:=:=Some things to check.
:=:=1. The write address should have R/W bit set to 0, ie the write address should be an even number.
:=:=
:=:=2. The ACK will only be given by the slave device by pulling SDA low on the 9th clock pulse only if there is an address match. There is no byte returned to the master, only the ACK.
:=:=Make sure there is no address conflict with other slave devices.
:=:=Yes, that can happen. I attended a Philips i2c seminar in the late 1980's and pointed this out. I was already using i2c and discovered a conflict by accident.
:=
:=I've found a conflict between the Philips PCF8583 RTC, and the RAMTRON 16k FRAM IC.
:=
:=I didn't even think of checking the IDs of the ICs before I built the prototype board. When I got it back, I built it up, and it was totally unable to read the RTC.
:=
:=I then looked at the docs, and both devices had the same ID, so won't live on the same bus :-/
:=
:=I now have to have _2_ I2C buses.
:=
:=Pete.

I'll have to watch that one, the PCF8583 is the RTC I always use.
Thanks
Kenny
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515694