Page 1 of 1

Issues with On-Chip debugging

Posted: Tue Feb 15, 2022 4:35 pm
by jjavierk
Using the virtual machine provided by BitCraze, I followed the instructions on https://www.bitcraze.io/documentation/r ... debugging/ to enable on-chip debug on VS code. Still, the GDB times out before starting the debug session, with the following message: failed to launch openocd gdb server: timeout. Does anyone had the same issue and got it solved?

Re: Issues with On-Chip debugging

Posted: Fri Feb 18, 2022 7:56 am
by kristoffer
Hi!

The first thing to check is probably that the VM can access the debugger via USB. The LED on the debugger (if you have an ST link) should flicker a bit when you start a debug session and the computer communicates with it

Re: Issues with On-Chip debugging

Posted: Mon Feb 21, 2022 10:48 pm
by jjavierk
This is actually the case. When the process starts, the led(s) on the j-link, as stated, start flickering (red/green), right after the debug session is launched. I can even read the target voltage from the console. Can you confirm that the JSON file offered as in the example in https://www.bitcraze.io/documentation/r ... debugging/ still holds? I'm attaching screens from the debug console and terminal if it is of any help.
Untitled.png

Re: Issues with On-Chip debugging

Posted: Tue Feb 22, 2022 4:14 pm
by kimberly
hi!

It seems that the gdb server is started and then closed afterwards as you said so it is not an USB problem.

Hmmm this issue looks a bit familiar to me. It might be that you have too many watch and breakpoints. Could you try to remove all of them, and try again?

Re: Issues with On-Chip debugging

Posted: Tue Feb 22, 2022 5:13 pm
by jjavierk
Thanks for the reply. Actually, there are no breakpoints/watchpoints inserted. I think that what the info msg is saying (stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints) refers to the actual hardware capabilities of the MCU.

Re: Issues with On-Chip debugging

Posted: Wed Feb 23, 2022 12:28 pm
by kimberly
Ah yes you are right about that line.

I've downloaded a fresh copy of the VM, setup the debugging and such, and yes I saw a similar problem. The thing is, that I first did a make, updated the projects and then setup the debugging. The culprit is that the location of the cf2.elf has change in the mean time, as of the latest changes with the kbuild system in the firmware now.

You should change this line in the json file:

Code: Select all

            "executable": "build/cf2.elf",
In my case, it grabbed the old cf2.elf I made in a older version of the firmware, therefore the openocd debugging failed on me, so I'm expecting that you have a similar problem that you still have an old cf2.elf in your repo (since you are not getting an error that it can't find the executable). If you have your important changes commited, please do a clean of your repository with

Code: Select all

 git clean -f
or remove the old cf2.elf in the root by hand.

Let me know if this fixes anything for you!