We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I am interfacing AT24C1024 (2 Nos.) EEPROM using I2C1 (channel 1) port of LPC2378 but i am not able to read / write into it. However i have successfully implemented same EEPROM with I2C0 (channel 0) port of LPC2378. And i used same code snippets which i used for I2C0 while interfacing EEPROM with I2C1 but it is not working. Currently i have disabled I2C0 initialisation, ISR Routines in my code only using I2C1 but still it is giving me problems. SDA0, SCL0 have external pull ups of 10K and SDA1 and SC1 have internal pull ups enabled. As fas as software is concerned i have used same working code which i used in I2C0 with only changing regsiters name. Do help me in this regard.
I checked I2C1 is enabled on power on. The code executes I2C1 ISR routine when START is given but after debugging i found out that it is getting NO ACK from EEPROM. It goes in case 0x20 (Slave address+ W transmitted NO ACK received) first. And then my code is getting hanged in case 0x30 (Data Byte in I2DAT is transmitted, NO ACK has been received), instead of executing cases 0x18 and 0x28 of Master Transmitting Mode. What could be the possible reason for NO ACK? I checked the hardware it is working fine when I2C0 is used but in case of I2C1 i could not write/read anything in EEPROM
how about the clock feeding the i2c peripherals?
Do you mean that my slave (EEPROM) is waiting for some lost bit / data during transfer and it is getting hanged?? hence NO ACK from EEPROM and it keep SDA pull down, SCL up ( so busy bus)! I didnt understand "clock feeding I2C peripherals". Does that mean that i should pull my SCL low to release the bus? or something else. Kindly elaborate. thanks
you will have to read the manual for the EEPROM to know for sure - but yes, you need to start with an idle i2c bus. are you sure the peripheral clock frequency for both i2c1 and i2c0 is the same? do you have a scope to observe the traffic?
You might find this useful:
NXP/LeCroy - "How to Debug I2C Devices Using an Oscilloscope" ics.nxp.com/.../debug.i2c.oscilloscope.pdf
The actual debugging seems rather focussed on the specific I2C features of a LeCroy scope - but the general information about the I2C protocol showing corresponding scope traces should be informative...