I2C Addresses Doubled

Good Evening!

Using Make Menuconfig I set the I2C Address to my address (0x98) 0d152. On my shiny new logic analyzer, I see that the address was 0x30, followed by a NAK.

I changed the address to 0x9A, 0d154, and the address is now 0x34 followed by a NAK.

Printing the address on the lldbg seems to agree with the defconfig setting, so that is not the issue.

Some maths tells me that this means the Address that the MDK is attempting to use is double that of the one I enter... Strange indeed.

0x98 * 2 = 0x130, since the address is a uint_8t that gets trimmed off at 0x30

0x9A * 2 = 0x134, same, trimmed at 0x34.

To finish off the test I tried using 0x4C, 0d76, (half of my real address) and on the scope I see Address 0x98 followed by an ACK and data!

Success, shrouded in mystery.

Furthermore, the data (a register value from my DAC) is sent back twice after calling a single read. Not sure if anybody has ever seen that before but it is a separate issue.

Top Replies

COMPACT over 8 years ago in reply to COMPACT +1

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…

Parents

COMPACT over 8 years ago

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.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel
rdecarre11 over 8 years ago in reply to COMPACT

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)
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel
COMPACT over 8 years ago in reply to rdecarre11

What is the behaviour when you use i2c-tools?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel
COMPACT over 8 years ago in reply to COMPACT

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?
Cancel
Vote Up +1 Vote Down

Sign in to reply

Cancel

Reply

COMPACT over 8 years ago in reply to COMPACT

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?
Cancel
Vote Up +1 Vote Down

Sign in to reply

Cancel

Children

rdecarre11 over 8 years ago in reply to COMPACT

I understand. Not sure why that took so long for me to grasp. .
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel
COMPACT over 8 years ago in reply to rdecarre11

I'm glad that it helped.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel