Second Chance

A field-deployed data logger reboots unexpectedly. Remote support needs to know why. On every boot the firmware must read the RCC clock/status register to determine the reset cause, log it over UART, then arm the Independent Watchdog so the system can self-recover from future hangs.

The starter code attempts this but always reports the wrong reset cause. Find and fix all the bugs.

STM32F4 RCC_CSR (in the RCC peripheral block) reset flag bits: Bit 31: LPWRRSTF (low-power reset) Bit 30: WWDGRSTF (window watchdog reset) Bit 29: IWDGRSTF (independent watchdog reset) Bit 28: SFTRSTF (software reset) Bit 26: PINRSTF (external pin reset) Bit 25: PORRSTF (power-on / power-down reset) Bit 24: RMVF (write 1 to clear all flags)

After reading the flags, request a clear by OR-ing RMVF into the register with a read-modify-write. Do not write zeroes over the flag bits: the grader reads RCC_CSR after the run finishes and the power-on flag (PORRSTF) must still be present there. More-specific reset sources (IWDG, WWDG, software) should take priority over generic flags (POR, PIN) since those are always set alongside them.

On a normal power-on boot, the firmware reports the reset cause ("RESET:" plus the short source name, e.g. POR), confirms the watchdog is armed, prints one "CYCLE:<n>" line per main-loop cycle (1 through 3), and finishes with a status line. The starter code already contains every print statement; the bugs are in the flag logic.