STM32F411CEU6 IWDG_RLR cannot be updated: RVU remains set and RLR stays at 0xFFF

[wangkang111333]

Hello, I am working on an STM32F411CEU6 and I am trying to configure the Independent Watchdog (IWDG) directly through registers. I have encountered a problem where IWDG_RLR cannot be updated. My MCU information is: - MCU: STM32F411CEU6 - Device ID: 0x431 - Revision ID: 0x1000 - IDCODE: 0x10006431 - HCLK: 16 MHz - PCLK1: 16 MHz - System clock: default HSI 16 MHz - LSI: enabled and ready I am using the following register-level code: RCC->CSR |= RCC_CSR_LSION; while (!(RCC->CSR & RCC_CSR_LSIRDY)); IWDG->KR = 0x5555; IWDG->RLR = 250; uint32_t sr1 = IWDG->SR; while ((IWDG->SR & IWDG_SR_RVU) && timeout++ < 1000000); uint32_t sr2 = IWDG->SR; uint32_t rlr = IWDG->RLR & 0xFFF; The result is consistently: SR immediately after writing RLR: RVU = 1 SR after waiting for the update: RVU = 1 RLR: 0xFFF In other words, RVU never clears and RLR remains at its reset value of 4095. I have also verified that the IWDG itself is working. Test 1: PR = 0 RLR = 0xFFF The watchdog resets the MCU after approximately 0.5 seconds, which agrees with: 4096 * 4 / 32 kHz ≈ 0.512 s Test 2: PR = 6 RLR remains 0xFFF The watchdog resets the MCU after approximately 30+ seconds, which is consistent with: 4096 * 256 / 32 kHz ≈ 32.8 s Therefore, the LSI and IWDG counter appear to be working correctly. However, RLR cannot be updated. I also checked the STM32F411 errata sheet (ES0287), which mentions an IWDG issue where RVU may remain set if the APB clock is less than twice the IWDG clock. However, in my case: PCLK1 = 16 MHz LSI ≈ 32 kHz so: PCLK1 >> 2 × LSI Therefore, this condition does not seem to apply. I have also tried disconnecting the ST-LINK debugger and powering the board independently, so I don't think debugger freeze is involved. My questions are: 1. Is there any known issue with IWDG_RLR/RVU on STM32F411CEU6 with revision ID 0x1000? 2. Is there any additional condition required before writing IWDG_RLR? 3. Why would RVU remain set indefinitely even though PCLK1 is 16 MHz? 4. Could this indicate a silicon issue or a specific erratum for this revision? Any advice or clarification from ST would be greatly appreciated. Thank you.

The following values were read directly from the MCU: IDCODE = 0x10006431 DEV_ID = 0x431 REV_ID = 0x1000 SystemCoreClock = 16000000

Testcode:IWDG->KR = 0x5555; IWDG->RLR = 250; sr1 = IWDG->SR; t = 0; while ((IWDG->SR & IWDG_SR_RVU) && t++ < 1000000); delay_ms(50); sr2 = IWDG->SR; rlr = IWDG->RLR & 0xFFF;

Result:H1 = 2 H2 = 2 T = 4095

[playwithyuzu]

One thing worth checking is the exact STM32F411 revision against the latest reference manual and errata, because the IWDG register update mechanism is asynchronous and RVU can remain set when the update handshake is not completing. I’d also verify that the write to KR = 0x5555 occurs before RLR, that no reset/debug configuration is affecting the watchdog clock domain, and test the same code with a minimal project using the current STM32CubeF4 headers. Since PR changes the timeout but RLR remains 0xFFF, the IWDG itself appears functional while the reload-register update synchronization is the part that needs investigation.

[wangkang111333]

Thank you. I have already checked most of these points. The test was performed with: STM32F411CEU6 DEV_ID = 0x431 REV_ID = 0x1000 IDCODE = 0x10006431 HCLK = 16 MHz PCLK1 = 16 MHz LSI ≈ 32 kHz The code is: IWDG->KR = 0x5555; IWDG->RLR = 250; Immediately after the write: RVU = 1 After waiting for a long time: RVU = 1 RLR = 0xFFF I also tested with the ST-LINK disconnected and without DBGMCU->APB1FZ IWDG freeze configuration, but the result was the same. I also verified that the IWDG itself works: PR = 0, RLR = 0xFFF → about 0.5 s reset PR = 6, RLR = 0xFFF → about 30+ s reset So I believe the problem is specifically related to the RLR update synchronization. Could REV_ID = 0x1000 have any known IWDG/RVU issue on STM32F411?

[wangkang111333]

After further investigation, the problem has been solved. It turned out to be a timing/sequence issue.

The correct sequence is to start the IWDG first (by writing 0xCCCC to KR) and then update the reload register, similar to how the HAL library handles the initialization flow.

My original code attempted to write IWDG_RLR before enabling the watchdog, which caused the RVU flag to stay set forever. Once I changed the order – first IWDG->KR = 0xCCCC, then unlock with 0x5555, write RLR, and properly wait for RVU to clear – the reload value was accepted and the RVU flag cleared normally.

For anyone encountering the same issue, here's the working sequence:

c

// Enable LSI and wait for readyRCC->CSR |= RCC_CSR_LSION;while (!(RCC->CSR & RCC_CSR_LSIRDY));// Start the IWDG firstIWDG->KR = 0xCCCC;// Then unlock and configure PR / RLRIWDG->KR = 0x5555;IWDG->PR  = 6;IWDG->RLR = 250;while (IWDG->SR & (IWDG_SR_RVU | IWDG_SR_PVU));// At this point the reload value is updated correctly

This works reliably on my STM32F411CEU6 (Rev A, REV_ID 0x1000). I believe the hardware expects the watchdog to be in a running state before the reload register can be safely modified; otherwise, the RVU flag can get stuck, especially on this silicon revision.

Thanks to everyone who helped with suggestions and documentation references.