Hi NXP Team
I'm facing a strange issue with my MIMXRT1060-EVKB that started suddenly. The board was working fine previously, but now I cannot debug any application, including the SDK examples.
Environment
- Board: MIMXRT1060-EVKB
- IDE: MCUXpresso IDE 24.12.x
- Debug Probe: On-board LinkServer
- Connection: USB
Problem
When I start a debug session:
- The project builds successfully.
- Flash programming completes successfully.
- After programming, the debugger resets the target but never reaches ResetISR or main().
- The GDB session immediately terminates.
Console output:
Closing flash driver MIMXRT1060_SFDP_QSPI.cfx
Flash Write Done
Flash Program Summary: 850584 bytes in 0.06 seconds
Starting execution using system reset and halt target
Stopped (Was Reset) [Reset from Unknown]
GDB stub (crt_emu_cm_redlink) terminating - GDB protocol problem: Pipe has been closed by GDB.
What I have already tried
- Tested with a new SDK example (UART interrupt example) — same behavior.
- Placed a breakpoint at ResetISR — it is never hit.
- main() is never reached.
- Performed Mass Erase — no change.
- Rebooted the PC.
- Tried on another laptop with a fresh MCUXpresso installation — same issue.
- Verified the DIP switches are configured for QSPI Flash boot mode, not Serial Downloader (ISP) mode.
Any suggestions would be greatly helpful.
Thanks
Prathyush.
Hi @ShellyZhang ,
Thank you for your suggestion.
I followed the exact sequence you recommended. I disconnected the power and debug cables, toggled the last two pins of SW4 to put the board into Serial Download Mode, reconnected the board, and performed a Mass Erase using the LinkServer GUI Flash Programmer. The mass erase completed successfully.
After that, I restored the board to QSPI Boot Mode, reset the board, and started a new debug session.
Unfortunately, the issue still persists. The application is programmed successfully, but the debugger does not reach ResetISR or main().
I also verified that the same behavior occurs with an unmodified SDK example project, so it does not appear to be specific to my application.
Thanks,
Prathyush
Dear @Prathyush_27 ,
Please try this sequency:
1. Disconnect the power cable and the debug cable from the board, then set the board boot mode to Serial Download Mode.
2. Reconnect the power cable and the debug cable, then use MCUXpresso IDE → GUI Flash Tool / LinkServer GUI Flash Programmer → Erase Flash Memory → Mass Erase.
3. Restore the board to QSPI Boot Mode, reset the board, and then start a new debug session.
Best Regards，
Shelly
Thank you for your reply. Your feedback will help us better understand the issue and may also benefit others who encounter similar problems.
Best Regards，
Shelly
Hi @ShellyZhang ,
Thank you for your assistance.
I was able to identify the root cause of the issue. It turned out to be the SW2 DIP switch configuration. The last two switches on SW2 had been accidentally toggled, which prevented the debugger from starting the application correctly.
After restoring the last two SW2 switches to their original positions, everything worked as expected. The debugger now successfully reaches ResetISR and main(), and debugging works normally.
This was a configuration issue on my board rather than a problem with the SDK or the debugger.
Thank you again for your support. I hope this information is helpful to anyone who encounters a similar issue in the future.
Dear @Prathyush_27 ,
Could you please try the following two approaches?
1. Verify Flash Programming and Boot
Please try using MCUXpresso Secure Provisioning Tool 26.06 to program a simple LED blink application while the board is in Serial Download Mode, and then switch the boot mode back to QSPI Boot Mode.
If the LED application runs successfully after a reset, it indicates that the flash device and boot process are functioning correctly. In that case, I suspect that LinkServer GUI Flash Programmer may not have completed the flash erase operation successfully.
If the LED application can boot and run after a reset, please try launching a normal debug session again to see whether the issue still occurs.
2. Run the Application from RAM
Please modify the project configuration to run the application from RAM:
2.1 Enable Link application to RAM:
2.2 Under Defined Symbols, configure:
XIP_EXTERNAL_FLASH=0
XIP_BOOT_HEADER_ENABLE=0
2.3 Rebuild the project.
2.4 Start a normal debug session and run the application.
Please let us know the results of both tests, especially whether the LED application can boot successfully from QSPI flash and whether the RAM-based application can run under debug.
Best regards,
Shelly