STM32CubeIDE Exception Traps Must Agree with Standalone Firmware

A deliberately faulty operation stops cleanly in STM32CubeIDE, yet the same firmware behaves differently after a cold start without the debugger. Before blaming optimization or the fault handler, compare the exception policy established by the debug launch with the policy established by application startup. The debugger can help expose a fault without proving that the standalone image enables the same detection.

This article uses STM32CubeIDE UM2609 Rev 18, June 2026, and the Cortex-M4-specific PM0214 Rev 10, March 2020. Register details must be checked against the actual core; they are not a universal STM32 recipe. The proposed checks have not been run on a target.

Separate trapping from stopping in the debugger

UM2609 section 3.1.2.4 describes launch options for divide-by-zero exceptions, unaligned-access exceptions, and halting on exceptions. It explicitly says that application software must enable the relevant traps when they are also required outside debugging. The launch configuration is therefore part of the experiment, not evidence that the firmware initialized those controls itself.

Separate three questions: does the operation create a processor fault, which handler receives it, and does a connected debugger halt execution? These outcomes can differ. A source window stopping at a useful instruction establishes something about that session, but it does not demonstrate the product’s standalone recovery or diagnostic-storage behavior.

Record the exact launch options used when reproducing the symptom. Avoid changing exception settings halfway through an investigation without preserving the previous result. Otherwise two engineers can run the same ELF and obtain different observations while assuming their debug environments are equivalent.

Inspect the firmware-owned policy

On the Cortex-M4 covered by PM0214 sections 4.4.7 and 4.4.11, SCB->CCR contains DIV_0_TRP and UNALIGN_TRP. The manual distinguishes these controls from operations that always fault on unaligned addresses. Its section 2.4.2 also explains that a fault whose configurable handler is disabled escalates to HardFault.

Search the actual startup and initialization sources for the intended register policy. Record when it becomes active and whether later initialization rewrites it. Include a bootloader or RTOS initialization path when the product uses one. A statement in application code is not enough if the fault can occur before that statement executes or another stage changes the register afterward.

Do not enable every trap as a cosmetic way to make a demonstration pass. Decide what the product requires, check the software assumptions affected by that decision, and implement the supported policy in privileged startup code using the correct device/core definitions. Unaligned-access behavior deserves special care because the instruction, address region, and software contract all matter.

Original comparison diagram. The same image can be observed under different launch-established conditions.

Build a controlled comparison of startup paths

Use an isolated development target with outputs placed in a safe condition. Preserve one diagnostic image and its ELF identity for the comparison. Define the observation point after the intended firmware initialization and before the deliberate test operation. Record relevant control and fault-status evidence through a method whose own effects are understood.

Compare a normal debug launch with a true standalone startup. Do not substitute a debugger restart command for power-on behavior without establishing what it resets and what it leaves behind. Attaching later to inspect registers can itself influence the experiment, so prefer a suitable retained record or independent diagnostic path when available, and document any unavoidable intervention.

A useful result identifies the register policy before the operation, the fault status afterward, and the route through the handler or recovery logic. Simply reporting that one run stopped and another continued leaves the causal question unanswered. Preserve the image identity and startup mode with each record so a rebuilt test binary cannot silently enter the comparison.

Choose a test the compiler cannot reinterpret

A naive C integer expression dividing by zero is not a reliable instruction-level processor test. WG14 N1570, section 6.5.5, specifies undefined behavior for division by a zero operand; the compiler can therefore invalidate the intended experiment. Likewise, an invalid typed pointer cast is not a sound general-purpose test of architectural unaligned access. Review the emitted instructions and use an architecture-aware diagnostic fixture approved for the chosen core and toolchain.

Keep that fixture out of ordinary production execution. It should have a clearly bounded entry path and a recovery plan appropriate to the board. Do not perform deliberate faults while the firmware controls an active motor, heater, or other hazardous load. The objective is to qualify diagnostic behavior, not to discover how the physical system reacts to an uncontrolled stop.

Deliver fault handling rather than a successful halt

After the trap policy is explicit, test the intended standalone consequence. Does the product retain enough fault context, move outputs to the required state, and recover or remain stopped according to its design? Does a reboot preserve or erase the evidence? These are application decisions that the IDE’s fault view cannot implement on behalf of deployed firmware.

The handover should include the startup policy, relevant launch settings, diagnostic fixture restrictions, image identity, and actual comparison results when obtained. A debugger-assisted stop is useful during development. Standalone fault behavior becomes a supported claim only when the firmware owns the required configuration and the product’s response has been verified without relying on the launch to supply it.