Why does I2C Expander reply with NAK when master sends a byte?

[jani12]

NXP LPC11E68JBD48E Microcontroller I2C1 is Master. I2C1 is in chapter 13. I2C1 is in Master Transmitter Mode.

https://www.mouser.com/ds/2/302/UM10732-315822.pdf

NXP PCAL6416A I2C 16-bit I/O Expander is Slave. https://www.nxp.com/docs/en/data-sheet/PCAL6416A.pdf
I2C1 Block in Microcontroller is initialized successfully.

Step 1. I2C1 block is in master transmitter mode because I2C control Register STA bit is set to 1. See attached step1_Master_Transmitter_Mode.png file.

Step 2. Microcontroller I2C1 block transmits START bit. After the START bit is transmitted, the Serial Interrupt(SI) bit in I2C Control Register is set and
and STAT register in microcontroller I2C1 block contains status of 0x08. See attached filename step2_start_bit_sent.png

step 3. The status 0x08 is used to vector to a state service routine. This routine loads the slave address and Write bit to the DAT register.
See attached filename step3_status_0x08_state_handler.png

step 4. Slave address and Write bit has been transmitted and negative acknowledgement(NAK) is received from slave. The STAT register has status of 0x20 and
microcontroller fires interrupt on this status value. See attached step4a_NAK_from_slave.png file and step4b_NAK_handler.png

This problem occurs the very first time Master tries to communicate with slave.

The previous hardware works fine with this microcontroller and NXP PCA6408AHKX I2C 8-bit Expander chip. When this byte is written to I2C register, ACK is recieved.

New hardware is same as previous hardware except 16-bit I/O expander instead of 8-bit.

What might be the problem? Is it hardware or software? What are usually reasons for NACK in I2C communication?

 

[jani12]

The byte I'm sending is 0x42. Seven most significant bits are slave address and least significant bit is write direction bit. Please see attached filename byte_sent.png

 

[Diver300]

The slave device doesn't really "send a NAK", it just fails to send an acknowledgement. To send an acknowledgement, the slave pulls the data line low for one clock pulse after the address, the 0x42 has been received.

As far as I can tell, the 16 bit device is in a completely different package to the 8 bit device, so you've obviously done a new layout. Have you connected the address input to +ve to make the address 0x42? If the address input is grounded, the address will be 0x40. If the address input is floating, the behaviour will be unpredictable, and will need to be fixed.

Oscilloscope traces are good for fixing I2C.

 

[jani12]

Attached are scope screenshots for existing hardware and new hardware.

With existing hardware, slave sends an ACK.

With new hardware, after START condition is transmitted, master fires an interrupt to inform software that START bit has been transmitted but I don't see it on SDA line. I'm triggering on START bit. What might be the problem?
Some inputs in the I2C expander chip are floating. Is this preventing the START bit to appear on the SDA line?
From I2C expander datasheet: "External resistors are required for inputs (on P Port) that may float. Also, internal pull-up or pull-down may be used to eliminate the need for external components."

 

[rjenkinsgb]

Edit - ignore this, I think I'm getting out of step with the start <> data transition..
Data actually starts after both lines go low.


Looking at the master waveforms, it appears the address is wrong, which would result in no response from the expander.

There is a 0 start bit, then 1 0 0 0 0 1 0 1

That's 0x85 instead of 0x42

Somewhere it appears something is doing a left-shift on the address byte before it is transmitted.
That may be some routine expecting a 7 bit address unshifted address, then shifting it to allow for a separate read/write bit?

Try using 0x21 for the address, assuming that the hardware address pin is high?

 

[jani12]

Problem Solved:
New board #1: saw NAK in software ISR
New board #2: SCL and SDA not wiggling at all
New boards #3 and #4: I2C Communication appears to be working as expected