Debug Connection Failure

[DirkG]

Dear all,

i have two  S32K3X4EVB-T172 Boards.

One of them is behaving fine, that means i'm able to connect to the board using Segger J-Link Ultra. 

The other one does not allow a debugging connection. I'm using the same software setup and all jumpers are set exactly the same. Every time i want to connect to the board, the RESET_K3 (D3) is blinking. It's not possible to erase the memory using the Segger Tools. 

This behaviour started after flashing a software and debugging it. From this point in time i'm not able to connect again to the board or to ersase the memory. 

Is there a possibility to reset the board? Perhaps by pressing a push button for a longer time?

Thanks in advance for your help.

Best Regards

Dirk

[StarryKnight04]

Debug connection issues can often be linked to incorrect settings, hardware problems, or loose connections. Check if your debugger and target device are properly set up, ensure all drivers are installed, and confirm that the device is in debug mode. Also, double-check your cables and power connections.

[DirkG]

Hello Fira,

thanks a lot for your reply.
I can confirm that the debugger and the hardware setup is fine, due to the fact that I'm able to connect and debug the second board.
The issue occurred as soon as I debuged a software and caused an exception. From that point in time the hardware is not connectable any longer, also not to the Segger Tool like J-Flash Lite, to erase the memory.
Best Regards
Dirk

[RomanVR]

Hi @DirkG!

I have some questions to get to know more about your issue:

• Is it possible for you to share more details about the software you flashed and debugged before the behavior started showing?
• Have you seen the same behavior using the onboard debugger? 
• Additionally, could you please provide us with an image of your reset signal?
• Have you tried loading an example available for your board and RTD version? If not, could you try and tell us if you see the same behavior?

- RomanVR.

[DirkG]

Dear Roman,

many thanks for you fast response.

>>>

• Is it possible for you to share more details about the software you flashed and debugged before the behavior started showing?

of course, we tried to add one more CAN channel (CAN1) using the config tools. Afterwards we debugged the firmware and figured out the "Port_Init" causes an exception. But from that point in time, the hardware was not longer accessible to the debugger.

If you want, I can also provide the project.

>>>

>>>

• Have you seen the same behavior using the onboard debugger?

Right now im trying to get the onboard debugger working, but up to now the board is not recognised as soon as I connect it by USB. Do I miss some drivers? Or shall I try another USB Cable?

>>>

• Additionally, could you please provide us with an image of your reset signal?

Do you speak about the firmware, which caused the malbehaviour? If yes, I can provide it.

>>>

>>>

• Have you tried loading an example available for your board and RTD version? If not, could you try and tell us if you see the same behavior?

We started with an example provided by RTD. Right now, the board is in a state which does not accept flashing firmware to it. It also does not accept "erasing memory" by the Segger Tools. It also does not accept "attach to running target".

Can you please provide a possibility to me to get this board up and running again. Is there a possibility to do a "reset to default state" to be able again to flash firmware to it.

Right now it seems to me, that always the hardware I showered on, the "faulty firmware" on it causes an exception and due to that reason I'm not able to connect to the hardware and replace the firmware.

Your help is really appreciated.

Best Regards

Dirk 

>>>

[RomanVR]

Hi @DirkG 

You could try a solution that worked for the S32K1 device family. To re-flash your MCU, keep the reset button pressed while trying to flash it with a blink example. It might fail and ask if you want to retry. When that happens, release the reset button and then try again to load the program under that prompt. After doing this, the program should load successfully and the board should recover.

Also, it would be helpful if you could check the reset signal with an oscilloscope. Just measure the reset pin directly and share an image of what you see. We're expecting a signal similar to the one attached, with the reset toggling as shown.

If possible, please share your project so we can test from our side as well.

- RomanVR

[DirkG · Accepted solution]

Dear Roman,

the handling you described, reset button pressed and then repeat the flashing, did work!!!

The board is now up and running again.

Nevertheless, please find attached the "buggy project" as zip file, I just leave in everything, also the generated source code.

Please come back if you can figure out what happened.

Best Regards and many thanks for your support.

You really saved my day.

Dirk

[DirkG]

Sorry, I forgot to upload the "buggy project".

Best Regards

Dirk

[DirkG]

A Short Add on:

In the meanwhile the onboard debugger seems to run, but it shows an similar behaviour:

Here is the debugger configuration dialog:

It would be great if you could provide a possibility to me to get the hardware up and running again.

Is there some possibility to erase the memory of the microcontroller?

Is there some possibility to restore default settings to the hardware?

Best Regards

Dirk