I2C communication between STM32L4R5 and esp32

[ejeee]

I tried creating I2C connection between my stm32 board and esp32. I assume it is not working because of my code, due to the wiring being so simple in I2C communication, the pull up resistor is connected externally. Do you guys see any mistake in my code that could make my I2C to not work?  I cannot figure out why it would not work.

[Hl_st]

Hello,

there seems to me two potentially problems. At first, there should be connected pull up resistor to both I2C pins (SDA and SCL). The second, you are shifting slave address 0x08 in: 

HAL_I2C_Master_Receive(&hi2c2, 0x08 << 1, &receivedByte, 1, 100)

 I would say, there should be:

HAL_I2C_Master_Receive(&hi2c2, 0x08, &receivedByte, 1, 100)

[Karl Yamashita]

---

@Hl_st wrote:

Hello,

there seems to me two potentially problems. At first, there should be connected pull up resistor to both I2C pins (SDA and SCL). The second, you are shifting slave address 0x08 in: 

HAL_I2C_Master_Receive(&hi2c2, 0x08 << 1, &receivedByte, 1, 100)

 I would say, there should be:

HAL_I2C_Master_Receive(&hi2c2, 0x08, &receivedByte, 1, 100)

---

Being that the slave address is 0x08 on the ESP32, then the OP is correct in shifting the slave address 0x08 left by 1 as indicated in the comments ST provides.

/**
  * @brief  Transmits in master mode an amount of data in blocking mode.
  * @PAram  hi2c Pointer to a I2C_HandleTypeDef structure that contains
  *                the configuration information for the specified I2C.
  * @PAram  DevAddress Target device address: The device 7 bits address value
  *         in datasheet must be shifted to the left before calling the interface
  * @PAram  pData Pointer to data buffer
  * @PAram  Size Amount of data to be sent
  * @PAram  Timeout Timeout duration
  * @retval HAL status
  */
HAL_StatusTypeDef HAL_I2C_Master_Transmit(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData,
                                          uint16_t Size, uint32_t Timeout)
{
  uint32_t tickstart;
  uint32_t xfermode;

[Hl_st]

OK, I wasn´t sure how it is on ESP32 <--> STM32 communication, but for STM32 <--> STM32 communication address shouldn´t be shifted.

[Andrew Neil]

---

@ejeee wrote:

 I assume it is not working because of my code, .

---

Don't just jump to that conclusion!

First, use an oscilloscope to what - if anything - is happening on the wires.

It could very well be a hardware problem.

That's why you need to show the schematics of your setup - see: How to write your question to maximize your chances to find a solution.

---

@ejeee wrote:

I tried creating I2C connection between my stm32 board and esp32. 

---

So which one is the Master, and which is the slave?

• Have you tested your Master against a standard, well-known, known-working Slave?
• Have you tested your Slave against a known-working Master?

Don't make the classic mistake of trying to do both ends of the link at once:

https://community.st.com/t5/stm32-mcus-products/i2c-communication-between-two-different-stm32-evk-boards/m-p/755042/highlight/true#M268963

[ejeee]

Hello,

Thank you for your advice! I did try to look at the SCL line, it shows some kind of square wave. But it seems there are a lot of noise of some sort in the SCL line. I do not have access to an oscilloscope at the moment. But, I will post my findings soon. 

Let's say I do not have access to the I2C Demo Board, what other way should I test my master and slave? Thanks for your help.

[Andrew Neil]

There are loads of low-cost "breakout" boards for common I2C devices...

[Karl Yamashita]

---

@Hl_st wrote:

OK, I wasn´t sure how it is on ESP32 <--> STM32 communication, but for STM32 <--> STM32 communication address shouldn´t be shifted.

---

That is incorrect about the STM32<>STM32. With the HAL driver, you MUST shift the slave address. That is one of the quirks of the ST's HAL I2C driver. All other companies' I2C drivers does that automatically for you.

You are forgetting about the read bit, which is set at bit 0 position. The slave devices parses the upper 7 bits for the slave address and bit 0 for the read flag. 

Think about a slave device with a slave address set as 0x09. If the master wants to read from that slave device, and without shifting, it'll send 0x09 on the bus. But the slave device will see the slave address as 0x04, not 0x09. 

And if you want to write to the slave, the master will send 0x09 on the bus, but bit 0 is set, which is a read flag, not a write.