[support]

Hi,

Thanks for the update. It looks like OpenOCD does get an incoming connection from gdb, so the problem should not be caused by the firewall (OpenOCD likely ends the connection when it discovers some critical error without showing more details).

If OpenOCD works with another board, we would advise comparing the schematics of the 2 boards and checking JTAG signals on both boards with an oscilloscope.

[support]

Hi,

As OpenOCD doesn’t mention an incoming gdb connection, it looks like something (likely a firewall or antivirus) is blocking it. Please try disabling your firewall/antivirus software and try again. Please also consider starting a debug session and checking the logs from both gdb and OpenOCD (double-check that both are using the same TCP port). If the OpenOCD does show the “incoming gdb connection” message, please share the updated log and we will help you find the relevant message.

[support]

Hi,

Please try updating to VisualGDB 5.4 Preview 10.

[support]

Hi,

Sorry, not currently. This Thread & ZigBee SDK appears to be much less popular than the regular Nordic SDK, so we won’t be supporting it directly unless it’s merged into the mainline SDK, becomes more popular, or someone orders it via our custom BSP program.

Please consider creating a project manually as shown in this tutorial: https://visualgdb.com/tutorials/arm/legacy/

[support]

Hi,

VisualGDB-generated projects contain all necessary code inside the main .c or .cpp file, hence they do not need separate _it.c and main.h files.

If you get errors due to missing _it.c file, most likely you have replaced the main source file with the main file from another project that also includes the _it.c and main.h files. If this is the case, please ensure you copy ALL the relevant files from the project you are trying to import.

[support]

Hi,

You can disable the automatic activation of the GDB Session window via Tools->Options->VisualGDB->General->GUI->Don’t Activate GDB Session window.

We have also added an option under General->Debug to ignore the inline gdb stub output to this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2623.msi

[support]

Hi,

Thanks for reporting this. We have investigated it and it looks like the behavior for missing source paths has changed in a recent VS update. The file path actually comes from the debug symbols in the libraries on Raspberry Pi and it indeed does not exist on your machine. The previous VS versions would ask for the path of the file, but it looks like the latest VS build shows an error instead.

We have addressed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2623.msi

VisualGDB will now report frames referencing non-existing frames as assembly-only (you can override this via Tools->Options->VisualGDB->Common->Debugging->Hide Missing Source Files).

[support]

Hi,

Please consider updating to VisualGDB 5.4 Preview 10. It should support the latest project layout from Android Studio. If your project uses different directories for APK files and libraries, please consider editing the .vgdbcmake file accordingly (see the OutputSubdirectory, AppSubdirectory and LibraryDirectory elements).

[support]

Hi,

VisualGDB takes the Android platform list from the <VisualGDB directory>\Rules\Android\AndroidPlatforms.xml file. If the platform you are using it not listed there, please consider editing the file, or using the latest VisualGDB 5.4 Preview 10 that includes the definitions for the latest platforms.

VisualGDB provides 2 different settings for the Android platforms: SDK platform and NDK platform (that might be different for older SDK/NDK versions). The SDK platform setting corresponds to the project.properties file used by Ant, while the NDK platform corresponds to the Application.mk file.

[support]

No problem. Let us know if you have further questions and we will be happy to help.

[support]

Hi,

The files you mentioned are generated by the STM32CubeMX tool and can be imported into VisualGDB as shown in this tutorial. They are indeed not a part of the basic project templates.

The “Inline GDB Stub Output” window contains text sent to the gdb session by the gdb stub (e.g. OpenOCD or Segger J-Link) and typically contains error and warning messages (sometimes repeating the regular stub output).

You can use the Memory window to view the memory contents at a specific address.

[support]

Hi,

Are you using the GCC ARM toolchain or the Keil ARM toolchain (that is supported since v5.4 Preview 10)?

[support]

@MystikReasons, Thanks for sharing this!

[support]

Hi,

Thanks for the logs. It looks like the ESP32 chip does not respond properly to JTAG commands and OpenOCD drops the connection:

Error: cpu0: esp32_fetch_all_regs (line 255): DSR (120034E5) indicates target still busy!

Please try erasing the target FLASH memory using esptool.py. If this doesn’t help, please share the OpenOCD log above with Espressif and check if they know any workarounds (we do not have access to the internal Espressif’s documentation, so it’s hard for us to provide any more specific help when it comes to communication issues between various components that are not maintained by us).

[support]

Hi,

It looks like you are using the ARM build of gdb that is not compatible with the ESP32 devices. Please use our ESP32 toolchain instead. You can find a detailed step-by-step tutorial here: https://visualgdb.com/tutorials/esp32/esp-idf/

[Author]

Posts