Forum Replies Created
-
Posts
-
Thanks for confirming this. To narrow the problem further, please follow the steps below:
- Dump the build command line used by VisualGDB to a batch file as shown here. Make sure the build fails when running the batch file.
- Try modifying the batch file to use the arduino-builder.exe from the Arduino IDE directory instead of the VisualGDB’s one. Does it solve the problem?
- If not, please check the ESP32 Arduino core version used by the Arduino IDE and VisualGDB. If they are not the same, please try updating the core used by VisualGDB via Tools->VisualGDB->Manage VisualGDB Packages.
Hi,
Please try building the same project with the Arduino IDE. If the problem persists, the issue is with a specific library. If not, we can help you configure VisualGDB to match the behavior of the Arduino IDE.
No problem, we have updated VisualGDB to show an “empty project” template after the regular project samples in the embedded project wizard. Please try this build: VisualGDB-5.5.5.3622.msi
You can turn this feature on and off via the “Show Empty Project Template” setting (see this page for a list of all global settings).
Hi,
Please see this page for a detailed overview of supported targets.
Hi,
It’s hard to say why HAL_DeInit() would hang on a specific board, however it should be relatively easy to find out by terminating the OpenOCD instance and then attaching to the device as shown in this tutorial. It will show what exactly is happening on the device when it hangs.
No problem, please try this build: VisualGDB-5.5.5.3618.msi
It will display the currently used timestamp offset in the build log after the warning suggesting to use the Host-wide settings, e.g.:
Current timestamp offset for ubuntu19vm is -3600 (generation=0).
Please try the following steps to narrow down the problem:
- Build the project normally. Locate the current timestamp message and the “time stamp in the future” warning in the build log.
- Try adjusting the value in Host-wide settings (e.g. subtract 1000 from it).
- Build the project again and locate the updated messages.
Please share the messages from both builds and we should be able to track this down.
Hi,
Normally, when you create a new project with the Mbed Project Wizard, it will simply clone the official blinky sample and will use the mbed version that was referenced by it.
We have just rechecked it and as of 2020-05-16, the sample project references mbed 5.15.1 (you can double-check it by running “git describe” in the mbed-os subdirectory), so it works as expected.
Either way, you can change the referenced mbed version by right-clicking on Libraries->mbed-os in Solution Explorer and selecting “Change Library Version”.
Hi,
Strange, we haven’t changed the IntelliSense popup logic recently, so if it didn’t happen before, it’s likely caused by some other change on your machine (e.g. installing another extension, or some software using global window hooks). If you could narrow it down to something we could reproduce on our side, we would be happy to fix it, but otherwise it’s unfortunately impossible to tell what could be causing it.
Hi,
Please refer to the following post for details: https://blog.kitware.com/cmake-finding-qt5-the-right-way/
Hi,
If this is the same board you mentioned before (where you had to hold the reset button in order to connect using the ST-Link utility), please make sure you do the same with VisualGDB. Please also try using the “connect under reset” checkbox.
If nothing helps, please try checking if the board works when using the Eclipse-based STM32 IDE, that also uses OpenOCD.
Hi,
Sorry, this is not supported directly, as it’s a rather rare case. Our best advice would be to see how the regular includes are handled on the Makefile level and patch it, adding a new variable for -isystem entries.
You will also need to add those paths to IntelliSense include directories via VisualGDB Project Properties -> IntelliSense Directories.
Good to know it works. We used to recommend using the libusb-win32 driver with ST-Link previously, but the recent official ST-Link has superseded it, since it’s also based on libusb. It’s hard to say why it didn’t work with this specific ST-Link, but if the generic libusb works, it should be as good as the official ST-Link one.
Strange. It looks like your ST-Link might be not supported by the latest drivers from ST (or needing a firmware upgrade). Please try checking if the ST’s Eclipse-based STM32 IDE (that also uses OpenOCD) can debug the board. If not, the only other thing to try would be a different ST-Link (or a different debug probe altogether).
Thanks, it looks like the board has an older version of ST-Link that requires a manual driver installation.
Please try right-clicking on the “USB Mass Storage Device” and selecting “Update Driver -> Browse my computer -> Let me pick a driver -> Have Disk” and point the driver installation GUI to the ST-Link drivers folder near the ST-Link utility folder. After the correct driver is installed, the device should appear as “STM32 ST-Link”.
