[support]

Hi,

Sorry about that, this indeed looks like the earlier version of the toolchain got cached incorrectly. Adding the missing <Checkouts> tag will indeed fully solve the problem. We have also updated the cache on our side, so that other users will get the correct toolchain with the valid XML file.

[support]

Hi,

Thanks for reporting this. We have updated Live Watch to handle bit fields correctly. Please try this build: VisualGDB-5.6.102.4519.msi

We have also added an option to only display the variables defined in the current source file, so you can find the relevant variables faster.

[support]

Hi,

This is to be expected. Porting a project to a different compiler will likely require adjusting it to account for differences between the compilers. As soon as you adjust the source code fixing the build errors, VisualGDB will let you build and debug the project as usual.

[support]

Hi,

If the header files are missing in Solution Explorer, they were likely not directly referenced by the original IAR project either (it’s not necessary for build). You can add them to Solution Explorer via the “Add->Existing File” menu command similar to the regular Visual Studio projects.

[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.

[Author]

Posts