Debugger Fail to Connect

[andreastornes]

I am creating a custom bootloader for a k64 microcontroller on a custom board. Software is coded using Kinetis SDK 2.0, and I am debugging using Segger J-Link. This is my first attempt in creating a custom bootloader, and mistakes have been made.

After attempting to jump to user app the system crashed, and I lost the debug connection completely, and received this error message when attempting to reconnect: "J-Link GDB Server failed: Could not connect to target. Please check if target is powered and if ribbon cable is plugged properly". I suspect that when restarting the system, the same crash occurs and prevents the debugger to ever make the connection. I was able to restore the connection by using reset strategy 2 (this option will reset the controller by pulling the reset pin low, and halt the program execution ).

I read that the debug connection may be lost if the cpu executes random code. I verified that the user application was correctly written to flash, and made another attempt. The jump to the reset handler of the user app was made correctly, and even made it to main. However, when calling BOARD_BootClockRUN() the system crashed again (this was the second time this function was called, as the bootloader does it as well). The debug connection was lost again, but now I am not able to restore it. Scoping the reset pin verifies that the pin is correctly toggled low by the debugger, but still not able to connect. I have also tried all the other reset strategies, and another J-link adapter, without success.

Atm, there is no other way to flash another application to the controller than using the debugger. I can really use some help to get it working again. Also, can anyone explain why this is happening?

[andreastornes · Accepted solution]

Solved by executing J-link script from https://community.nxp.com/thread/439921?commentID=857127#comment-857127. This board does not have a reset button, but it worked by applying power to the board just as the script started.

Many thanks to the NXP support team for finding the solution!