• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

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

jani12

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

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?
 

Attachments

jani12

Member
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
 

Attachments

Diver300

Well-Known Member
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

Member
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."
 

Attachments

rjenkinsgb

Well-Known Member
Most Helpful Member
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?
 
Last edited:

jani12

Member
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
 

Latest threads

EE World Online Articles

Loading

 
Top