I2C slave register address not updating using HAL_I2C_Mem_Read function
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-06-17 3:36 AM
Hello,
I am new on the embedded subject, and I need some help.
I want to practice I2C communication, so I connected Nucleo-L4P5ZG (master), and MAX6604EVKIT (slave), the general goal is to read registers and send the result via UART.
I used the STM32cubeMX to generate the initial code.
I used the HAL function " HAL_I2C_Mem_Read" to read register in address 0x6.
Build process went without errors.
During debug, when looking at the scope, it seems that the MCU don't change the register address to 0x6, and it is stuck on 0x0.
The slave address is correct, and I receive ACK (0 logic).
I am attaching the main.c.
Do you know what seems to be the problem?
Thanks
Shay
Solved! Go to Solution.
- Labels:
-
STM32CubeMX
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-06-19 5:45 AM
> I2C_MEMADD_SIZE_16BIT
After the address, it sends 0x00 and then 0x06. That is exactly what it should send for the 16-bit address of 0x06.
Since MAX6604 has 8-bit addresses, not 16, you should use I2C_MEMADD_SIZE_8BIT.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-06-17 5:57 AM
Show the code and show the scope trace. The HAL_I2C_Mem_Read function works as intended, has to be another explanation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-06-19 2:15 AM
Hi TDK,
Thanks for responding.
The scope images are attached.
This is the code:
void ReadFromI2C()
{
uint16_t Devaddr = (0x18 << 1) | 0x01;
uint16_t MemAddress = 0x6; // Memory address to read from
uint8_t pData[2]; // Buffer to store the read data
uint16_t Size=2;
uint32_t Timeout = 10000; // Timeout duration in ms
HAL_StatusTypeDef status;
status=(HAL_I2C_Mem_Read(&hi2c1, Devaddr, MemAddress, I2C_MEMADD_SIZE_16BIT, pData, Size, Timeout) != HAL_OK);
// Check for success
if (status == HAL_OK) {
// printf("Device is ready for communication.\n");
// Successfully read data, process read_buf as needed
} else {
// printf("Device is not ready or not responding.\n");
// Handle error
}
}
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-06-19 5:45 AM
> I2C_MEMADD_SIZE_16BIT
After the address, it sends 0x00 and then 0x06. That is exactly what it should send for the 16-bit address of 0x06.
Since MAX6604 has 8-bit addresses, not 16, you should use I2C_MEMADD_SIZE_8BIT.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-06-19 3:47 PM
This does not affect the actual data on the bus, but you don't need to, and should not, set the LSB of the device address. The STM32 HAL code expects the 7-bit I2C address in the upper 7 bits with the LSB=0. The HAL code will set/clear this bit as needed for read and write operations.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-06-19 5:00 PM
Assuming I2C1.jpg is the start of the data, the first write to the slave address 0x18 should not have the read bit set. But you can see in the image, the 8th bit there is glitch where the data is high, but it should be a low since it's a write. \
It might have to do with how your setting up the slave address
uint16_t Devaddr = (0x18 << 1) | 0x01;
// instead, do it like this. The HAL driver will take care of the read/write bit automatically.
uint16_t Devaddr = (0x18 << 1);
Don't worry, I won't byte.
TimerCallback tutorial! | UART and DMA Idle tutorial!
If you find my solution useful, please click the Accept as Solution so others see the solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-06-23 3:55 AM
Thanks,
That solved the problem.
I somehow missed it.
Shay
