I2C spuriously not working after NRST reset on STM32L4 requires reprogramming

[mkrug]

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

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

[Tesla DeLorean]

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.

[Karl Yamashita]

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