Skip to main content
M
mkrug
Visitor II
December 13, 2024
Solved

I2C spuriously not working after NRST reset on STM32L4 requires reprogramming

  • December 13, 2024
  • 3 replies
  • 1151 views

Hello everbody,

I'm using the STM32L4KC Nucleo board. Accidentially I discovered something that I cannot understand so far.

I have a small application that is reading sensor data on I2C. So far everything works. When I cause by purpose some interrupts (using the button on that board) I realize that the application is not longer able to read from I2C. It simply stops after expecting a ACK from the sensor chip at the very first sensor reading (ID of the sensor). Further resets on NRST don't fix the problem. Physically disconnecting the sensor (therefore power off/on) don't fix the problem. 
Power down/up the Nucelo board don't fix the problem. The only thing that reliably fix the problem is to reprogramm the STM32L4KC. 
I saw something in the erata that says don't programm the flash durint power down. However, I'm not writing to the flash at all. 
Even more strange to me is the dependency on the programming tool. The problem described above can be fixed reliable using STM32CubeIDE. It doesn't work if I use the SEGGER JFlashLite tool. 

Anybody any idea?
Best Regards
Markus

    This topic has been closed for replies.
    Best answer by TDK

    If SDA is stuck low due to a slave chip being out of sync with the bus, you will have to cycle SCL until the slave releases SDA. Toggling NRST will not clear this.

    Otherwise, resetting the chip will clear the issue. Nothing about the I2C configuration is non-volatile.

    Thing only working with one programmer and not the other doesn't add up. The chip doesn't care which programmer is used to write the flash. I'd recheck your assumptions here. Debugging the code to see where it is stuck can also help.

    3 replies

    T
    TDKAnswer
    Super User
    December 13, 2024

    If SDA is stuck low due to a slave chip being out of sync with the bus, you will have to cycle SCL until the slave releases SDA. Toggling NRST will not clear this.

    Otherwise, resetting the chip will clear the issue. Nothing about the I2C configuration is non-volatile.

    Thing only working with one programmer and not the other doesn't add up. The chip doesn't care which programmer is used to write the flash. I'd recheck your assumptions here. Debugging the code to see where it is stuck can also help.

    T
    Tesla DeLorean
    Graduate II
    December 13, 2024

    Slave I2C devices typically don't have their own async reset input, so won't reset with the MCU

    If you've got slave devices into odd states, perhaps you need to clock them out, or look very carefully at mode pins for SPI vs I2C operation, or non-volatile settings / modes.

    You lack specificity as to the device or connectivity in the circuit, so no much to go on.

    M
    mkrugAuthor
    Visitor II
    February 5, 2025

    Hi,

    I guess your answer comes quite close to the truth. The I2C device is sending with a comparable high rate (each 20ms about 700Bytes. I guess If I reset the STM32 side during a I2C msg reception the I2C device is getting 'confused'.  I have not further investigated why reprogramming is fixing the issue. 
    Actually, the more my application has been grown - the less I'm observing the issue. So maybe I did something else wrong and cured it accidentially in the meantime. 
    Nevertheless - from another micro I learned that 'clocking out' might help in situation where the I2C slave is not responding. So I will implement that to get some additional safety margin.

    Thanks all for your suggestions
    Markus

    K
    Karl Yamashita
    Graduate II
    December 13, 2024

    You need to show some code. No telling what you're doing in code.

    Terms & ConditionsAccessibility statement