2024-02-14 07:38 PM
Hi all,
I was trying to write to the codec (WM8994) I2C3 in the STM32F746 Disco board without luck. After trying a few things and looking at the data on my scope I realized the codec was not acknowledging the address. The problem is I was using 0x68 (for writting) for the address. The 7-bit address is 0x34 and this is what worked. I left shifted it because when I read UM1905 (Description of STM32F7 HAL and low-layer drivers, bottom of page 494 picture below) it says to left shift the address before calling the interface. I'm confused. What does the "The device 7 bits address value in datasheet must be shifted to the left before calling the interface" means? Thanks.
2024-02-14 09:09 PM
"Welcome in the club of confusion" LOL.
STM seems to use a Slave Addr ad 8bit, where bit 0 is actually R/nW bit. So, a 7 bit address on b[7:1].
But a datasheet can give you a (7 bit) slave address, e.g. as 0x20 (they do not care about the bit0 as R/nW).
Now, you have to shift this, e.g. 0x20 as: 0x20 <<1 = 0x40. And provide this as the slave address (so that bit0 is "don't care", for the R/nW bit added).
A good advice, when a Slave Address does not seem to work as provided in a datasheet: try with ADDR <<1 or ADDR >>1. It depends how the HAL drivers expect a Slave Addr (it can vary from vendor to vendor).
Slave Addr is just 7bit, but as a parameter for a function call, expecting an 8bit value (e.g. uint8_t slaveAddr, even uint16_t slaveAddr), we do not know exactly if it has to be shifted (to make room for bit0 as R/nW bit).
Not a bug, just a "confusion" and not well documented HAL FW how the Slave Addr is used (as shifted or not shifted as 7bit: shifted internally).
I assume, your code will work if you take a 7bit Slave Addr from datasheet, e.g. 0x20 and you provide on HAL drivers as 0x40 (as 0x20 << 1).