I am using a Raspberry Pi Zero board as an I2C controller and a Raspberry Pi Pico as an I2C target and passing data between them using I2C.

I use something like this:

unsigned char buf[256];
write(fd, buf, 1)  

to write 1 byte data from controller to target. The SDA and SCL pins show what I expect in the oscilloscope.

I use something like this for the controller read 1 byte data from the target:

unsigned char buf[256];  
read(fd, buf, 1)    

At this point I am getting a HIGH in the data frame ACK bit, when I thought it should be low, as per this tutorial I am following. For an I2C target address of 0x22, this is the waveform I am getting:

enter image description here

The address frame seems correct (bits from LSB to MSB, RW bit set to 1, ACK set to 0).

The data bits in the data frame look correct (0xA8 from MSB to LSB), but the ACK bit is high.

The target Raspberry Pi Pico program is written in such a way that every read() function will return a byte from the next element of a uint_8 array in it's memory. I am calling the read() function above inside a loop.

I see that the ACK bit is always HIGH every time this function is called. But it looks like the I2C read process itself is executing correctly, as the data read in the I2C controller's program matches the data in the I2C target's memory.

What is happening here? Am I getting the correct waveform on the SDA line?

See page 5 Sec2.3 point 4

  1. A master-receiver is done reading data and indicates this to the slave through a NACK.

ACK bit for data frames is what I expect if doing read(fd, buf, 2), with the very last data frame having ACK bit HIGH as here.

  • \$\begingroup\$ Please diagrammatize what you expected to see. \$\endgroup\$
    – Andy aka
    Commented Nov 12, 2021 at 11:05

1 Answer 1


The waveform is correct.

The target device is not supposed to send ACK at that time, on the contrary, it is the role of the MCU host to send that bit, and since it is the last byte transferred, it must be a logic high NAK bit, from the MCU to target.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.