Update OpenOCD

[vard]

I have an issue with breakpoints in my ESP32 project: debugger won’t stop at breakpoints.  A colleague of mine is using a Linux machine for ESP32 development and had similar issues, but he solved them by upgrading to the latest  version from 2018-07-24 (See issue 51 in Github espressif -openocd). How can I manually update to the latest version? Trying to do it via the VisualGDB package manager doesn’t seem to work, the package manager doesn’t see the latest release.

Can I update the openocd manually, by just replacing the files in the ../com.sysprogs.arm.openocd/ folder?

Thank you!

[support]

Hi,

The OpenOCD build that is included in our toolchains includes some fixes and usability improvements compared to the original ESP32 OpenOCD. You can get the source code (including a VisualGDB project for convenient building with CMake) here: https://github.com/sysprogs/openocd-esp32

For your convenience we have merged the latest commits from the Espressif’s branch into our fork and uploaded a built version here: http://sysprogs.com/files/tmp/esp32/openocd.exe

[vard]

Awesome ! Works like a charm! And thank you for taking your time to make the exe file, much appreciated!

 

[vard]

Hmmm…. I’m still seeing some problems, but of a more or less different kind this time around: On a clean memory ESP32 (flash erased), I can do a Debug Test Settings from VisualGDB properties page and everything works fine. Then I program the chip and run the program, no problem. But if I make any changes in the code and try to program again, the debugger fails to connect and program the ESP32. I get an error: Failed to get flash maps(-1)!

The stub log looks like this:

c:\sysgcc\esp32\esp32-bsp\OpenOCD\bin\openocd.exe -c “gdb_port 55856” -c “telnet_port 55857” -f interface/ftdi/esp32_devkitj_v1.cfg -c “adapter_khz 3000” -f target/esp32.cfg -c “echo VisualGDB_OpenOCD_Ready”
Open On-Chip Debugger 0.9.0 (2018-07-30)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
adapter speed: 3000 kHz
Info : auto-selecting first available session transport “jtag”. To override use ‘transport select <transport>’.
force hard breakpoints
VisualGDB_OpenOCD_Ready
Info : clock speed 3000 kHz
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : Target halted. PRO_CPU: PC=0x40009070 (active) APP_CPU: PC=0x400076DD
Info : accepting ‘gdb’ connection on tcp/55856
Info : Target halted. PRO_CPU: PC=0x4009170E (active) APP_CPU: PC=0x400076DD
Error: Failed to get flash maps (-1)!
Error: Failed to get flash mappings (-4)!
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use ‘gdb_memory_map disable’.
Error: attempted ‘gdb’ connection rejected

Going back to the VisualGDB Project Properties page, I can no longer get a successful test, the test console window displays the same message as the above stub log.

The only way I can get this back to work is to use the ESP32 Download tool to erase the flash. After erasing the flash, the test works correctly and I can go ahead an program the chip:

c:\sysgcc\esp32\esp32-bsp\OpenOCD\bin\openocd.exe -c “gdb_port 55959” -c “telnet_port 55960” -f interface/ftdi/esp32_devkitj_v1.cfg -c “adapter_khz 3000” -f target/esp32.cfg -c “echo VisualGDB_OpenOCD_Ready”
Open On-Chip Debugger 0.9.0 (2018-07-30)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
adapter speed: 3000 kHz
Info : auto-selecting first available session transport “jtag”. To override use ‘transport select <transport>’.
force hard breakpoints
VisualGDB_OpenOCD_Ready
Info : clock speed 3000 kHz
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32: Debug controller was reset (pwrstat=0x5F, after clear 0x0F).
Info : esp32: Core was reset (pwrstat=0x5F, after clear 0x0F).
Info : accepting ‘gdb’ connection on tcp/55959
Info : Target halted. PRO_CPU: PC=0x40090616 (active) APP_CPU: PC=0x00000000
Info : Target halted. PRO_CPU: PC=0x4009170E (active) APP_CPU: PC=0x00000000
Info : Target halted. PRO_CPU: PC=0x4009170E (active) APP_CPU: PC=0x00000000
Info : Auto-detected flash size 4096 KB
Info : Using flash size 4096 KB
Info : dropped ‘gdb’ connection
Info : Restore debug stubs @ 0 on core0 of target ‘esp32’

All seems to be working fine after that except… it no longer wants to stop to any break points (again)!

During debug I can go into the GDB Session window and try the Diagnose Breakpoint Problems button but the answer is “No breakpoint problems detected”

So it worked beautifully the first time I tried the latest OpenOCD versions, but now it’s doing the same thing as before, plus the programming issue (I have to erase the flash to program it).

I tried it on 3 different debuggers (I tried ESP32 Devkit, Olimex and Segger Jlink) and two ESP32 boards (Devkit and ESP core V2).

Any suggestions?

Thanks again for all the help and support!

 

 

[support]

Hi,

Sorry, OpenOCD is maintained by Espressif, please consider asking at their forums. Our changes to their OpenOCD fork focus on usability improvements and out-of-the-box experience on Windows, but we don’t touch low-level device interaction logic as it changes very often between releases and relies on undocumented ESP32 internals.

We will run a few advanced tests on this build before releasing it officially and might be able to fix it if we reproduce it reliably and it turns out to be something trivial, or delay until Espressif fixes it, but we are not able to do any deep diagnostics beyond that.

Another option would be to try finding out the exact commit hash of the Linux build you are using, merging that commit into our OpenOCD fork and building it. If the problems you are experiencing are caused by some changes after that commit, this might help.

[vard]

Fair enough, thanks again for all the help!

[support]

Hi,

Just wanted to let you know that we did a few extra tests on our side and it looks like we were able to locate and fix the source of the problem. We will release an update to the ESP32 toolchain after the upcoming v5.4 Preview 4 release that will include the newest OpenOCD build with this issue resolved. Please expect an update within the next 3 business days.

[vard]

That’s very nice of you, thank you for going out of your way to help with this issue!
Looking forward to trying out the new preview release.

[support]

Hi,

We have released the updated VisualGDB 5.4 Preview 4 and the ESP32 toolchain (R10). Please try installing both updates and let us know if the problem is solved.

[vard]

Hi,

I’ve downloaded and installed VGDB 5.4 Preview 4 and the latest ESP32 toolchain (R10) but now I have a different issue: I can’t see the debug configuration. Under the “Debug settings” tab, I’ve selected “Debug using ESP32 Devkit” but I got a “Failed To Display Configuration” error:

System.MissingMethodException: Method not found: ‘BSPEngine.IAdvancedProjectDebugContext BSPEngine.IBSPConfiguratorHost.get_AdvancedModeContext()’.
at OpenOCDPackage.OpenOCDSettingsEditor..ctor(IBSPConfiguratorHost host, String baseDir, OpenOCDSettings settings, KnownInterfaceInstance context, Boolean autoDetectDevice)
at ESP8266DebugPackage.ESPxxOpenOCDSettingsEditor..ctor(IBSPConfiguratorHost host, String baseDir, ESPxxOpenOCDSettings settings, KnownInterfaceInstance context, Boolean isESP32)
at ESP8266DebugPackage.GUI.ESPxxOpenOCDSettingsControl.SetConfiguration(Object configuration, KnownInterfaceInstance context)
at VisualGDB.Common_GUI.WPF.DebugMethodSettingsControl.Controller.set_SelectedItem(MethodOrDeviceItemBase value)

[vard]

I’ve re-installed everything from  scratch, I no longer get that error, and the debugger seems to stop just fine at the first breakpoint! I can even step through the code!

Very nice, many thanks!

[support]

Hi,

Good to know it works. If you encounter any further problems, don’t hesitate to contact us again.

[Author]

Posts