[support]

No problem. BTW, the new BSP has passed all the tests and has just been released. You can install it via VisualGDB Package Manager as usual.

It also includes out-of-the-box support for AzureRTOS (ThreadX, FileX, LevelX, UsbX) thanks to the ST’s new X-CUBE-AZRTOS packages.

Also feel free to try out the new VisualGDB build that automatically recognizes and displays ThreadX threads (Custom edition and higher): VisualGDB-5.6.102.4517.msi

[support]

No problem and good to know it works. BTW, the copy command didn’t work because it’s not a separate executable, but rather a virtual command provided by cmd.exe. Setting executable path to “cmd.exe” and the arguments to “/c copy <…>” should to the job.

[support]

Hi,

Sounds like a reasonable workaround, thanks for sharing this!

[support]

Hi,

This looks like something coming from the Keil compiler and not from VisualGDB. Please consider contacting Keil support regarding this.

[support]

Hi,

Strange, this is different from what we have observed. Perhaps you are using a different device revision.

Either way, you can configure VisualGDB to install the driver on the inner node by adding the Interface element the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.esp32.core\QuickSetup\interfaces.xml file as follows:

  <ProgrammingInterface>
    <ID>esp_usb_jtag</ID>
    <Name>ESP32C3 built-in JTAG</Name>
    <ScriptFile>interface/esp_usb_jtag.cfg</ScriptFile>
    <UsbIdentities>
      <UsbIdentity>
        <VID>303A</VID>
        <PID>1001</PID>
        <Interface>02</Interface>
      </UsbIdentity>
    </UsbIdentities>
    <UniversalDriverId>com.sysprogs.libusb.mini</UniversalDriverId>
  </ProgrammingInterface>

 

[support]

No problem Please try locating the View->Debug->VisualGDB Output->OpenOCD window. It will contain the output from OpenOCD – the open-source tool that handles the actual FLASH programming. It should normally explain what is going on.

Most FLASH programming issues with OpenOCD can be resolved by:

• Trying to use the ST fork of OpenOCD instead of the mainline (selectable via VisualGDB Project Properties) and/or the OpenOCD script generated by STM32CubeIDE for this specific device, rather than the one from the OpenOCD repository.
• Padding/aligning small FLASH sections.
• Switching to Segger J-Link with the J-Link software that is generally more reliable than open-source GDB.

You can also try reproducing the issue outside VisualGDB as follows:

1. Take a note of the OpenOCD command line from the VisualGDB Output window
2. Run it manually with the same command line
3. Start GDB manually (arm-none-eabi-gdb.exe <your ELF file>) and run the following commands:
   1. target remote :<OpenOCD GDB port>
   2. load

You should get the same error message as shown by VisualGDB. If you would like to troubleshoot it, you would need to step through the debug build of OpenOCD and possibly patch the STM32F7 FLASH driver. See this tutorial for a detailed example of building OpenOCD from sources.

[support]

Hi,

VisualGDB installs the WinUSB driver for the root node of the ESP32-C3 debug interface (USB\VID_303A&PID_1001 instead of USB\VID_303A&PID_1001&MI_02) because the Espressif’s port of OpenOCD fails to recognize it otherwise. You can recheck it by right-clicking on the “USB JTAG/serial debug unit” in Device Manager, selecting “Uninstall device” and replugging it. The COM port will reappear in the Device Manager, but OpenOCD won’t recognize it.

You can retest it by running ESP32 OpenOCD manually:

openocd.exe -f interface/esp_usb_jtag.cfg -f target/esp32c3.cfg

Installing the driver to the root node gets OpenOCD working, but indeed hides the COM port.

Feel free to report this to Espressif, or make your own patch to OpenOCD resolving this issue. If you can get OpenOCD to work without installing the WinUSB driver to the root device node, we can gladly update VisualGDB to not do it.

[support]

Hi,

We usually release updated BSPs when the underlying SDKs get major updates. ST has recently been mostly focusing on the wireless devices (e.g. STM32WL) and changing the structure of the STM32CubeMX projects, so we accommodated it via the separate STM32WL BSP and updates to our STM32CubeMX integration.

The regular STM32 BSP was somewhat a lower priority due to mostly minor changes, some of them causing issues with the auto-imported sample projects. That said, we have resolved these issues by now and will be releasing the updated BSP early next week after it passes another round of tests.

We also confirm that the STM32F1 HAL in the new BSP contains the HAL_UARTEx_ReceiveToIdle_DMA() call.

[support]

Hi,

No worries, you can always use the variables like $(ProjectDir) throughout the VisualGDB Project Properties (including the custom steps) to avoid hardcoding absolute paths.

You can also use the link at the bottom of the VisualGDB Project Properties window to view all the variables relevant for the current project/configuration.

[support]

Hi,

We have rechecked the ESP32-C3 apptrace on the latest stable ESP-IDF 4.3.1 and it indeed triggered build errors inside ESP-IDF. The same ESP-IDF version worked with the regular ESP32 chip, so it looks like a bug in ESP-IDF specific to ESP32-C3.

Either way, the semihosting/apptrace is fully handled by the Espressif’s tools. VisualGDB simply turns it on by issuing the following command to OpenOCD via gdb (the actual path to the temporary file would be different):

monitor esp apptrace start "file://C:/temp/file.txt" 1

The Espressif’s port of OpenOCD then begins polling the apptrace memory, decoding its contents and writing it to the temporary file, where VisualGDB picks it up.

As the support for ESP32-C3 semihosting appears broken in the latest stable ESP-IDF release, our best advice would be to try other versions of ESP-IDF and see if the “monitor esp apptrace start” command works as expected. If not, please consider reporting it to Espressif – if the OpenOCD tool is not able to read the semihosting data correctly, VisualGDB won’t be able to display it.

If running the “apptrace” command in OpenOCD manually works, but the VisualGDB-level functionality (e.g. the semihosting window doesn’t), please let us know and we will investigate it further.

On our side, we have updated the OpenOCD package based on the latest sources from Espressif. You can install it via the VisualGDB Package Manager, although we cannot guarantee that it will work better.

[support]

Hi,

Our BlueNRG BSP is based on the ST BlueNRG-DK v1.1.0 that only includes one version of the linker script. If you would like to target a different device with a different memory layout, you would likely need to patch it, although this is something to double-check with ST.

[support]

Hi,

This is something to check on the Raspberry Pi forum. As far as VisualGDB is concerned, if valgrind itself works as expected, VisualGDB will work with it as well.

[support]

Hi,

Thanks, indeed there was a glitch with the Keil components triggered by the 64-bit runtime used by VS2022. We have fixed it in this build: VisualGDB-5.6.102.4516.msi

With the pack versions, indeed VisualGDB only recognizes the latest one. We will look further into it and provide an update here regarding the possible workarounds in the next couple of days.

Update: the multiple pack versions work just fine as long as you select the correct pack version in the device selector (first page of VisualGDB Project Properties). Then, VisualGDB will use the component list from the corresponding version of the pack.

• This reply was modified 3 years, 10 months ago by support. Reason: explained multiple pack versions

[support]

Hi,

It looks like valgrind may not be 100% compatible with your version of Raspberry Pi OS yet. You can try installing an older version of the OS/toolchain thta might work better (see this page) or submitting this issue to valgrid developers, so that they could consider fixing it.

[support]

Thanks for letting us know.  Segger J-Link supports a huge variety of devices very well, and has its own support dedicated to this type of low-level issues. Feel free to check with them whether your specific device is supported, and forward them any J-Link-level messages you get.

If you do not wish to use J-Link, you can try debugging:

1. A “LEDBlink” project for the same chip/board using VisualGDB.
2. A “LEDBlink” project for the same chip/board using STM32CubeIDE.

If the #1 doesn’t work, while #2 works, you should be able to fix VisualGDB-based debugging by copying the additional initialization commands from STM32CubeIDE.

If debugging a “LEDBlink” project works, while debugging your current project doesn’t, it could be an OpenOCD bug triggered by something about the project layout. Comparing the project to the LEDBlink project could help understand it.

You can also try building OpenOCD yourself and stepping through its logic, although it could be a tricky endeavor.

[Author]

Posts