Debugging problem.

[kostbill]

Hi,

I have the esp32 wrover kit 3. I am debugging with the usb cable with jtag. Until yesterday it worked.

Now I cannot make it stop on breakpoints.

Even before it programs the flash, it outputs “Warning: could not set a breakpoint on main. ‘Step into new instance’ will not work.”

I have set the semihosting and it works fine. I just want it to stop at breakpoints.

I read some of the questions here, but they deal with setting flags that I cannot find in the configuration.

Thanks.

[kostbill]

oh, I just disabled the semihosting and it stopped at a breakpoint.

When we have semihosting, breakpoints do not work??

[support]

Hi,

No problem. Turns out the Espressif’s OpenOCD port was inadvertently resuming the target when starting the semihosting client, preventing gdb from handling the breakpoints properly. We have patched it and released an updated toolchain. Please update to R15.

[kostbill]

That was quick and nice! It works now, thank you very much!

[kostbill]

Hello again.

Debugging is not working any more. I changed several things but I re-created the project from scratch and I cannot set it to work.

When I try semihosting now, the “Inline GDB Stub Output” outputs the line:

Target halted. PRO_CPU: PC=0x400E08FE (active)    APP_CPU: PC=0x401396EA

many times, with visible delay, about perhaps 4 messages per second and I get garbage in the “ESP32 Semihosting” output.

I attach the image.

Thanks for any help.

Attachments:

You must be logged in to view attached files.

[kostbill]

I found it, it was a wrong buffer that I was trying to print on.

Also, the slow response with the messages, is only when I step over my semihosting debug function.

Thanks.

[kostbill]

However I can see that some times the debug semihosting messages are not printed.

Is this because of the rate that they get pulled?

Can I change this somehow?

[support]

Hi,

On the ESP32 platform, the semihosting client is actually a part of the Espressif’s OpenOCD port. VisualGDB starts it using the “monitor esp32 apptrace start” command and then forwards the output to the output window. The exact low-level logic of it is unfortunately outside VisualGDB’s control.

The best way to get it to work would be to narrow down a specific sequence of steps that reproduces the problem (e.g. certain program, certain breakpoint locations), reproduce it by manually running the “monitor esp32 apptrace start” command via the GDB Session window and forward the details to Espressif. As they have a more detailed knowledge of their tools’ internals, they might be able to tell what is going on.

[kostbill]

Thanks for the answer.

[Author]

Posts