Cannot Reset Target and Connect Using LinkServer Debugger

[rnicolls]

Hi,

We're having issues connecting and launching a new debug session with a running target. 

After we enabled the DMA to continuously transfer conversions from the ADC we have been having issues connecting to a running target and programming. If we modify the code so that the DMA no longer transfers the conversions or if we manually reset the target before connecting and programming, there are no issues.

It appears that the debugger is unable to halt the cpu core. We've tried modifying the debug configuration so that the Flash driver reset handling is set to VECTRESET and the reset handling is also set to VECTRESET but this does not seem to help.

Here's the console after trying to launch a debug session:

MCUXpresso IDE RedlinkMulti Driver v11.6 (Jul 12 2022 16:58:24 - crt_emu_cm_redlink build 4)
Found chip XML file in C:/work/bms_module_controller/MCUXpressoIDE/MODULE_CONTROLLER_APP/Debug\MIMXRT1176xxxxx.xml
Reconnected to existing LinkServer process.
============= SCRIPT: RT1170_connect_M7_wake_M4.scp =============
RT1170 Connect M7 and Wake M4 Script
DpID = 6BA02477
APID = 0x84770001
Setting M4 spin code
Setting M4 clock
Resetting M4 core
View cores on the DAP AP
DpID = 6BA02477
TAP 0: 6BA02477 Core 0: M7 APID: 84770001 ROM Table: E00FD003*
TAP 0: 6BA02477 Core 1: M4 APID: 24770011 ROM Table: E00FF003
============= END SCRIPT ========================================
Probe Firmware: MCU-LINK r0FF CMSIS-DAP V0.078 (NXP Semiconductors)
Serial Number: KQGOZKDOWAIEL
VID:PID: 1FC9:0143
USB Path: \\?\hid#vid_1fc9&pid_0143&mi_00#7&2c94bdd8&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Using memory from core 0 after searching for a good core
debug interface type = CoreSight DP (DAP DP ID 6BA02477) over SWD TAP 0
processor type = Cortex-M7 (CPU ID 00000C27) on DAP AP 0
number of h/w breakpoints = 8
number of flash patches = 0
number of h/w watchpoints = 4
Probe(0): Connected&Reset. DpID: 6BA02477. CpuID: 00000C27. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Content of CoreSight Debug ROM(s):
RBASE E00FD000: CID B105100D PID 000008E88C ROM (type 0x1)
ROM 1 E00FE000: CID B105100D PID 04000BB4C8 ROM (type 0x1)
ROM 2 E00FF000: CID B105100D PID 04000BB4C7 ROM (type 0x1)
ROM 3 E000E000: CID B105E00D PID 04000BB00C Gen SCS (type 0x0)
ROM 3 E0001000: CID B105E00D PID 04000BB002 Gen DWT (type 0x0)
ROM 3 E0002000: CID B105E00D PID 04000BB00E Gen (type 0x0)
ROM 3 E0000000: CID B105E00D PID 04000BB001 Gen ITM (type 0x0)
ROM 2 E0041000: CID B105900D PID 04001BB975 CSt ARM ETMv4.0 type 0x13 Trace Source - Core
ROM 2 E0042000: CID B105900D PID 04004BB906 CSt type 0x14 Debug Control - Trigger, e.g. ECT
ROM 1 E0043000: CID B105900D PID 04001BB908 CSt CSTF type 0x12 Trace Link - Trace funnel/router
NXP: MIMXRT1176xxxxx
DAP stride is 1024 bytes (256 words)
Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MIMXRT1170_SFDP_QSPI.cfx
Image 'iMXRT1170_SFDP_FlexSPI1_A_QSPI Jul 7 2022 12:15:07'
Opening flash driver MIMXRT1170_SFDP_QSPI.cfx
Sending VECTRESET to run flash driver
Flash variant 'iMXRT1170_SFDP_FlexSPI1_A_QSPI Jul 7 2022 12:15:07' detected (16MB = 256*64K at 0x30000000)
Closing flash driver MIMXRT1170_SFDP_QSPI.cfx
Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MIMXRT1170_SFDP_QSPI.cfx
Image 'iMXRT1170_SFDP_FlexSPI1_A_QSPI Jul 7 2022 12:15:07'
Opening flash driver MIMXRT1170_SFDP_QSPI.cfx
Sending VECTRESET to run flash driver
Flash variant 'iMXRT1170_SFDP_FlexSPI1_A_QSPI Jul 7 2022 12:15:07' detected (0B = at 0xFFF)
Flash Driver V.2 startup failed - rc Ef(57): Flash Driver supports page size larger than working memory area
chip initialization failed - Ef(57): Flash Driver supports page size larger than working memory area
failed to initialize flash driver MIMXRT1170_SFDP_QSPI.cfx
Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MIMXRT1170_SFDP_QSPI.cfx
Image 'iMXRT1170_SFDP_FlexSPI1_A_QSPI Jul 7 2022 12:15:07'
Opening flash driver MIMXRT1170_SFDP_QSPI.cfx
Sending VECTRESET to run flash driver
Waiting for target to stop...
Warning - processor did not halt - gave up waiting
target failed to halt after flash driver reset - (null)
flash start - disabling IRQs failed - rc Ep(08). Cannot access core regs when target running.
chip initialization failed - Ep(08). Cannot access core regs when target running.
failed to initialize flash driver MIMXRT1170_SFDP_QSPI.cfx
Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MIMXRT1170_SFDP_QSPI.cfx
Image 'iMXRT1170_SFDP_FlexSPI1_A_QSPI Jul 7 2022 12:15:07'
Opening flash driver MIMXRT1170_SFDP_QSPI.cfx
chip initialization failed - Ep(08). Cannot access core regs when target running.
failed to initialize flash driver MIMXRT1170_SFDP_QSPI.cfx
Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MIMXRT1170_SFDP_QSPI.cfx
Image 'iMXRT1170_SFDP_FlexSPI1_A_QSPI Jul 7 2022 12:15:07'
Opening flash driver MIMXRT1170_SFDP_QSPI.cfx
chip initialization failed - Ep(08). Cannot access core regs when target running.
failed to initialize flash driver MIMXRT1170_SFDP_QSPI.cfx
Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MIMXRT1170_SFDP_QSPI.cfx
Image 'iMXRT1170_SFDP_FlexSPI1_A_QSPI Jul 7 2022 12:15:07'
Opening flash driver MIMXRT1170_SFDP_QSPI.cfx
chip initialization failed - Ep(08). Cannot access core regs when target running.
failed to initialize flash driver MIMXRT1170_SFDP_QSPI.cfx
Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MIMXRT1170_SFDP_QSPI.cfx
Image 'iMXRT1170_SFDP_FlexSPI1_A_QSPI Jul 7 2022 12:15:07'
Opening flash driver MIMXRT1170_SFDP_QSPI.cfx
chip initialization failed - Ep(08). Cannot access core regs when target running.
failed to initialize flash driver MIMXRT1170_SFDP_QSPI.cfx
Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MIMXRT1170_SFDP_QSPI.cfx
Image 'iMXRT1170_SFDP_FlexSPI1_A_QSPI Jul 7 2022 12:15:07'
Opening flash driver MIMXRT1170_SFDP_QSPI.cfx
chip initialization failed - Ep(08). Cannot access core regs when target running.
failed to initialize flash driver MIMXRT1170_SFDP_QSPI.cfx

[kerryzhou]

Hi @rnicolls ,

  Please try the newest MCUXPresso IDE version:

https://www.nxp.com/design/software/development-software/mcuxpresso-integrated-development-environme...

  Whether you can reproduce the issues on the NXP MIMXRT1170-EVK board or not?

Best Regards,

Kerry

[rnicolls]

Hi,

I downloaded the latest IDE and the issue persists. 

Thanks,

Rory

[kerryzhou]

Hi @rnicolls ,

  Which board you are using?

  Which SDK version you are using?

  Can you reproduce the issues on the newest SDK with the MIMXRT1170-EVK board?

  If yes, tell me which SDK project you are testing, thanks. 

Please give me more information to check the issues!

Best Regards,

Kerry

[rnicolls]

Hi Kerry,

We're using the RT1176 uCom board from Embedded Artists. 

The SDK that we're using is eaimxrt1176_sdk_2_11_1_2022-05-16 but we're using our own project, not any SDK example in particular. 

I did try reproducing the issue with some of the eDMA examples but wasn't able to. My suspicion is that none of the examples are continuously triggering the eDMA like we are.

We're using the PIT to trigger the ADC_ETC which triggers the eDMA to transfer the completed conversions from the ADC. If I stop the PIT, the issue is no longer present and I can re-connect the debugger.

Thanks

[kerryzhou]

Hi @rnicolls ，

    Thanks for your information.

   Normally, meet the connection issues, is the core is lost the connection to the debugger.

   Sometimes, it is the invalid app.

   When you meet this issues, I suggest you enter the serial download mode, then you can try to download the code again, this will let the core connect to your debugger.

Wish it helps you!

Best Regards,

kerry

[rnicolls]

Hi

Do you mean to put the device in ISP mode and load the program that way. Then set the debug configuration to attach only and connect while it's running?

[kerryzhou]

Hi @rnicolls ,

    Yes,  to RT1170, ISP is the serial download mode.

    Serial download mode can drag back the debug, you can refer to my document:

https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT-board-recovery-for-debugger-connect-issues/ta...

Wish it helps you!

Best Regards,

Kerry

[rnicolls]

Hi Kerry,

I'm actually already aware of this way of recovering the MCU, the issue with that method is that we'd have to do this every time we want to flash the chip and debug. 

As long as the application is running the DMA continuously, we cannot connect to the core. Is there some way of configuring the DMA so that it will allow the debugger to connect? Is there someway of halting the DMA when we're connecting?

Thanks,

Rory

[kerryzhou]

Hi @rnicolls ,

    I am thinking, whether you can add one GPIO input in the code, if you want to connect the debugger, then the code detect the GPIO input status, and stop the continuous DMA.

    Then, the debugger can connect and without the influence from continuous DMA.

Best Regards,

kerry

[rnicolls]

Thank you,

I'll explore this solution and see if it works for us. 

Is there anything in the debug configuration that will halt peripherals when the debugger tries to connect?

[kerryzhou]

Hi @rnicolls ,

  Another way, add some delay in the main, before you do the DMA operation.

Then, press reset, debug, just let the DMA not influenced.

You can try it.

Best Regards,

kerry