Debug connection error

[msaliharslan]

I work with MXRT1052 processor on custom boards. I use PE Micro Multilink Universal debug probe to program the processors. Occasionally, program operation fails with the following error.

Error in services launch sequence
PEmicro GDB Launch Failure : The GDB Server was not able to establish a connection to the target processor. Please check your connections and power. Verify that the launch settings in the Debug Configuration are accurate.

This error occurs due software since we debug without problem on the same hardware i.e. same connections, power, launch settings. We thought this issue might be related to flash memory, however, If flash has problems, I believe that there should be another error message. For example write error, not connection error. Moreover, even when "link application to RAM" option was selected in project settings, the error persist.

------------------------- UPDATE --------------------------------------------

I want give more information about the problem. We use MXRT1052 CVJ5B and IS25LP064 QSPI Flash. Normally, we are able to debug without problem. However, something causes current consumption to drop significantly and the processor is no longer reachable by the debugger. Some possible causes are

• Power cut during debug
• Selecting target as MXRT1052 instead of MXRT1052QSPI in debug configuration
• Monitoring the memory region of FLEXSPI peripheral during debug
• Selecting "plain load image" option in project settings
• Loading wrong image to the flash
• Using FLEXSPI to reach the some other region of the same flash device

The error occurs when BOOT_MODE is set to internal boot, it never occurs when set to serial downloader and usually does not occur when set to Boot From Fuses. At the current state, the board is reachable after it was kept powered off for a while, however, following power resets results in a low current consumption state in which debug is not possible when BOOT_MODE is boot from fuses.

The error we get given above is the same when there is nothing connected to debug probe.

Is there any state, in which the processor cannot be reached by debug probe? If so how can I get the processor out of it? If not what might be the problem?

[victorjimenez]

Hello, 

The behavior that you are facing is because the RT ends up in an unknown state in which the debugger cannot take control over it. This might happen due to several different reasons, the most commons are clock misconfigurations, the RT is trying to access a memory location that doesn't exist, memory misconfiguration, and entering a low power mode without an exit way. 

To regain debug access when this happens, we recommend putting the RT into serial downloader mode. Doing this will bring the RT into a known state, hence the debugger can take control over it once again. 

One of my colleagues created a document in his personal blog that explains this in detail. Although he uses the RT1064, the same concepts apply to any RT. You can check it at the following link. 

Regaining Debug Access to NXP i.MX RT1064-EVK executing WFI (https_mcuoneclipse.com)

Regards,
Victor 

[msaliharslan]

Can any of these unknown states occur internally from the processor, without trying to run an image on flash? Is these states persist after power reset?

[victorjimenez]

No, these unknown states occur due to the image that is running. These states will persist as long as you don't repair in your current image what is causing this. If you just reset the RT, the same image will start running again. This will lead to the same unknown state as before. 

Regards,
Victor