Hi,
There are different ways to recover depending on the firmware currently present in the flash memory. If there is sufficient time after leaving the bootloader and re-assigning the function of one of the debug pins, you will be able to halt the core and reflash.
There is some documentation available about this in the SDK under <SDK>/docs/firmware.html > SW Debug Considerations.
The demo applications show different ways to help you avoid bricking your IC:
- The Hello world application, blinky, has added a wait time before starting to execute, by calling Chip_Clock_System_BusyWait_ms (since SDK v12.5)
- The temperature logger application, tlogger, has added in it's reset handler a check, and block execution while the WAKEUP pin is low, by using this line of code: while (!(NSS_GPIO->DATA[1 << 0]));. You can push and hold the WAKEUP button, press RESET, then grab a new debug session.
- The msg module has a special message MSG_ID_PREPAREDEBUG, to correct the pin configuration of the debug pins, and enter an infinite loop.This allows you to connect and debug a running session (use attach only in your debug configuration, i.e. no reset and reflash before halting the core)
In general, all these measures show how to increase the window within which it is possible for a debugger to connect to the core. As said by Daniel, Flash Magic can be used to revive an IC. It is much faster than MCUXpresso and requires a much shorter break-in time window. You can also use a J-Link Base debugger and the corresponding command line interface.
It is possible all your tries will fail. Replacing the IC is then your unfortunate last solution. Be sure to add some kind of (potential) delay at the startup before experimenting, to avoid these problems in the future.
Kind regards,
Dries.
