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.

[Andrew Neil]

---

@Gopika wrote:

• During initial startup of the system i2c communication will not work.

---

So investigate what's happening during that initial startup.

Does the power supply take a while to stabilise, etc, etc ...

Again, have you looked at the I2C lines with an oscilloscope?

[Gopika]

During runtime, I observed that the SCL and SDA lines suddenly go high, after which the I²C data gets stuck and communication stops. This was confirmed using a DSO.

[Gopika]

During runtime, I observed that the SCL and SDA lines suddenly go high, after which the I²C data gets stuck. This condition is not present at initial startup and was confirmed using a DSO.

[Andrew Neil]

Note that everyone can see all posts - there's no need to repeat replies to each person.

You can mention multiple people in one post using '@' ...

[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.

[Andrew Neil]

---

@Gopika wrote:

During runtime, 

---

Have you resolved the issue(s) at startup ?

---

@Gopika wrote:

I observed that the SCL and SDA lines suddenly go high

---

The idle state of both lines is high.

Have you tried debugging and/or instrumenting your code to see what is happening when this occurs?

Are you sure that all connections are secure - including a good, solid common ground?

Photo(s) of your setup would help

---

@Gopika wrote:

confirmed using a DSO.

---

Please post a trace.

Be sure to use the DSO's trace capture facility - far better than a photo of the screen!

And, again, please test against a genuine STM32.