[support]

Hi,

Thanks for rechecking everything. Most likely VisualGDB creates a background thread that doesn’t properly exit after the normal MSBuild logic terminates. Please try attaching to the MSBuild process from Visual Studio in the Managed mode (ensure you select the correct one as VS itself may run several of them) and check the call stacks of all threads. Please post them here along with the exact VisualGDB build number and we should be able to tell what is going on and provide a fix/workaround.

[support]

Hi,

Thanks for uploading the video and sharing your concerns. We will try to explain what is going on.

Unlike many conventional ARM-based devices that are supported through our optimized MSBuild backend and a collection of tested BSP packages, the Advanced ESP32 projects are built directly by the ESP-IDF framework (official ESP32 SDK by Espressif). We decided to handle the ESP32 platform this way in order to accommodate the rapid release cycle of the ESP-IDF that often releases updates introducing new features, large structural changes and breaking backward compatibility.

I.e. instead of an optimized VisualGDB package based on a specific version of ESP-IDF (that would get obsoleted very quickly), VisualGDB can run on top of any recent ESP-IDF release of your choice and produce exactly the same results as meant by Espressif. It will inherit the original ESP-IDF build system and the configuration settings.

PlatformIO likely uses a different approach – includes a subset of ESP-IDF with its own build subsystem that is faster and requires less configuration settings, but is not equivalent to the latest ESP-IDF framework. Hence most of the differences you mentioned are rather the differences between ESP-IDF (full-scale ESP32 SDK) and PlatformIO (a lightweight SDK for smaller projects) and are not actually related to VisualGDB itself.

Although VisualGDB doesn’t support PlatformIO out-of-the-box yet, it does support the ESP32 Arduino core (see the new Arduino project wizard) that provides similar lightweight experience at a cost of offering fewer features. Espressif itself is also addressing the build speed issue by switching their IDF to CMake+Ninja. Once this switch is complete, the ESP-IDF projects will build much faster.

Regarding the other issues mentioned in the video, it looks like you did not specify valid debug settings when creating the project. If you don’t have a JTAG probe, simply select a COM port. VisualGDB will warn that no actual debugging will be possible, but will still allow programming the device via the COM port. You can change it for an existing project via VisualGDB Project Properties -> Debug Settings. Alternatively, please try right-clicking on the project node in Solution Explorer and select “Program FLASH Memory”. This will run the same FLASH programming routine as used by PlatformIO.

The COM port syntax (/dev/ttyS<port number – 1>) is to be expected – this is a valid Cygwin COM port syntax, so please do not change it. Please also note that changing the programming speed from 115200 might break programming, depending on the capabilities of the specific COM2USB chip used on your board.

Hope this helps. Let us know if you have any further questions.

[support]

Hi,

Yes, please click the lightning icon in the bottom left corner of the suggestion popup to enable this mode.

[support]

Hi,

Sorry, this doesn’t look like any known issue, so we can only suggest the generic steps to narrow it down. Please try checking if the problem can be reproduced on a basic LEDBlink project. If not, please try comparing the project structure – the created threads, called functions, configuration settings, etc. until you find the setting that triggers the issue.

You can also try creating a separate thread with just a loop of sleep() calls and see if setting breakpoints there works.

Let us know your findings and we will try to suggest a workaround.

[support]

Hi,

Unfortunately we are not aware of anything that could be causing this, but we can still help you pinpoint it. First of all, please check whether the problem can be reproduced:

• When building from Visual Studio
• When building the default target only (no /t switch)
• When building a clean “Hello, World” project using the same toolchain
• When building a remote “Hello, World” project
• When building a regular VC++ Win32 project

Please let us know your findings and we can suggest further steps to narrow it down.

[support]

Hi,

No worries, and good to know it works.

[support]

Hi,

It looks like the executable is either corrupt, or is blocked by your antivirus. Please try re-downloading it from http://gnutoolchains.com/esp32/ and running it again and check your antivirus logs if it doesn’t help.

[support]

Hi,

This looks like a corrupt ESP32 toolchain. Please try reinstalling it.

[support]

Hi,

Sorry, that’s unfortunately by design. Each embedded framework managed by VisualGDB includes all of the source files from the corresponding directory. The ST samples (selected as “STM32CubeMX Samples” on the sample page) often include a subset of the sources from a particular framework that is used in this particular sample. This makes them incompatible with the framework mechanism out-of-the-box.

We generally recommend using the vendor samples (e.g. STM32CubeMX samples) to quickly explore various drivers and libraries that come with the SDK and then creating production projects based on the regular samples that are compatible with the framework system. Alternatively you can simply reference the necessary frameworks and manually remove the conflicting files from the regular source file list.

We don’t do the adjustment automatically as a part of our BSP generation, as we want the vendor samples to be 100% equivalent to the original ST projects they are based on in order to minimize the chance of introducing errors. Unfortunately this means inheriting the monolithic non-modular structure of the original projects.

Hope this explains. We can also share more detail on the inner workings if the samples, BSPs and frameworks, so you would tweak them to your needs.

With the barebone project, there could be several variants of it for different cases (e.g. with different linker scripts/startup files/system files), so instead of providing a separate barebone sample, we recommend using the VisualGDB project template mechanism. Simply start with the LEDBlink project, remove all code and the unnecessary frameworks and then export it as a VisualGDB template via the File menu. Next time pick “create a project from template” and VisualGDB will automatically copy the project structure. You can also tweak the template files after creating them, as they are simply ZIP files with an XML index + the referenced source files.

 

[support]

Hi,

There was a temporary issue with the R12 file on our server, sorry about that. Please try downloading it again.

[support]

Hi,

Thanks for reporting this and sorry for the inconvenience. We have double-checked the installer file and resolved the problem. You should be able to install it as usual now.

[support]

Hi,

No problem. With the reset sequence, you might be able to reset it by first triggering a bootloader reset (same as when programming FLASH), and then immediately issuing an “exit bootloader” command or programming an empty image without erasing. Checking the bootloader sources might help find the exact commands or suggest a better idea.

With hardware debugging, if the board has the JTAG or SWD pins exposed, the Olimex debugger should work.

We have also added an option to control the vertical scrollbar in the console to this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2430.msi (under Tools->Options->VisualGDB->General->GUI). The default colors unfortunately would be trickier, so we will try to add an option for them next time we redesign the terminal settings logic, but we won’t be able to add this option in v5.4.

[support]

Hi,

No problem and thanks for reporting this. Looks like one of the components in our toolchain was using files from an earlier build. We have fixed it and published an updated toolchain. Please update to the R12 toolchain via VisualGDB Package Manager.

[support]

Hi,

Most likely your cross-toolchain is out-of-sync with the target SD card image. Please ensure you are using a compatible toolchain/SD image combo (see this page for supported versions).

[support]

Hi,

No problem and sorry we couldn’t offer further help with this. That said, if you discover that mbed itself works on a different target, but doesn’t work under VisualGDB, feel free to share the details here and we will help you get it to work with VisualGDB.

[Author]

Posts