MCXE316 will not run without debugger

[brucebowling]

Working on a custom board with the MCXE316 in the 48-pin package. I can download and execute code without issue with the debugger attached (PE Micro), however without the debugger attached with debug session in MCUXpresso the processor appears to not be running. If I power cycle the board is dead, if I plug in the debugger and start a debug session the board operates properly. Some of the things I have tested/verified:

1) I made sure I built the project without Semihosting enabled, and using the Redlib nohost -nf library which I believe disables Semihosting. Also there seems to be code in the semihost_hardfault.c to catch a hard fault from no debugger.

2) I have checked the reset register MC_RGM.FES and DES in the debugger and the power-on reset bit is the only one active - even if I apply a POR without the debugger attached (hung), then physically connect the debugger and initiate a debug session without a power cycle, the only bit set is power-on.

3) I have one LED on my board at PTB13, and I created the simplest code to flash the LED with no setup changes on clocks, etc, just flash the LED as the first operation in main with an infinite loop - here is the test code:

#include "fsl_siul2.h"

main()

{

// Make PTB13 an output

SIUL2->MSCR[45] = 0x200000;

while(1)

{

for(volatile uint32_t s=0; s<100000; s++);

SIUL2_PortToggle(SIUL2, kSIUL2_PTB, 1u << 13U);

}

}

This code operates fine when the debugger is attached, but standalone there is nothing. I have also made this same code using SDK functions and the same result, it operates only with a debugger session active.

I have also disabled the SWT watchdog in the code, same result. I don't think it is a watchdog reset event.

Any ideas or checks I can perform? Thanks!

[brucebowling · Accepted solution]

Ok, I began the steps you outlined in the response, and right out of the gate the issue showed up. Checking the memory at 0x0040_0000 was 0xFFFFFFFF, as were all of the subsequent address contents. So evidently these areas were not being programmed by the SDK default project.

Checking the reference manual for the Image Vector Table (section 31.5) I see the section regarding the magic number, etc. that needs to be programmed into the IVT. I was assuming that the default project setup for the MCXE316 device would include initializing this section, but I did not see anything regarding this.

I did notice that the FRDM MCXE31B board (big brother chip to the MCXE316) demo applications like the LED_Blinky did properly allow program execution without debugger attachment, as expected. And after loading in LED_Blinky into the FRDM-MCXE31B board, checking the memory address location 0x0040_0000 had the expected 0x5AA5_5AA5. So evidently this project contains the setup that is missing from the default SDK project I was using for the MCXE316 variant.

A little digging into the project for LED_Blinky shows a "boot_header" folder with the files "boot_header.c" and "boot_header.h". Looking at the boot_header.c source it appears this is where the project initializes the magic number and other items for the IVT. So I just copied the source and .h file from the LED_Blinky project to my SDK project. I also had to set a #define BOOT_HEADER_ENABLE 1U in order for the code to be included in the build.

This works! The applications continues to operates without debugger hardware on my custom test board. Apparently this file does what you were asking before in the test #2 section.

NXP needs to include this in the next SDK release for the MCXE316 device, otherwise others will experience the same issue.

Thanks for the help on this!

[Celeste_Liu]

Hello @brucebowling ,

Thank you for sharing the progress. As you correctly pointed out, the SDK should include the boot_header file when creating a new project. Therefore, I also consider this to be a bug.
I will report this issue to the SDK team and remind them to address it as soon as possible. Thank you again for your valuable suggestion!

BR

Celeste

[brucebowling]

Hello Celeste,

Thank you for the response and items to check. I am still experiencing the issue with no operation without the debugger - here are responses to the individual items to check:

-  I monitored the RESET pin during powerup with an oscilloscope, and the reset pin level always drives to +5V on POR reset (i.e. not being held in reset).  There is no jumping or other visuals of the part going back into repeated resets, the line stays logic high. I can manually pull the reset line low then release (manual reset), the signal just goes to logic high and stays there

- I have also maintained power (verified) and manually pulled RESET line low then released, still no operation. I would believe this would bypass any power supply powerup rate issues.

- I have powered up the board without the debugger attached (no run state but with power applied), then physically plugged in the debugger cable (external power still applied without interruption) and viewed the FES and DES registers in the debugger, they indicate only a POR reset reason, no other faults are present. The PC is pointing to the main() entry breakpoint, I assume the debugger issues a reset at the beginning of the debug session and hence the code runs and halts at the beginning of main - but since the board has maintained power the DES and RES should still be valid from the original POR when the part hangs up.

- I am not setting up the clock at all, it is using the default clock configuration on reset as provided by the SDK project. I have also attempted to set the clock up with code to use the external crystal and PLL, and under the debugger this operates and I indeed get the higher PLL clock in the debugger just fine. But with no debugger the part is just dead, does not matter if I set up a **bleep** in the code or I just let the part default to the internal clock source present on boot.

- As far as I can measure the power supply ramp-up is within specification. I will try to bring the board up with an external power supply just to add a variable to see if there is a difference. However I would assume that once the part is powered-up then an external reset would subsequently wake it up - and if the chip was latched up hard then maintaining board power and re-hooking up the debugger would stay in a locked state, but the debugger always works.

Any other checks or verifications I can perform let me know. I am running out of ideas. Thanks

[Celeste_Liu]

Hello @brucebowling ,

Thank you for your response. Please proceed with the following checks in sequence:

1. Verify whether a valid IVT exists at the Flash base

• Read address 0x0040_0000, expected value: 0x5AA5_5AA5
• Check 0x0040_0004 (Boot Configuration Word): ensure CM7_0_ENABLE is set to 1
• Verify 0x0040_000C contains a valid CM7_0 application entry address

2. Confirm that the project / linker script / programming method generates a valid MCXE31 boot image

• Ensure that you are not programming only a standard ELF or vector table
• The image must include an IVT recognizable by Secure BAF
• The IVT must be located at one of the supported IVT addresses for MCXE316

3. Capture POR-related status at the earliest point after reset

• PMC.LVSC: check PORF / LVR flags
• DCM read-only registers: check POR_WDG_EN and POR_WDOG_TRIM

4. Perform a minimal experiment to verify true independent application entry

• Avoid relying solely on LED toggling
• Instead, in ResetISR or very early startup code, set a reserved RAM flag or a dedicated GPIO state
• Then, use attach mode without triggering a debugger reset to read the status, this helps eliminate interference caused by debugger-induced resets

Best Regards,

Celeste

[Celeste_Liu]

Hello @brucebowling ,

Thank you for your detailed description and for already checking several potential causes, that is very helpful.

Based on what you described, this behavior is typically related to startup conditions rather than the application code itself. We would recommend focusing on the following key areas:

1. Check for reset or early startup failures

Please monitor the RESET_B pin with an oscilloscope during power-on (without the debugger connected). Check if there are any unexpected pulses, glitches, or repeated assertions of reset.

If possible, power the board without a debugger, then attach the debugger without resetting the device, halt execution, and check:

• Program Counter (PC)
• MC_RGM.FES and MC_RGM.DES register

This helps identify whether the device is stuck or being reset repeatedly.

2. Verify clock configuration

This is one of the most common root causes for this type of issue.

If your project configures external clock sources or PLL:

- Please ensure that all clock domains are correctly configured, not only the core clock.
- For example, some derived clocks (such as HSE or other system clocks) must follow specific relationships with the core clock.
- Incorrect clock configuration can lead to unexpected resets or execution failure during early startup, even if debugging appears to work normally.

3. Check power supply ramp rate

Since you are using a custom board, please also double-check the power supply stability during startup. The design needs to comply with the requirements specified in the MCX E31x Hardware Design Guide and the DS.
Please refer to the screenshots below for details.

Hope it helps.

BR

Celeste