Electronic – Problem I2C NACK in 3rd byte MLX90614 – Repeated Start

i2csmbus

I am trying to read Melexis MLX90614 infrared temperature sensor through SMBus (I2C or TWK like protocol).

The protocol (SMBus) implement an special type of command or sequence called repeated start, that means we send a start condition without a previous stop condition.

I am using a XMEGA microcontroller using TWI libraries used in application note AN1308

In order to read the sensor data, I need to send 1 byte to write the address to read, and next read 3 bytes of data. For that reason is used repeated start.

Reading data example

The problem is I get ACK from 2 first bytes (write address and command write) but i get NACK when i send the address after repeated start condition

I have 3 captures from Oscilloscope:

General sequence
General sequence
The repeated start condition appears OK, we have a start condition in the middle without a previous stop condition. The address is right and the command (address to read) also is ok (0b00000110 – 6)

The initialization of module is:

// ************** TWI Master config ****************
TWI_MasterInit(&twiMaster,
               &TWIC,
               TWI_MASTER_INTLVL_HI_gc,
               TWI_BAUDSETTING);

And the usage is:

    TWI_MasterWriteRead(&twiMaster,
                        MLX90164_ADDR,
                        bufferTX,
                        1,
                        3);

MLX90614 is 0x5A and bufferTX is a unsigned char array with a 0x06 in the first position. Also the baudrate is set to 100kHz

I don't know why i get NACK in 2nd address byte to read the data from sensor, the repeated start condition looks right. Also, the hardware configurations must be ok because I get ACK from 1st and 2nd byte

Thanks in advance

Best Answer

It is hard to tell without being zoomed in further, but it looks as though you may have inadvertently sent a Stop immediately after the Repeated Start. SDA looks like it went high a little bit before SCL went low. This would certainly prevent the slave from ACKing.

The first Start has the same behavior, but it looks like it wasn't quite as bad and so wasn't perceived as a Stop.