Working with low power modes can be challenging. It can severely affect debugging capabilities of a microprocessor or microcontroller. I ported a FreeRTOS application using the Tickless Idle Mode to the NXP i.MX RT1064 board, and all of a sudden, the board was unresponsive to any debugger connection. Luckily the board was not really bricked, but it took me while to find a way to recover it. So for when you end up in a situation with a ‘bricked’ i.MX RT1064 board, this article might be helpful for you to recover it.

What I did with using the FreeRTOS tickles idle mode to reduce the power consumption of the board. In that mode, the RTOS calls a hook in which I can put the CPU or board into a low power mode, and it will be woken up by the next interrupt, either the tick interrupt or any other interrupt. The simplest way to do this is using the WFI (Wait For Interrupt) instruction:

/*
** ===================================================================
**     Description :
**         Used in tickless idle mode only, but required in this mode.
**         Hook for the application to enter low power mode.
**     Parameters  :
**         NAME            - DESCRIPTION
**         expectedIdleTicks - expected idle
**                           time, in ticks
**     Returns     : Nothing
** ===================================================================
*/
void McuRTOS_vOnPreSleepProcessing(portTickType expectedIdleTicks)
{
  (void)expectedIdleTicks; /* not used */
  __asm volatile("dsb");
  __asm volatile("wfi"); /* wait for interrupt: the next interrupt will wake us up */
  __asm volatile("isb");
}

That worked, but only until I increased the tick and task frequency. Suddenly I was not able anymore to gain access to the CPU with the debugger :-(.

💡 Update: after doing some more experiments, the behaviour seems to depend on if the board was going through a POR (Power-On Reset) with a following debug access. It still might be possible to enter debug mode if the board did not go through a power cycle.

Not able to connect with the Debugger

The symptoms were that the debug probe was not able to talk to the core, andd it received an invalid or wrong CpuID. In case you might see something similar, here are console outputs in Eclipse for the different debug probes I’m using (LinkServer, P&E and SEGGER):

The LPC-Link2 or ARM DAPLink (on-board default debug interface on the i.MX RT1064-EVK): might report something about a wrong CpuID:

Using memory from core 0 after searching for a good core
connection failed - Ep(03). Invalid ID for processor... Retrying
Using memory from core 0 after searching for a good core
On debug connection reset using system reset
Failed on connect: Ep(03). Invalid ID for processor.
Connected&Reset. Was: NotConnected. DpID: 0BD11477. CpuID: 00000FFF. Info: <None>
Last stub error 0: OK
Last sticky error: 0x0 AIndex: 0
Debug bus selected: MemAp 0
DAP Speed test unexecuted or failed
Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
(100) Target Connection Failed

A Segger J-Link might not find the core in the Coresight setup:

Connecting to J-Link...
J-Link is connected.
Device "MIMXRT1064DVL6A" selected.
Firmware: J-Trace PRO V1 Cortex-M compiled Oct 25 2018 11:48:19
Hardware: V1.00
S/N: 751000175
Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...InitTarget() start
InitTarget()
_TargetHalt: CPU halted
InitTarget() end
Found SW-DP with ID 0x0BD11477
Scanning AP map to find all available APs
AP[1]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x04770041)
Iterating through AP map to find AHB-AP to use
AP[0]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0xFF
InitTarget() start
InitTarget()
_TargetHalt: CPU halted
InitTarget() end
Found SW-DP with ID 0x0BD11477
Scanning AP map to find all available APs
AP[1]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x04770041)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FD000
CPUID register: 0x411FC271. Implementer code: 0x41 (ARM)
Found Cortex-M7 r1p1, Little endian.
FPUnit: 8 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl[0] @ E00FD000
ROMTbl[0][0]: E00FE000, CID: B105100D, PID: 000BB4C8 ROM Table
ROMTbl[1] @ E00FE000
ROMTbl[1][0]: E00FF000, CID: B105100D, PID: 000BB4C7 ROM Table
ROMTbl[2] @ E00FF000
ROMTbl[2][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
ROMTbl[2][1]: E0001000, CID: B105E00D, PID: 000BB002 DWT
ROMTbl[2][2]: E0002000, CID: B105E00D, PID: 000BB00E FPB-M7
ROMTbl[2][3]: E0000000, CID: B105E00D, PID: 000BB001 ITM
ROMTbl[1][1]: E0041000, CID: B105900D, PID: 001BB975 ETM-M7
ROMTbl[1][2]: E0042000, CID: B105900D, PID: 004BB906 CTI
ROMTbl[0][1]: E0040000, CID: B105900D, PID: 000BB9A9 TPIU-M7
ROMTbl[0][2]: E0043000, CID: B105F00D, PID: 001BB101 TSG
Cache: Separate I- and D-cache.

I-Cache L1: 32 KB, 512 Sets, 32 Bytes/Line, 2-Way
D-Cache L1: 32 KB, 256 Sets, 32 Bytes/Line, 4-Way
ERROR: Could not find core in Coresight setup
ERROR: Could not connect to target.
Target connection failed. GDBServer will be closed...Restoring target state and closing J-Link connection...
Shutting down...
Could not connect to target.
Please check power, connection and settings.

Server has been shut down.

A P&E Multilink Universal might not be able to download the .ARP file for programming:

Initializing.
Target has been RESET and is active.
CMD>CM C:\nxp\MCUXpressoIDE_10.3.0_2200\ide\plugins\com.pemicro.debug.gdbjtag.pne_3.9.2.201812122206\win32\gdi\P&E\supportFiles_ARM\NXP\iMX\nxp_imxrt1064_1x32x1meg.arp
 
Initializing.
Initialized.
 
;version 1.00, 08/29/2018, Copyright 2018 P&E Microcomputer Systems, www.pemicro.com
 
;device nxp, imxrt1064, 1x32x1meg, 
 
;begin_cs device=$70000000, length=$00400000, ram=$00000000
 
Loading programming algorithm ... 
Error loading .ARP file : C:\nxp\MCUXpressoIDE_10.3.0_2200\ide\plugins\com.pemicro.debug.gdbjtag.pne_3.9.2.201812122206\win32\gdi\P&E\supportFiles_ARM\NXP\iMX\nxp_imxrt1064_1x32x1meg.arp at address 00000000 
Error loading programming algorithm - load aborted. 
Error occured during Flash programming. 
PE-ERROR: Error downloading to the device.
Disconnected from "127.0.0.1" via 127.0.0.1
Disconnected from "127.0.0.1" via 127.0.0.1
Target Disconnected.

In all cases, it means the debugger was not able to get access to the core.

WFI: Wait for Interrupt

In my case, the problem occurred with using ‘WFI’ which is used in tickless idle mode of FreeRTOS. ‘WFI’ is the ‘Wait for Interrupt’ ARM instruction: it will suspend the core and saves power with the next interrupt waking it up and continue execution

That worked fine for me if the RTOS was not often going into low power mode. But as soon as the core was entering low power mode say with about 100 Hz, the debugger was not able to connect any more. My thinking is that the debugger was able to talk to the core, but not able to finish the sequence to halt until the core again executed again a WFI: or in other words: the debug connection needs more than 10 ms to halt the core. If the core enters low power mode during the connection sequence, the debugger will fail to connect.

This is a problem I have not seen on any other Cortex-M I’m using, and probably because the i.MX RT is executing much faster (600 MHz!) than the others I’m using.

I tried different ways to recover the board (e.g. trying to erase the FLASH from the IDE), but did not work. I tried to use the SEGGER J-Link command line tool to gain access to the core: that did not succeed.

Update:

The i.MX RT1064 has a GPC (General Power Controller).

Calling

CLOCK_SetMode(kCLOCK_ModeRun); 

at the start of the application which does

typedef enum _clock_mode_t
{
    kCLOCK_ModeRun = 0U,  /*!< Remain in run mode. */
    kCLOCK_ModeWait = 1U, /*!< Transfer to wait mode. */
    kCLOCK_ModeStop = 2U, /*!< Transfer to stop mode. */
} clock_mode_t;

/*!
 * @brief Setting the low power mode that system will enter on next assertion of dsm_request signal.
 *
 * @param mode  Which mode to enter, see \ref clock_mode_t.
 */
static inline void CLOCK_SetMode(clock_mode_t mode)
{
    CCM->CLPCR = (CCM->CLPCR & ~CCM_CLPCR_LPM_MASK) | CCM_CLPCR_LPM((uint32_t)mode);
}

actually prevents the CPU to enter the WAIT mode, and in this stage the problem does not happen, because simply the WAIT mode is disabled. See https://community.nxp.com/thread/492841#comment-1099054.

By default the CLPCR[LPM] bit is set. Chapter 13.6.3.2.1 says that in that case I have to configure the ‘alternative interrupt controller’ should be enabled. I read it that the NVIC of the ARM core is disabled. That would explain why for example the SysTick does not run any more in my RTOS.

Recovery

💡 Another (easier) way to recover is the following: 1) make sure no debug connection is active. b) power-on the board, and wait until it goes into WAIT mode (you won’t be able to access it in this state). c) Press the SW02 button on the board for 2 seconds, then release it. d) the board should now restart, and somehow the SW02 press has set the CPU into a state which prevents entering WAIT mode. e) Now I’m able to debug the board again.

So how to regain access with the debugger to the core? The other idea I had was to boot the processor in a different mode from a different memory, preventing it to execute the code with the WFI in it. The NXP i.MX RT1064 offers three different boot modes which can be configured using switches on the board:

I changed the board boot mode to ‘serial download’ mode (SW7 set to 0001).

With this the processor is executing the boot ROM code, and I was able to attach with the debugger again.

However, the internal flash memory at 0x7000’0000 was not accessible in this mode, and I was not able to erase it or access it directly.

Boot Utility to the Rescue!

That DIP switch for the ‘Serial Download’ executes a bootloader on the NXP i.MX RT1064. That bootloader communicates over the USB port of the MCU with a special tool on the host which can be used to download new firmware. I have used that approach for other microcontrollers (see “Getting Started: ROM Bootloader on the NXP FRDM-KL03Z Board“), but not yet for the i.MX.

Setting up such a utility and using it is not that simple. What came to the rescue was the ‘NXP Boot Utility‘ of Jay Heng: this tool enabled me in a few steps to regain access to the board.

1. Follow the instructions from https://github.com/JayHeng/NXP-MCUBootUtility/
2. Boot the board in serial download mode with SW7 set to 0001:
   

   SW7 set to serial download

3. The board should enumerate as USB HID device with vID 0x1FC9 and PID 0x0135
   

   USB HID Device

4. Start NXP-MCUBootUtility-1.0.0\bin\NXP-MCUBootUtility.exe. Select the device and using USB-HID. It shall list the VID and PID discussed above. If not, check your USB connection.
   

   MCU NXP Boot Utility

5. Switch to ‘Master’ mode:
   

   Master Mode

6. Disable the ‘One Step’ option (so we have full control over all steps) and connect to the ROM:
   

   Connect to ROM

7. With this we should be connected to the ROM, and you can see the executed host bootloader program (sdphost) commands in a separate console window.
   

   Connected to ROM

8. Next click the ‘Connect to Flashloader’ button, the status shall now be green:
   

   Connected

9. Press the ‘Configure boot device’ button and the status shall change to blue. Notice the section about the FlexSPI NOR memory configuration in the Device Status. Only with such settings the tool is able to operate properly with the internal FLASH and will use an offset of 0x0 (otherwise you have to specify an offset or address of 0x70000000):
   

   Boot Device Configured

10. Go to the ‘Boot Device Memory’ tab. Configure the start address as 0x70000000 with size 0x400000 and press Erase. You can verify the correct command in the Log (if it fails, see trouble shooting section below):
    

    Erasing the flash

11. This now should have erased the memory area specifed. Use the ‘Read’ button to verify this (if this fails, see trouble shooting section below):
    

    Erased internal flash memory

12. This has set all the flash memory cells to 0xffff’fffff. What is missing is that the correct Flash descriptor is programmed. This is done with the MCUXpresso IDE. Open the GUI Flash Tool in the MCUXpresso IDE with a working project (e.g. blinky) selected for the RT1064:
    

    GUI Flash Tool

13. Then do a mass erase (note that this will do a mass erase *and* program the correct header):
    

    Mass Erase with Flash Header

14. This should succeed as below:
    

    Flash Erase completed

15. Checking the flash memory with the Utility should show now that it has the correct header:
    

    Correct Flash Header Present

16. Now program a ‘known-good’ application (e.g. a blinky) to the MCU using the MCUXpresso GUI Flash programmer:
    

    Programming Application

17. This should succeed:
    

    Sucessful Flash Programming

18. Now set SW7 back to boot from internal FLASH (SW7: 0010), reset the board, and the programmed application (e.g. blinky) shall run.
19. Now the board is recovered again 🙂

Troubleshooting

In some case the Boot Utility seems not to send the correct parameters. You can see this in the log and in the console output as below:

In that case, copy the command line from the Log, paste it to a System Console, e.g. I used following (while the utility is still running):

C:\nxp\McuBootUtility\NXP-MCUBootUtility-1.0.0\tools\blhost\win\blhost -t 6573000 -u 0x15A2,0x0073 -j -- flash-erase-region 0x70000000 0x40000 9

Suggestion: Safety Belt

What I recommend for any other low-power experiments is to add a kind of safety belt code: after power-on the system waits (and blinks) some time to allow me to connect to it before it goes into the ‘danger’ zone with low-power modes:

This allows me to catch the target in case of problems. Such a code might be even helpful in production systems, e.g. doing this if a push button is pressed during power-on.

Summary

Dealing with ‘flash-less’ devices can be tricky. While the NXP i.MX RT1064 has an on-chip device, it is really like an internally bonded QSPI flash device. In order to have the CPU booting from it, it requires a well-defined header (Flash description) placed in it. If this header is corrupted, the application misbehaving or if the memory is erased, the debugger might not be able to access the MCU any more. This happened for me with a FreeRTOS application executing the WFI instruction so fast that it was not possible any more to access the MCU. A combination of MCUXpresso IDE, the i.MX RT1064 bootloader (serial loader) and the NXP Boot Utility finally helped me to get ‘back to normal’. In case you ever end up in the same situation, the above steps and descriptions hopefully will help you.

💡  I recommend to have different debug probes (NXP LPC-Link2, Segger J-Link and P&E Multilink) at hand in combination with the NXP MCUXPresso IDE and the MCU Boot Utility.

Happy Debugging 🙂

Links

• First Steps with the NXP i.MX RT1064-EVK Board
• Low Power with FreeRTOS: Tickless Idle Mode
• NXP Boot Utility by Jay Heng: https://github.com/JayHeng/NXP-MCUBootUtility
• Forum discussion about WFI on i.MX RT: https://community.nxp.com/thread/492841#comment-1099054