[Resolved] Stock firmware boot failure: Interaction with external EEPROM?

[luckyabsoluter]

I recently encountered a soft-brick scenario after flashing a bad firmware. I am sharing my findings regarding a strange flash corruption issue that seems closely tied to the external EEPROM, and I would appreciate any insights from the community.

🐛 Symptoms

• Stock Firmware: After flashing the stock firmware, the device fails to boot completely. There is no boot logo, the LCD remains completely black, and only the power LED blinks.
• Patched Firmware: A patched firmware that bypasses the CRC checks boots and operates perfectly fine.
• "Erase Data" Ineffective: Even after booting successfully via the patched firmware, executing "Erase Data" from the device settings, and reflashing the stock firmware, the boot failure persists.
• No Bad Sectors: To rule out hardware failure, I performed a manual erase of the flash memory. The subsequent dump showed a clean state of all 0xFF, confirming that there are no bad sectors and the memory cells are functioning correctly.

🔍 Technical Observations

To investigate the stock firmware boot failure, I dumped the flash memory after writing the stock firmware to the STM32.

• Flash Corruption: The dumped binary did not match the flashed stock firmware. Specific addresses had their values changed, and the exact locations of these changes varied slightly each time.
• Bit-level Behavior: Upon closer inspection, the altered bytes were consistently changed to 0x00. Given that erasing STM32 flash sets bits to 1 (0xFF) and writing pulls them to 0 (0x00), this indicates that active write operations are occurring to corrupt the flash memory.
• Patched vs. Stock: If I flash the CRC-bypassed patched firmware, boot the device, and dump it later, the flash memory remains 100% intact.
• The Anomaly: Strangely, if I flash the stock firmware and attempt to dump it immediately—without even intentionally trying to boot the device—the flash values are already altered.

🤔 Hypothesis

Based on these observations, my hypothesis is that the CRC-related logic reads the state of the external non-volatile storage (EEPROM) and actively modifies (corrupts) the STM32 flash memory based on those values.
However, there are still some questionable aspects to this mechanism. It is highly unlikely that the firmware's CRC-related logic could execute before the device even attempts to boot.

🚀 Takeaways & Next Steps

1. Backup is critical: The key lesson here is that backing up the EEPROM is essential. It appears that certain EEPROM states can force the device into an unbootable state when running stock firmware.
2. Developing a Dumper Payload: To investigate this further, I plan to develop a custom payload/firmware that will allow us to freely read, dump, and analyze the EEPROM directly through the STM32. This will eliminate the need to physically desolder the EEPROM chip for analysis.

If anyone has knowledge about this specific EEPROM interaction or has ideas regarding the payload development, please feel free to share your thoughts.

[m-kozlowski]

Are you sure your "stock" firmware is valid?
Does it have proper checksum for controlled blocks? (crc16-ccit-false for 0x8000000, len 0x4000; 0x08040000, len0xc0000; 0x08004000, len 0x3c000)

[m-kozlowski]

I've had only two cases of eeprom relatated boot failures: First when I tried to manually edit files on fat12 volume and messed up and second when I soldered eeprom chip upside down. Other than that I find firmware to be rather forgiving: when it detects product code change it simply reverts to default settings. Even after erasing the whole chip it simply recreates everything from scratch (of course device specific info/calibration data is lost).
Service manual indicates that there are some eeprom issues that resmed considers critical, but even then device boots and displays message.

I'm not convinced that your problem is actually related to the EEPROM. I would rather suspect that some "bad state" flags in the RCC registers were set, survived the reboot and prevent stock firmware from booting. (fix_rcc should clear them after flashing, but maybe something went wrong?)

Are you able to reproduce it?

[luckyabsoluter]

You were right. Writing 1 and then 0 to Registers - RCC - BDCR - BDRST solved the problem. It successfully booted up normally, and the firmware was not corrupted upon dumping.

Writing 1 to RCC - CSR - RMVF had no effect.

The bad news is that the date information was wiped. If we can figure out the exact information that needs to be changed without going through BDRST, we might be able to avoid erasing the date.

[luckyabsoluter]

Additionally, I should clarify that I am using STM32CubeProgrammer instead of OpenOCD for this.

[m-kozlowski]

Additionally, I should clarify that I am using STM32CubeProgrammer instead of OpenOCD for this.

So that's why you ran into this issue in the first place. flash_new in openocd calls rcc_fix that should fix BKP registers after flashing.

Today I'm planning to push PR with firmware integrity fixes for airbreak generated images, so this shouldn't be a problem anymore (unless you modify something by hand later).

As for the BKP registers, here's what i found so far:

register	desc
BKP_DR1	Written with 0x7231 at boot (boot_check_rtc_config_setup)
BKP_DR2	state flag based on averaged values read from ADC (FUN_080028ee) most likely RTC battery votage vs VREF
BKP_DR3	some one shot trigger ("SF") consumed in rtc_check_magic_bkp0r_3()
BKP_DR6	Bootloader "handshake? (?). theres some value juggling here between bootloader code and main firmware code (magic1=0x91C1D9AA, magic2=0x1B183CA7). Bootloader enters infinite loop if read value != magic2 (bringup_clock_and_prepare_to_party)
BKP_DR7	firmware status register. I believe that 0x6006 means "update in progress", 0x70xx are error states (flashing error, crc error...). read by boot_crc_validate_config()

[nickarcade]

Additionally, I should clarify that I am using STM32CubeProgrammer instead of OpenOCD for this.

Try using ST-Link software on Windows instead of STM32CubeProgrammer and see if you get any success that way. I found that cube programmer was inconsistent when flashing different firmware compared to ST-Link.