Electronic – I2C slave not ACK’ing quickly enough

i2cmicrocontrollertiming

I am programming a microcontroller to talk with a slave device via I2C. My I2C transactions always get NACK'd, but I believe the slave is ACK'ing the transaction, just a little bit too late and my microcontroller thinks it's a NACK. Please correct me if I'm wrong.

Here is a trace of the transaction.

The slave drives SDA low at the end to ACK the transaction. But my I2C library always reports it a NACK. Further more, the slave keeps SDA low since their isn't a 9th clock pulse, and my I2C peripheral gets stuck trying to finish the stop condition.

My I2C library is a reliable one from manufacturer that I've used many times successfully with different devices. I'm thinking the slave is just a bit too slow with the ACK.

The current trace is at 100 KHz but I've tried at 10KHz and it does the same thing. Any suggestions to solve this?

More details:

slave: AMS AS3955
master: Silicon labs EFM32 Pearl

Update

I bit banged the I2C operation in question and added the 9th clock cycle. The same problem occurs. After the operation, I disconnect SDA and measure it on the microcontroller side and slave side. Micro-SDA is high (correct) but slave-SDA is pulled low still. So it seems this may be more of an issue with the slave device than an I2C issue, right?

Update 2

See my posted answer.

Best Answer

Turns out my I2C slave doesn't support I2C.

The AMS AS3955 is configured as a SPI or I2C device at factory time. My device is a SPI one and I didn't notice.

Thanks for the discussions!

Related Solutions

Electronic – the I2C ACK, and how to detect it

The specification says that the ACK consists of a low level after the 8th clock pulse, as shown by this diagram:

enter image description here

The bus master will generate a 9th clock pulse to read the level. The specification doesn't talk about pulsing ACK, and the master will not take notice of it either. Follow the spec and take care of data setup and hold times (250ns and 5\$\mu\$s resp. for standard mode) to be sure that the level is properly detected.

What you see as a spike in the ACK is not part of the ACK, but a bus release between the ACK and a low-level first databit of the next word. The bus release comes after SCL goes low again, both in your and my diagram. According to the diagram above this release is required; note that the low level of the SDA after ACK is interrupted, indicating that SDA must go high.

Note: the bus release isn't shown on the timing diagram, figure 38, nor is timing given in the AC characteristics. I couldn't find any reference to it in the spec's text. There's also no SCL activity during this SDA high. This suggests that the bus release isn't really required. In that case the diagram contains an error, apparently copied by others, like in the TMP175 datasheet.

edit
Madmanguruman comments that the ACK comes from the slave, while the next databit comes from the master. This will often be the case, and he has a point. The next databit will also come from the slave, however, if it's the reply from the slave to a read command. Then it would make perfectly sense that the slave doesn't release the bus.

Electronic – Strange I2C Behaviour

It looks to me that you're ORing terms that you need to be ANDing. I2C_ON is 0xFFFF, so the register is going to be all 1's.

Take a look at the i2c.h file for PIC24:

#define I2C_ON                      0xFFFF /*I2C module enabled */

No matter what else you put in the configuration word, they're all going to be 1. Many settings you need (general call off, 7-bit address, etc.) need their corresponding bits to be zero.

Here's how I init the I2C peripheral on a dsPIC33 (essentially the same peripheral and same library calls):

OpenI2C1(I2C1_ON & I2C1_IDLE_CON & I2C1_7BIT_ADD & I2C1_STR_EN & I2C1_SLW_DIS & I2C1_GCALL_DIS & I2C1_SM_EN & I2C1_IPMI_DIS, clk);

Also bear in mind that the clock argument should be unsigned int - not 4.2 :)

(When in doubt, don't use the library call and manually set the SFR bits yourself.)

Related Topic