[Archive] flash_new fails at rcc_fix ("Failed to write memory") on Windows (Unofficial xPack OpenOCD)

[luckyabsoluter]

Describe the bug

When running the flash_new command via OpenOCD on Windows using an unofficial xpack binary, the firmware successfully flashes and verifies. However, the process halts immediately after with a memory write failure during the rcc_fix procedure. The script fails to write magic numbers back into the RCC memory, throwing an error at mww 0x40002989 0x1d0f0000.

Environment:

• Target: STM32F4x
• Tool: OpenOCD Unofficial xPack binary(xpack-openocd-0.12.0-7-win32-x64.zip): https://github.com/xpack-dev-tools/openocd-xpack/releases
• OS: Windows x64

To Reproduce

Follow https://github.com/Asmageddon/airbreak-plus/blob/3a42fbc3e5f4e991a2022997cba003b57e6457de/docs/firmware.md
Steps to reproduce the behavior:

1. Connect the STM32 device via OpenOCD on a native Windows machine.
2. Execute the command: flash_new stm32-patched.bin
3. The flashing and verification process completes successfully ("Verifying that flash was written properly...").
4. The process then fails during the reset_watchdog_bit -> rcc_fix step.

Console Output / Logs

> flash_new stm32-patched.bin
Unable to match requested speed 2000 kHz, using 1000 kHz
Unable to match requested speed 2000 kHz, using 1000 kHz
[stm32f4x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800021c msp: 0x2000f000
Tickling watchdog...
device id = 0x100f6413
flash size = 1024 KiB
Resetting device...
Unable to match requested speed 2000 kHz, using 1000 kHz
Unable to match requested speed 2000 kHz, using 1000 kHz
[stm32f4x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800021c msp: 0x2000f000
Overwriting flash memory...
device id = 0x100f6413
flash size = 1024 KiB
Verifying that flash was written properly...
Unable to match requested speed 2000 kHz, using 1000 kHz
Unable to match requested speed 2000 kHz, using 1000 kHz
[stm32f4x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800021c msp: 0x2000f000
Resetting watchdog bit...
Unable to match requested speed 2000 kHz, using 1000 kHz
Unable to match requested speed 2000 kHz, using 1000 kHz
Writing magic numbers back into RCC memory...
Failed to write memory at 0x4000286c
tcl/airsense.cfg:92: Error:
Traceback (most recent call last):
  File "tcl/airsense.cfg", line 86, in flash_new
    reset_watchdog_bit
  File "tcl/airsense.cfg", line 70, in reset_watchdog_bit
    rcc_fix
  File "tcl/airsense.cfg", line 92, in rcc_fix
    mww 0x40002989 0x1d0f0000
>

Possible Cause

• The failure likely stems from the mww command requiring 32-bit alignment, which the address 0x40002989 violates, triggering memory errors specifically on Windows.
• It is ambiguous whether this is a flaw in the airsense.cfg script or the OpenOCD xPack.
• Replacing the command with the following mwb (byte-level) writes resolves the issue by bypassing alignment restrictions. Further technical context can be found: https://rsaxvc.net/blog/2018/11/24/Unaligned_Access_on_Cortex-M_Loads_vs_Stores,_M4_vs_M7.html

# Replace mww 0x40002989 0x1d0f0000 with(STM32 is little-endian):
mwb 0x40002989 0x00
mwb 0x4000298a 0x00
mwb 0x4000298b 0x0f
mwb 0x4000298c 0x1d

Workaround

As a workaround, I successfully completed the entire flashing process by running OpenOCD inside WSL (Windows Subsystem for Linux) and forwarding the USB device using usbipd. In the WSL environment, the rcc_fix completed perfectly without any memory write errors.

Additional Context

I am opening this issue primarily for archiving purposes and to help document this for other Windows users who might run into the exact same problem. I may close this issue later, but I am open to suggestions if there is a better, proper fix for native Windows environments.

[m-kozlowski]

Yeah, newer versions of openocd is more picky about write alignment and splitting it to independent byte writes is exactly what I did on my local copy.
But the truth is: I have no idea what second mww is supposed to do.
First stores "magic" in BKP_DR6, third one clears error flag from BKP_DR7.
but address 0x40002989 is odd... in every sense of the word.

[m-kozlowski]

I did some digging and I think I've found something regarding writes to 0x40002989.

The critical decision points in the boot process are roughly as follows:

1. BKP6R Gate (pre-SRAM, flash code)

• 0x1B183CA7 skip bootloader entirely, jump to app (CDX+0x204)
• anything else copy bootloader to SRAM, run it
• always restores 0x91C1D9AA after reading

2. BLX self check

• check crc16 of bootloader block and go to infinite loop on mismatch

3. BKP3R "SF" Magic

• if equals to 0x5346, value cleared to 0, set magic = true
• anything else magic = false

4. Enter flashing mode or pass-through

• magic == true OR CDX CRC != 0 OR CCX CRC != 0 -> set BKP7R = 0x7016, enter flash mode (long timeout)
• all CRCs valid and no magic -> pass-through (short timeout)

5. Timeout Expiry

• BKP7R == 0 AND (CRC valid OR state == 2) [all good or we've just finished flashing] -> write 0x1B183CA7 to BKP6R, reset (and skip bootloader)
• otherwise system_reset_now(). (at this point BKP7R is != 0, so basically go into bootloop)

6. UART flash completion frame (0x0F)

• clear BKP7R
• system_reset() - full reboot into new firmware

And that's it.
So from the bootloader’s point of view, BKP6R and BKP7R should be cleared. Maybe BKP3R as well, but that’s another topic…

But...
During analysis I noticed that 0x1D0F0000 is constantly present in BKP18R.
The address of BKP18R...

0x40002898
        ^^

So this looks like a typo. Seemingly not very critical, as nobody has noticed it since 2020.