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.