I2C Communication issue on stm32H743zi Nucleo board

[Gopika]

 

When using the STM32H743ZI Nucleo board as the I²C master and two STM32 Blue Pill boards as I²C slaves with different addresses, the master requests data from the slaves and the slaves respond accordingly. However, I²C communication  is unreliable during initial startup, and intermittent I²C errors are observed during runtime.

Is there anyone to help me with this issue.

Thank you.

[Andrew Neil]

Welcome to the forum.

Please see How to write your question to maximize your chances to find a solution for best results.

 

---

@Gopika wrote:

Is there anyone to help me with this issue.

---

What testing/investigation/debugging have you done so far?

What have you found?

Have you looked at the I2C lines with an oscilloscope?

If they're noisy or have other "analogue" issues (including inappropriate pullup value), then it's bound to be unreliable ...

Have you looked at the I2C lines with an analyser?

Have you instrumented your code and/or used the debugger to see what's happening inside the microcontrollers?

Have you tested your Master code with some known-good slaves?

 

Note that Blue Pills are not ST products, and likely do not contain genuine STM32s.

[Gopika]

• I have tried the 9 clock pulse generation method recommended in multiple ST community forum threads to recover the I2C bus when it gets stuck. Unfortunately, this method did not resolve the issue in my case.
• During initial startup of the system i2c communication will not work.If I power OFF both boards, then power them ON again, and only perform a software reset on the master board, the I2C communication starts working correctly.Runtime missing also will be there(approximately after 1 hour of system reset).
• The master I2C is configured to use DMA mode.
• I do not currently have access to a logic analyzer, so I have not captured protocol-level traces.
• The same slave device works reliably once the master and slave is reset, indicating the slave itself is likely not at fault.

[Ozone]

> I have tried the 9 clock pulse generation method recommended in multiple ST community forum threads ...

Don't try remedies until you have identified the problem.

> However, I²C communication  is unreliable during initial startup, ...

I would suggest to investigate this issues, i.e. make a logic analyser recording.
Usually the first instance were the bus signals are not as expected are the most crucial.

Electrical issues can play a role as well.
A too large pull-up resistor value in conjunction with high bit rates makes the communication unstable as well.

[mƎALLEm]

Hello,

---

@Gopika wrote:

and two STM32 Blue Pill boards as I²C slaves 

---

Just to recall that STM32 Blue Pill boards may contain or most probably may contain a counterfeit chip. 

So I recommend you using one of the ST Nucleo boards, they contain genuine chips and they are cheap.

[mƎALLEm]

@Gopika ,

As I have a doubt about these Blue pill boards (as I said previously), you may better start using two instances of I2C on stm32H743zi Nucleo board and discard the Blue Pill boards for the moment. At least you will validate one part of the hardware and the software.