I2C problem on some devices on STM32L432 but not STM32L433

[Peter Mather]

I've got an issue that the STM32L432 on the Nucleo running a simple I2C I/F isn't working with a DHUT21 when exactly the same code on the 433 is fine. The same I2C code on both chips works fine with a BMP180 and many other devices. This is reproducible across some but not all Nucleo-L432 boards - some work OK with the DHUT21. The signals look fine except that the sensor is NAKing the address on the 432. Any ideas appreciated.

[waclawek.jan]

The 'L432 and 'L433 I2C should be identical, so the difference lies in the external circuitry.

From the waveforms you've posted, SDA changes a tad bit too soon after SCL falling edge to my liking. Try to increase I2C_TIMINGR.SDADEL .

JW

PS. Isn't it DHT21 rather than DHUT21?

[Peter Mather]

Thanks for the suggestion. Adding delay makes it work BUT only when the scope is connected to SCL!

It looks like there is something funny about STM32L432KC (32-pin) and also the DHTU21 (a poor I2C implementation?) and together....

I can replicate the problem both on the Nucleo and on a breadboarded STM32L432KC

Interesting on the new scope trace is that while I2C_TIMINGR.SDADEL affects the change of SDA after clocks 0-6 it does not change the timing of clock 7 when SDA is released immediately on the downgoing edge of the ACK/NAK clock pulse

UPDATE fixed by adding 56pF between SDA and GND - I think the issue is the very fast release of SDA after the last clock

[waclawek.jan · Accepted solution]

> only when the scope is connected to SCL

Sounds like crosstalk between SDA/SCL, and/or grounding problem.

If pin speed in GPIOx_OSPEEDR is set to high, set it to lower/lowest.

JW

[Peter Mather]

Set to very_high by CubeMX changed to LOW and now working without the added capacitance - many thanks