I2C Addresses Doubled

I suspect that you are suffering from confusion (not just your own ) about what is the I2C address.

Download the official I2C spec from

https://www.i2c-bus.org/specification/

and on page 13 (amongst others) you'll see that the first byte in a message from the master contains the address in the most significant 7 bits but that the R/W bit is in position zero. (The page 13 diagram helpfully numbers the bits in a weird way.)

The address is in bits 7  down to 1 so an address of 0x10 (b00010000 looks like b0010000x  where x is the R/W bit. If your logic analyser is not I2C aware it won't get this.

The confusion arises because you can either say the address is the code sent in the byte with bit zero masked out or that it is encoded in the 7 most significant bits. I hope this helps but I won't go so far as to hope that it's clear !

MK

Thanks Michael, I double-checked my settings and took another trace this morning.

Blurry, but this is the `write` to an address set in menuconfig as 0d76 (0x4C).

SCL is the second trace, counting bits shows address (TX'd MSB-first) 0b1001100 + 0 at the end for a write operation. That is 0x98...

Ramlog Shot - (ignore tfa9890, I am re-writing the previous tfa9890 driver)

You can see the driver echoing the i2c_addr as 0x4C.

Thanks again.

Robert

What is your exact device, I'd like to see the data sheet for it?

It appears that you added the "Volume set to," is that working properly?

For the rev check, did you update the source so it's actually trying to read the version of that chip, and update the value it's checking against?

Finally, there are multiple i2c busses, are you sure you attached to and configured the proper one?

The device is a PCM5142. Page 56 of this:

http://www.ti.com/lit/ds/symlink/pcm5142.pdf

The Volume set to... is the lines I have added to just read a register (0x3D/3E). That works fine. The Rev check is beyond what I was editing and again, not applicable because this device has no ID registers. I just left it in the code because right now I don't care what it does.

The I2C bus is right. The traces I took were captured from the  PCM5142's SDA and SCL pins. I can see the STM32 sending the i2c commands and the PCM responding.

This is mostly just trying to figure out why the Address is set in Menuconfig to 0d76 (0x4c), but what is actually sent is a 0x98.

The PCM5142 is looking for a repeated start condition in the midst of a register access (read) so you'll have to generate one.

Have a look 8.4.1.1.2.6 Timing Characteristics of the data sheet.

From your pictures you're not generating one.

i.e. a falling edge of SDA followed by a falling edge of SCLK.

I appreciate the input. The previous screenshot was about the Address, not about the register read. I was trying to keep this one on the topic of the strange Address behavior.

I double checked the rest of my I2C exchange and I do in fact have the repeated start. See this other forum about why the 5142 is not behaving.

https://e2e.ti.com/support/data_converters/audio_converters/f/64/t/578178

Just to maintain one problem at a time :

I would like to focus on the fact that even when I put 0d76 (0x4c) in the Menuconfig, the stm32 sends a 0x98 as an address. (depicted in the waveform above)

What is the behaviour when you use i2c-tools?

It's already been said - There are two schools of thought for I2C addresses.

1. Treat the 7 bit address field as though it is left padded with a 0 and ignore the R/~W bit. (Range 0x00-0x7F)

(As used by Linux)

2. Treat the 7 bit address field combined with the R/~W to form an 8 bit address. (The physical byte transmitted).

(i.e. Range (0x00-0xFF) with even addresses for writes and odd addresses for reads.)

Does this explain your doubling of I2C addresses?

I understand. Not sure why that took so long for me to grasp. .

I'm glad that it helped.