Skip to main content
Explorer
August 20, 2026
Solved

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

  • August 20, 2026
  • 2 replies
  • 92 views

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!

Best answer by 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).

2 replies

Associate II
August 27, 2026

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

jakson
jaksonBest answer
Visitor II
August 27, 2026

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).