1. Abstract
When the customer uses the NXP RT board to debug the code, sometimes, the board suddenly meets debug connect issues when using the IDE and the debugger to download the code. Especially to the customer who is using the NXP RT EVK board with the onboard default CMSIS-DAP debugger. They even suspect the board is broken after trying a lot of times.
The debugger connects issues that normally happen when using the wrong FDCB, the download process is ended abnormally, the wrong flash loader, or the abnormal app code in the flash, .etc.
The reported issue result will be similar to the following pictures:
Fig.1
Fig.2
The connect log maybe:
No connection to chip’s debug port
Error: Wire Ack Wait Fault
This document will give some methods to recover the board when meeting the debugger issues with the typical MIMXRT1060-EVK board +MCUXpresso IDE as the test platform. Other platform is also similar, the recovery method also can be used.
2. RT board recovery method
The main method is to change the RT board to the serial download mode, bring the core to a known state, then do the mass erase in IDE or with the MCUXpresso Secure Provisioning Tool(SPT).
First, let the board enter the serial download mode:
Fig.3
Enter serial download mode:
1) SW7: 1-OFF,2-OFF,3-OFF,4-ON
2) Power off and power on again, or Press Reset button
2.1 IDE Mass Erase
MCUXpresso IDE, choose the related debugger interface, then choose “erase flash action”.
Here take the MIMXRT1060-EVK on board default debugger CMSIS DAP as an example:
Fig.4
Fig.5
After this operation, when the Board is back to the internal boot again, the debugger can download to the flash again.
2.2 SPT Mass Erase
Customers also can use the NXP MCUXpresso Secure Provisioning Tool to do the code download or the mass erase in the serial download mode, this method also can recover the board, in fact, just let the core in the known status.
SPT tool download link:
After installing the SPT tool, open it.
1) Create one RT1060 workspace
Fig.6
2) Connect the board with USB or the UART
Here, take USB interface as an example.
Fig.7
Fig. 8
Fig.9
Fig.10
Fig.11
Until now, the external flash is erased!
In the SPT, the customer also can double check the memory, especially whether the FDCB area is erased or not, just like in the following picture:
Fig.12
The customer can go back to the internal boot mode and use the debugger to download the code again.
Internal boot mode:
SW7:1-OFF,2-OFF,3-ON,4-OFF
Press reset or power off and power on again to enter the internal boot mode, then use the debugger to test it again, this is the result:
Fig.13
We can see, the MIMXRT1060-EVK debugger interface is recovered!
3. Conclusion
When the flash contains an app that is abnormal(access memory does not exist, memory is corrupted, misconfiguration of the clocks, etc.), it will cause the board to end up in an unknown state, then the debugger can’t take control over the core. But, when put the core in serial downloader mode, then it will put the core in a known state, this way, the debugger will be able to take control of the core.
So, when meeting the debugger issues in the RT board, try to mass erase the external flash in serial download mode, then it will recover the board debugger to a normal situation.
