[support]

Hi,

Please contact our support with the details of your key and we will help you resolve this.

[support]

ESP-IDF is for ESP32; if you are using ESP8266, it’s either RTOS SDK, or non-OS SDK. Both can be downloaded from here: https://espressif.com/en/support/download/sdks-demos

You can also simply post your test program here and we could quickly check if the problem is reproduced with the original command-line build tools.

[support]

Hi,

If you had to add a line manually, there could be a version mismatch between your system file and the HAL library and that could cause further cryptic errors. We would strongly encourage double-checking this and getting the correct version rather than just adding a missing line, as it would help avoid really tough-to-pinpoint problems.

[support]

Hi,

If both building and IntelliSense is slow, perhaps something is using the CPU? Could you please check the CPU usage via Task Manager? This could also happen if the RAM utilization was too high or too much background disk activity was slowing down the access to the source files.

[support]

Hi,

Just to double-check, you are using the optimized ‘Release’ build, right?

[support]

Hi,

We don’t support this board yet due to relatively low popularity. We will keep on monitoring its popularity and reconsider this once the board becomes more popular.

[support]

Hi,

Please double-check that your project includes a system_stm32xxxx.c file. It should either come from the code generated by STM32CubeMX or from the VisualGDB BSP directory (enabled by referencing ‘default system file’ framework on the Embedded Frameworks page of VisualGDB Project Properties).

[support]

Hi,

That should work. Another option would be to add “-x c++” to the CFLAGS to explicitly tell GCC to treat the file as a .cpp file.

[support]

Hi,

Thanks, looks like a bug on our side. We have updated our mbed package; please update it on your side via Tools->VisualGDB Package Manager.

[support]

Hi,

It looks like the replies sent via our support system don’t reach your email address, so please add ticket@sysprogs.com to your spam filter whiltelist.

Below is a copy of our last reply regarding ESP32-WROOM.

Unfortunately the general problem with ESP32 devices is that they are less reliable than ARM devices and don’t provide adequate diagnostic means, so we have to limit our support to a few popular devices that we could test on our side and a few very basic scenarios.

To make it easier to diagnose the problems that we cannot handle on our side, we made all our ESP8266/ESP32 support open-source: https://github.com/sysprogs/BSPTools/tree/master/DebugPackages/ESP8266DebugPackage

When VisualGDB programs an ESP32 firmware, it loads 3 regions of FLASH:

• The bootloader (at 0x1000)
• The partition table (at 0x8000)
• The image itself (typically at 0x10000)

You can find the related logic in ESP32StartupSequence.cs, line 180. If the program fails to start on the ESP32-WROOM module, it could be caused by one of the 3 reasons:

• The memory is not programmed correctly
• The bootloader configuration or the partition table is wrong
• The compiled program is doing something unsupported (e.g. it was compiled with no optimization and hence triggers a bug in the ESP-IDF)

In order to diagnose this, please try using the esptool.py to read the FLASH memory contents back to the disk and then compare it with the bootloader file, partition table file and the <program>-esp32.bin file. This should help understand if the programming itself succeeds.

If the programming succeeds, please try programming the version that works (e.g. the one built via ESP-IDF build scripts) and compare the bootloader and the partition table contents. If they are different, please try overriding them.

If both the bootloader and the partition table are the same, please send us the downloaded first 1024 bytes of FLASH memory at offset 0x10000 for both the version that works and then one that does not so we could quickly compare the ESP32 image headers and check if there is any obvious reason for this.

[support]

Hi,

Sorry, we tried reproducing it and could not get the problem to appear. Could you try reproducing it on a smaller project that you could archive and send to us?

[support]

Hi,

Sorry, could not reproduce this. The problem could easily be caused by a corrupt VS installation on one specific machine. Please try enabling the debug logging for the installer:

msiexec /l* visualgdb.log /i VisualGDB.msi

Then reproduce the problem and check for Visual Studio-related entries in the log file. This should explain what exactly is done by the installer.

[support]

Hi,

VisualGDB 5.2 should already be doing double-buffering for the parse data. I.e. while a file is being parsed, it will use the previous parse data to highlight local references and handle other similar functionality. The Ctrl-Space code completion should also work completely parallel to this. If you observe the opposite, please share the repro steps and the diagnostic log so that we could investigate this.

Ophidian14: we will try to include this feature in one of the early preview builds of v5.3. We will post an update here once it becomes available.

[support]

Hi,

For a 3rd-party toolchain you would need to manually specify “–specs=nosys.specs” via LDFLAGS to include the necessary libraries. The toolchains shipped by us have this flag conveniently mapped to a checkbox in the settings, but 3rd-party toolchains would require specifying it manually.

[support]

Hi,

VisualGDB does not have a free community edition. Please note that we only offer support to the users of our paid products like VisualGDB. To get general Qt-related support, please try asking on the Qt forums.

[Author]

Posts