Skip to main content
Identify and resolve issues observed during MCU bring-up, interface usage, and power transitions by using structured debug and isolation techniques. Focus on narrowing failures to their root cause, validating assumptions against known-good behavior, and capturing reliable debug evidence. This helps you troubleshoot problems efficiently, reduce iteration time, and restore stable system operation with confidence. 10.1 Fix a boot failure Isolate the most common causes of early MCU boot failure without jumping straight into deep debug. Prerequisites ■ Access to logs or debug state very early in boot. ■ The built image, symbols, and map file used for the failed run. Procedure
  1. Confirm the host loaded the intended image and that the reset vector or handoff configuration matches the build.
  2. Check whether clocks, the CX rail, and DDR access are available when the MCU starts.
  3. Verify that the default image can execute from DDR before you debug a customized image.
  4. Compare a failed run to a known-good baseline log.
  5. If the failure persists, capture a fault dump, register state, or trace snapshot before you change more variables.
Expected result. You narrow the failure to a loading problem, a platform dependency problem, or a software initialization problem. 10.2 Fix a peripheral failure Isolate whether a failed transfer comes from routing, configuration, missing dependencies, or the peripheral itself. Prerequisites ■ A known-good board path or device if one is available. Procedure ■ Confirm the target serial engine, GPIO path, or device binding matches the hardware you intended to test. ■ Validate interrupt routing and platform votes or dependencies for the full transfer duration. ■ Reduce the test to the smallest known-good transaction. ■ Check whether the path fails with a clear status such as timeout, NACK, or completion error. ■ Only after the basic path works, add larger payloads, extra interrupts, or GPI. Expected result You can tell whether the failure sits in basic interface setup, the external device, or the optional optimization layer. 10.3 Fix an interrupt or wake issue Isolate problems where the event never arrives, arrives with the wrong polarity, or wakes the
system inconsistently.
Prerequisites ■ A repeatable event source such as a GPIO stimulus or timer event.
Procedure
  1. Confirm the physical event really toggles or asserts as expected on the line.
  2. Check interrupt routing, polarity, edge or level selection, and wake qualification in the board and software configuration.
  3. Test the event first in active mode, then repeat the same event in a wait or low-power path.
  4. Keep the ISR small and verify the worker or thread handoff path separately from pure interrupt delivery.
  5. If wake still fails, capture the entry and exit power-state evidence along with the interrupt evidence.
Expected result. You can identify whether the bug is in the line behavior, the routing, the wake qualification, or the software handoff path. 10.4 Debug techniques ■ Preserve a stable debug path such as UART logging across all phases of bring-up. ■ Reduce test complexity before you add new variables. ■ Compare every failed run to a known-good baseline instead of comparing two failed runs. ■ Capture logs, trace, and register state before you reset or rebuild.