56F82xx I2C0 master bug?

[Adam_Huang]

When using I2C1 module in 56F82xx DSC, there is no issue; If using I2C0 module in 56F82xx DSC as master, with EEPROM 24LC02 connected, DSC can get ACK from EEPROM for this byte transfer by sending Device Address (0xA0); while get NACK from EEPROM for second byte by sending any ROM Address.

code segment:

    usigned char u8ErrStatus;     u8ErrStatus = 0;       I2C0_Start();     u8ErrStatus = I2C0_MasterByteWrite(u8DevAddr);     u8ErrStatus = I2C0_MasterByteWrite(u8MemAddr);  //failed at 9th pulse of clock when sending 2nd byte          I2C0_RepeatStart();     u8ErrStatus = I2C0_MasterByteWrite(u8DevAddr | 0x01);     u8ErrStatus = I2C0_MasterByteRead(u8Data, I2C0_SEND_NACK);       I2C0_Stop();

Appreciated anyone can point out the mistake in above code segment......or, is there any Errata that can explain why I2C1 can but I2C0 can't.

[johnlwinters]

It should work the same on both I2C0 and I2C1. What may differ is the pin configuration and board layout for the pin.

For I2C, do not drive the pins configured to the bus. Use the mode where the DSC only forces the signal low, and allows the bus to pull up the signals.

In software, make sure that the pins configuration is totally correct. For the hardware, observe the waveforms and determine if the bus meets the specification. The bus includes the external voltage supply pulling up the bus.

[Adam_Huang]

Thanks John's prompt response.. Attached is the waveform that I captured at SCL and SDA signal of I2C0 module.

You can see that ACK can be obtained after master sends Device Address to slave, but NACK will be obtained after master sends any Memory Address (0x28 for example).

I tried to change Device Address rather than 0x5? (? means 0 ~ F), the response can get NACK. So, the configuration should be OK for I2C0 module. Compared with I2C1 configuration, there is no distinct difference on each register respectively.

[johnlwinters]

Would you be able to cut and jump your board so that the same circuit that works is connected to the i2c pins that seem to be problematic?

How many memory devices are you addressing in your system, and at what addresses?

Perhaps a schematic would be good of the devices on the I2C bus.

[Adam_Huang]

It's inconvenient to rework the board to use I2C1 instead of I2C0 to connect EEPROM for verification. What I had done were:

(1) extract the source code from the good project which work well with I2C1 connecting EEPROM;

(2) build a new project with the extracted source code that also can work well with I2C1 on the same board;

(3) change all the I2C1 to I2C0 to build the above project but it cannot work well with another board where the same type of EEPROM is connected to I2C0 interface.

The waveform is same as the privious reply depicted, in which the 9th clock of 2nd byte will get NACK response.