Unable to reset by board using MCUXpresso and SEGGER JLink

[rshipman]

Hi.

I've not been able to get the SEGGER JLink to successfully reset the board (RT1021 with SDRAM etc).

Currently I have to manually reset the board (i.e. press a physical button) and then launch the debugger. This works fine as long as I have an empty ResetTarget() function in my script, so that no attempt to reset the board is made by MCUXpresso/SEGGER.

If I do not have a ResetTarget() in the script, and instead rely on the SEGGER JLink reset strategy then the program never loads.

Using an empty ResetTarget() function in the script:

• If I manually reset the board before debugging then it all works with no hardfaults.
• If I do not manually reset the board before debugging then I usually get a hardfault, presumably because the SDRAM has not been reset when it tries to access it. The symptoms vary, but usually involve a hardfault.

Using no ResetTarget() function in the script:

• Set the reset strategy to type 2 in the .launch file.
• The board is reset.
• MCUXpresso seems to just stop launching with a callstack like this:
  • MyApplication JLink Debug [GDB SEGGER Interface Debugging]
  • MyApplication.axf
  • arm-none-eabi-gdb (12.1.90.20221210)
• Console just shows this:
  • Executed SetRestartOnClose=1
  • [MCUXpresso Semihosting Telnet console for 'MyApplication JLink Debug' started on port 53093 @ 127.0.0.1]
  • SEGGER J-Link GDB Server V7.94k - Terminal output channel
• So I give up and kill the session using the 'Clean Up Debug' button.

Using simple ResetTarget() function in the script:

void ResetTarget(void)
{
    JTAG_ResetPin = 0;      // Active low.
    JLINK_SYS_Sleep(500);   // 0.5 seconds - time to reset
    JTAG_ResetPin = 1;
    JLINK_SYS_Sleep(1);     // 1 millisecond - time to recover
}

• MUCXpresso does not run the app, but we get this callstack:
  • MyApplication JLink Debug [GDB SEGGER Interface Debugging]
    MyApplication.axf
  • Thread #1 57005 (Running : User Request)
  • arm-none-eabi-gdb (12.1.90.20221210)
• I'm not surprised this does not work because the manual says to halt the CPU in this function etc.

Calling the ResetTarget() function I got from SEGGER (see attached script), from my ResetTarget() after doing the above pin reset. I was hoping the SEGGER reset code would do all the necessary CPU halting etc (which it seems to, among other things) after I toggled the reset pin:

• MUCXpresso does not run the app, but we get this callstack:
  • MyApplication JLink Debug [GDB SEGGER Interface Debugging]
    MyApplication.axf
  • Thread #1 57005 (Running : User Request)
  • arm-none-eabi-gdb (12.1.90.20221210)

I don't really understand what is going on here. I had a try months ago and gave up, so I thought I would try again. Still no luck. Any help would be greatly appreciated.

What I don't understand is why simply setting the type 2 reset strategy in the MXUXpresso .launch file does just work, especially when I do not have a ResetTarget() function.

MCUXpresso IDE v11.8.1 [Build 1197] [2023-10-27]
SEGGER J-Link GDB Server V7.94k

Many thanks.

[diego_charles]

Hi @rshipman 

Thank you for reaching out and for your patience. 

Could you explain how one could replicate your issue? How is you application linked? Do you see this issue even with LED blinky linked to run from flash? Did you see this with our EVK? 

According to Segger's documentation    Reset strategy type 2 will fail if the RESET pin of the target device is not pulled low. 

How is your connection to the POR_B pin of the RT1020? Plese share a illustration of your connection if you are using a your custom board. 

Let me know if you have found anything else in this time. 

Thank you,

Diego