Watchdog doesn't fire while hanging in I2C

Forum|Forum|8 months ago
June 9, 2025
3 replies
826 views

Hi,

I have a situation where the configured watchdog on my STM32L031 does not trigger even though the MCU gets stuck in an I2C function. In my program flow, I first run through some initializations (as well as I2C_Init()) and then start the IWDG (Start_WDG()). I then try to establish an I2C connection to another device. In some cases this fails and I get stuck on line "while(!(I2C1->ISR & I2C_ISR_TXIS));". Surprisingly, in this situation the watchdog does not trigger as expected. I am of course aware that the code in this form is not properly programmed and error handling in this situation solves the problem (implemented a timeout which itself does a system reset). Nevertheless, it would be interesting to know why the IWDG in this version does not trigger.

I2C Transmission.png

Start IWDG.png

I2C Init.png

Thanks in regard.

Greetings from Salzburg

This topic has been closed for replies.

J

JohannesK

Explorer

Hi @Brigei !

Do you enable the clock LSI (disabled after reset) for the IWDG? The IWDG requires this clock source. Can be done in RCC->CSR register by enable bit LSION and wait until LSIRDY flag is set by hardware.

Greetings from Graz.

B

BrigeiAuthor

Visitor II

Yes LSI is enabled. When IWDG is enabled then, according to de reference manual, the LSI can't be disabled any more. So there shouldn't be a problem with that.

J

JohannesK

Explorer

@Brigei wrote:
Yes LSI is enabled. When IWDG is enabled then, according to de reference manual, the LSI can't be disabled any more. So there shouldn't be a problem with that.

Okay. Yes I know that the LSI can't be disabled.

About the LSI and the IWDG:

Tried it now on a STM32H745 and it's seems not necessary first to enable LSI before writing to the IWDG registers. Seems the IWDG enables the LSI automatically. Didn't know that before, because I never used the watchdogs.

But about your project:

Is it really necessary to use the watchdog when I2C hangs? Because the watchdog resets the whole system. Wouldn't it be better if you use a timeout in your while loop and return an error code? And maybe retry the I2C communication? And as @Andrew Neil mentioned where you refresh the watchdog periodically? I had a similar issue on AVR devices because I didn't refresh the watchdog. Therefore the MCU always resets.

K

KnarfB

Super User

Don't see issues with your Start_IWDG() code, provided Update_IWDG does the right thing.

The first line will freeze IWDG when the debugger halts the MCU. Did you try without debugger attached? How did you then find out that the MCU "get stuck on line ..."

hth

KnarfB

PS: Better use the "insert code sample button" for inserting code here.

B

BrigeiAuthor

Visitor II

The "Update_IWDG" is a definition with "IWDG->KR = 0xAAAA".

When I analyze the whole thing with the debugger, I initially just let the program run. When I then press "pause," the program counter always points to the while loop.

If I try the whole thing without a debugger, the MCU also doesn't behave as expected. For example, it doesn't respond to a button press, which should trigger something else (the ISR is most likely executed correctly, but it has no effect because after the ISR, it jumps back to the while loop). If a reset were to be triggered by the IWDG, I would certainly detect it via the reset control bits.

So for me it's clear that the MCU gets stuck and the IWDG doesn't fire. I read somewhere that the I2C peripheral, when totally busy, could block the WDG. Could that really be?