[SR5E1E7 Custom Board] How to load program to FLASH?

[nhatnguyen304]

Hello everyone,

I am bringing up a custom motor control inverter board based on the  STEVAL-TTM001V1 evaluation kit. I am using StellarStudio, OpenOCD, and the Stellar Motor Control Tool Kit (MCTK with StellarESDK-1.7.0).

The Problem: My firmware runs perfectly when launched via a Debug session in StellarStudio. I can step through the code, initialize peripherals, and hit my main loop. However, if I disconnect the debugger and power-cycle the board (or press the physical Reset button), the application completely fails to start.

What I have verified so far:

1. Flash Linking: My linker script is correctly pointing to Flash (core1_nvm at 0x08000000). OpenOCD successfully flashes and reports ** Verified OK **.

2. The Trap Location: If I power-cycle the board, let it fail, and then hot-attach the debugger without resetting, I find the PC is trapped in an infinite assembly loop.

3. No Hardware Faults: While trapped in this loop, I checked the CFSR register (0xE000ED28), and it reads 0x00000000. This indicates no MemManage, Bus, or Usage faults occurred. It appears to be a software trap (like Error_Handler or Default_Handler).

My Question: Why would the SR5E1E7 successfully execute code when initialized by the OpenOCD debug sequence, but drop into a software trap during a standalone reset? Are there specific UTEST, Boot Assist Flash (BAF), STCU, or Watchdog configurations required in the ESDK to allow standalone booting on a custom SR5E1 board?

Any guidance on what the debugger is doing differently than the standalone bootloader would be greatly appreciated!

[db16122]

Please check the reset/interrupt related voltage setting during your power cycle. It could be lead to software error during power up

[jakson]

This issue is usually caused by option bytes or boot configuration — the debugger overrides boot pins/clock settings that aren't applied during a standalone reset.

Quick checklist:

• Check option bytes: Boot address must be set to FLASH (0x08000000), not RAM/loader. Debuggers sometimes force their own boot vector.
• Clock config: If HSE/PLL init fails standalone (since the debugger keeps the clock stable during attach), it can trap in Default_Handler.
• Watchdog (IWDG/WWDG): Debug sessions usually freeze the watchdog, standalone doesn't. If init isn't done before timeout, it resets/traps.
• BAF/UTEST/STCU settings: Wrong Boot Assist Flash config on SR5E1 can block standalone boot even though the debugger force-attaches fine.

Fix approach: Verify option bytes (especially BOOT_LOCK and boot address), then put a breakpoint or LED toggle inside Error_Handler to pinpoint exactly where it traps — then check that peripheral's init sequence (clock timeout and watchdog are the most common culprits).