LinkServer problems when debugging

[tbonkers]

I can upload and erase flash using a custom LinkServer algorithm, however I cannot debug. Starting gdbserver works, however when trying to connect I get a myriad of errors:

INFO: [stub (3333)] Pb: (100) Finished writing Flash successfully.
INFO: [stub (3333)] Wc: ============= SCRIPT: RT1160_reset_M7.scp =============
Wc: This probe = 1
Wc: This TAP = 0
Wc: This core = 0
Wc: SYSTEM Reset
Wc: Wirespeed = 10000000 Hz
Wc: Error: Wire Ack Fault - target connected?
Wc: DpID = 6BA02477
INFO: [stub (3333)] Wc: TAP 0: 6BA02477 Core 0: M7  APID: 84770001 ROM Table: E00FD003*
Wc: TAP 0: 6BA02477 AP   1:     APID: 24770011 ROM Table: E00FF003
Wc: TAP 0: 6BA02477 AP   2:     APID: 54770002 ROM Table: 00000002
Wc: APID = 0x84770001
Wc: View cores on the DAP AP
Wc: TAP 0: 6BA02477 Core 0: M7  APID: 84770001 ROM Table: E00FD003*
Wc: R15 = 0x00223104
Wc: Vector table SP/PC is the reset context.
Wc: PC = 0x3000EF1D
Wc: SP = 0x8021C450
Wc: XPSR = 0x01000000
Wc: VTOR = 0x30002000
Wc: Set DEMCR = 0x010007F1
Wc: ============= END SCRIPT ==============================
INFO: [stub (3333)] Nc: Using memory from core 0 after searching for a good core
INFO: [stub (3333)] Pc: ( 30) Emulator Connected
INFO: [stub (3333)] Pc: ( 40) Debug Halt
INFO: [stub (3333)] Pc: ( 50) CPU ID
INFO: [stub (3333)] Nc: debug interface type      = CoreSight DP (DAP DP ID 6BA02477) over SWD TAP 0
Nc: processor type            = Cortex-M7 (CPU ID 00000C27) on DAP AP 0
Nc: number of h/w breakpoints = 8
Nc: number of flash patches   = 0
Nc: number of h/w watchpoints = 4
INFO: [stub (3333)] Wc: ============= SCRIPT: RT1160_reset_M7.scp =============
Wc: This probe = 1
Wc: This TAP = 0
Wc: This core = 0
Wc: SYSTEM Reset
Wc: Wirespeed = 10000000 Hz
Wc: DpID = 6BA02477
Wc: TAP 0: 6BA02477 Core 0: M7  APID: 84770001 ROM Table: E00FD003*
Wc: TAP 0: 6BA02477 AP   1:     APID: 24770011 ROM Table: E00FF003
Wc: TAP 0: 6BA02477 AP   2:     APID: 54770002 ROM Table: 00000002
Wc: APID = 0x84770001
INFO: [stub (3333)] Wc: View cores on the DAP AP
Wc: TAP 0: 6BA02477 Core 0: M7  APID: 84770001 ROM Table: E00FD003*
Wc: R15 = 0x00223104
Wc: Vector table SP/PC is the reset context.
Wc: PC = 0xFFFFFFFF
Wc: SP = 0xFFFFFFFF
Wc: XPSR = 0x01000000
Wc: VTOR = 0x30002000
Wc: Set DEMCR = 0x010007F1
Wc: ============= END SCRIPT ==============================
INFO: [stub (3333)] Nc: state - running or following reset request - re-read of state failed - rc Nn(05). Wire ACK Fault in DAP access
INFO: [stub (3333)] Xw:
INFO: [stub (3333)] Nc: state - running or following reset request - re-read of state failed - rc Nn(05). Wire ACK Fault in DAP access
INFO: [stub (3333)] Nc: state - running or following reset request - re-read of state failed - rc Nn(05). Wire ACK Fault in DAP access
INFO: [stub (3333)] Nc: state - running or following reset request - re-read of state failed - rc Nn(05). Wire ACK Fault in DAP access
INFO: [stub (3333)] Nc: state - running or following reset request - re-read of state failed - rc Nn(05). Wire ACK Fault in DAP access

The second reset script invocation seems to be where the problem occurs. Strangely enough, when I start LinkServer gdbserver with --attach option, I can connect with the debugger.

The issue might have something to do with the FlexSPI control block - when I'm using Octal DDR mode, I can connect and debug; when I'm using XSPI I can't.

[tbonkers]

I believe the problem might stem from the .cfx driver applying the wrong configuration option to the FlexSPI. I'm using IS25WX256 in Extended SPI mode. The LinkServer flash driver applies CONFIG_OPTION1 0xC0603001.

I tried using different CONFIG_OPTION1 in the flash driver (0xC0000001), but the problem with debug not working persists. When using MCUXpresso Secure Provisioning Tool, I can read/write flash using config option 0xC0000001.

Is there a way to get the currently applied config option from the FlexSPI ROM API?

[carlos_o]

Hi @tbonkers 

Thanks for your post.

Could you please provide the chip you are using?

Is it a custom board? if not please provide which one you are using.

Could you please provide the reason why you need to use a custom script to use LinkServer?

[tbonkers]

Hi,
I am using a custom board with MIMXRT1166CVM5A and octal flash IS25WX256.
I've had to use a custom algorithm for LinkServer as the reset pin of the flash does not match the reset pin used by MIMXRT1160-EVK.

[carlos_o]

Hi @tbonkers 

This are some guide or information related to scripting with LinkServer

Solved: LinkServer automation with python - NXP Community

LinkServer Scripting, and how to Recover MCUs with a Script | MCU on Eclipse

I also recommend you review the script provided with the LinkServer at yourlinkserverlocation/binaries/scripts/

BR

[tbonkers]

I've managed to get debugging to work. However I cannot reset the board during debugging with gdb.

I think it may be caused by the flash configured for DDR mode by the application - when I reset the mcu, the flash is not reset and cannot be initialized.

I've modified the LinkServer driver to use a custom pin which works and I can flash, erase and debug. Is there another piece of code which must reflect the modified reset pin the LinkServer drivers? I found this line in "LinkServer-FlashDrivers.md"

FlexSPI Flash reset
A number of IMX RT MCUs that support external flash via the FlexSPI interface implement a flash device reset sequence.
During FlexSPI boot the boot process requires the FlexSPI Flash device to be in a certain mode, for example, 1-bit SPI compatible mode. The Flash
device will naturally be in this mode after a POR reset because the power-up sequence will reset it with the RT MCU device together. However, the
Flash device will not be in 1-bit SPI compatible mode if the flash device is configured to DPI mode or QPI mode or Octal mode when any non-POR
resets happen. In such case, special processing is required by the boot process to restore the Flash device to 1-bit SPI compatible mode before
continuing access to the Flash device. In general, this can be achieved by using a GPIO to assert a reset pin on the Flash device. The bootloader
can perform the reset process and reset the Flash device to 1-bit SPI compatible mode based on fuses configuration, using the GPIO specified by
the combination of FLEXSPI_RESET_PIN_PORT and FLEXSPI_RESET_PIN_GPIO.
When starting a flash-resident debug session this reset sequence may need to be performed by the flash driver as well. Flash drivers for IMX
RT500 and RT600 MCUs implement this functionality.
Note: Custom boards may not be wired identical to EVK development boards in regards to the actual pin dedicated to flash device reset. In such
cases the pre-connect script needs to be modified in order to pass to the flash drivers the relevant information about the GPIO pin used for flash
reset. 

What does "flash-resident debug session" mean in this context? I was not able to find a dedicated reset function in the LinkServer algorithm for MIMXRT1170, which I used as a base. The only time a reset is performed is in the `uint32_t Init(void)` function.

[MultipleMonomials]

Long shot, but maybe my previous thread would be helpful? https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Debuggers-cannot-connect-to-MIMXRT1062-after-cor...

If you are saying that you can't issue a core reset from within the debugger and have things work, then yeah that is not normal. But if you mean that when the core resets itself the debug session dies, then that is actually expected. Per Gavin this is not supported by LinkServer and will lead to your debug session dying. IIRC, I saw this with J-Link as well... seems like some kind of limitation inherent to the MCU.