[support]

Hi,

Thanks, looks like one of the recent MSBuild builds changed the internal thread structure, so VisualGDB was not properly detecting the end-of-build event.

Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2436.msi

[support]

Hi,

No problem. If the valgrind’s vgdb tool works without any problems when launched manually, it could be caused by different timing.

Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2436.msi

We have added a new option: Tools->Options->VisualGDB->General->Profiling->Delay before starting valgrind’s vgdb tool

Please try setting it to 5000 and check if this solves the problem. If yes, try reducing it to 500-1000. If not, please increase it to 60000 and open VisualGDB Diagnostics Console. VisualGDB will show the exact command line it is about to launch before it starts waiting. Please try running the command line manually from an SSH terminal and check if it also results in an error. This should help understand whether vgdb or valgrind itself (launched before) is behaving differently in VisualGDB vs. manual SSH console.

[support]

Hi,

Sorry, this is not scheduled for any specific release yet. The best workaround currently would be to try creating a basic importer based on the other open-source importers we provide: https://github.com/sysprogs/BSPTools/tree/master/ProjectImporters

Once we will add an official importer for TrueStudio, we will publish its sources in the same repository and will update this thread.

[support]

Hi,

Thanks for the second comparison. Unfortunately a few things are still unclear. Do you get 4 or 8 minutes when running the Cygwin command line from our toolchain manually with the same -j8 flag as with your toolchain? What time would you get by running “mintty.exe -” and then manually navigating to the project folder and building it with “make -j8”?

Also are both toolchains using the same version of ESP-IDF? We had noticed a substantial increase of build time in v3.0 compared to v2.x.

[support]

Hi,

Strange, normally VisualGDB should run the same command. Could you please try checking the build output for the exact command line used by VisualGDB (in the very beginning of the output)? E.g.:

VisualGDB: Run "e:\SysGCC\esp32\bin\bash.exe --login -c "export IDF_PATH=/esp-idf/v3.1 && export BATCH_BUILD=1 && export -n PYTHONHOME && export LANG=en_US && cd /cygdrive/e/projects/temp/EmbeddedProject8 && make -j16 BUILD_DIR_BASE='/cygdrive/e/projects/temp/EmbeddedProject8/Debug' SDKCONFIG='/cygdrive/e/projects/temp/EmbeddedProject8/sdkconfig-debug' V=0"" in directory "" on local computer

Do you observe anything similar? Is the thread count set properly to the amount of CPU cores? Does it run faster when you run exactly the same command (including the bash.exe part) manually?

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

[Author]

Posts