DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

How does AI transform chaos engineering from an experiment into a critical capability? Learn how to effectively operationalize the chaos.

Data quality isn't just a technical issue: It impacts an organization's compliance, operational efficiency, and customer satisfaction.

Are you a front-end or full-stack developer frustrated by front-end distractions? Learn to move forward with tooling and clear boundaries.

Developer Experience: Demand to support engineering teams has risen, and there is a shift from traditional DevOps to workflow improvements.

Related

  • 10 Most Popular Tools to Monitor and Debug Serverless Applications
  • A Guide To Troubleshooting the 500 Internal Server Error on Nginx
  • Navigating Progressive Delivery: Feature Flag Debugging Common Challenges and Effective Resolution
  • Troubleshooting Memory Leaks With Heap Profilers

Trending

  • RAG vs. CAG: A Deep Dive into Context-Aware AI Generation Techniques
  • Four Essential Tips for Building a Robust REST API in Java
  • From Java 8 to Java 21: How the Evolution Changed My Developer Workflow
  • Event-Driven Microservices: How Kafka and RabbitMQ Power Scalable Systems
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Maintenance
  4. Regaining Debug Access to NXP i.MX RT1064-EVK Executing WFI

Regaining Debug Access to NXP i.MX RT1064-EVK Executing WFI

Working with low power modes can be challenging.

By 
Erich Styger user avatar
Erich Styger
·
Jan. 07, 19 · Tutorial
Likes (3)
Comment
Save
Tweet
Share
12.8K Views

Join the DZone community and get the full member experience.

Join For Free

Working with low power modes can be challenging. It can severely affect the 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 a 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.

i.MX RT1064-EVK Board

i.MX RT1064-EVK Board

What I did was use the FreeRTOS tickles idle mode to reduce the power consumption of the board. In that mode, the RTOS calls a hook, 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.

Unable to Connect With the Debugger

The symptoms were that the debug probe was not able to talk to the core, and 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 and E, and SEGGER):

The LPC-Link2 or ARM DAPLink (onboard 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 proper access to the core.

WFI: Wait for Interrupt

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

WaitForInterrupt

WaitForInterrupt

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 anymore. 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, which is probably due to the fact that 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 it did not work. I tried to use the SEGGER J-Link command line tool to gain access to the core — that did not succeed either.

Recovery

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:

Board Default Boot Configuration

Board Default Boot Configuration

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

SW7 set to serial download

SW7 set to serial download

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

Attached to boot ROM Code

Attached to boot ROM Code

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 that 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.

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

    SW7 set to serial download

    The board should enumerate as USB HID device with vID 0x1FC9 and PID 0x0135USB HID Device

    USB HID Device

    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

    MCU NXP Boot Utility

    Switch to ‘Master’ mode:Master Mode

    Master Mode

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

    Connect to ROM

    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

    Connected to ROM

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

    Connected

    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 is the tool able to operate properly with the internal FLASH and use an offset of 0x0. Otherwise, you have to specify an offset or address of 0x70000000:Boot Device Configured

    Boot Device Configured

    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 the troubleshooting section below):Erasing the flash

    Erasing the flash

    This now should have erased the memory area specified. Use the ‘Read’ button to verify this (if this fails, see the troubleshooting section below):Erased internal flash memory

    Erased internal flash memory

    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

    GUI Flash Tool

    Then, do a mass erase (note that this will do a mass erase *and* program the correct header):Mass Erase with Flash Header

    Mass Erase with Flash Header

    This should succeed as below:Flash Erase completed

    Flash Erase completed

    Checking the flash memory with the Utility should show now that it has the correct header:Correct Flash Header Present

    Correct Flash Header Present

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

    Programming Application

    This should succeed:Sucessful Flash Programming

    Successful Flash Programming

  • Now, set SW7 back to boot from internal FLASH (SW7: 0010) and reset the board; the programmed application (e.g. blinky) should run.
  • Now, the board is recovered again
  • Troubleshooting

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

    wrong read memory

    wrong read memory

    In that case, copy the command line from the Log and 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

    Executing Flash Erase from Cmd.exe

    Executing Flash Erase from Cmd.exe

    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:

    Safety Belt Code

    Safety Belt Code

    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 anymore to access the MCU. A combination of the 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!

    Helpful 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
    Debug (command) Flash memory application Memory (storage engine)

    Published at DZone with permission of Erich Styger, DZone MVB. See the original article here.

    Opinions expressed by DZone contributors are their own.

    Related

    • 10 Most Popular Tools to Monitor and Debug Serverless Applications
    • A Guide To Troubleshooting the 500 Internal Server Error on Nginx
    • Navigating Progressive Delivery: Feature Flag Debugging Common Challenges and Effective Resolution
    • Troubleshooting Memory Leaks With Heap Profilers

    Partner Resources

    ×

    Comments

    The likes didn't load as expected. Please refresh the page and try again.

    ABOUT US

    • About DZone
    • Support and feedback
    • Community research
    • Sitemap

    ADVERTISE

    • Advertise with DZone

    CONTRIBUTE ON DZONE

    • Article Submission Guidelines
    • Become a Contributor
    • Core Program
    • Visit the Writers' Zone

    LEGAL

    • Terms of Service
    • Privacy Policy

    CONTACT US

    • 3343 Perimeter Hill Drive
    • Suite 100
    • Nashville, TN 37211
    • [email protected]

    Let's be friends: