[support]

Hi,

Sorry, not fully sure we understood you correctly. Do you mean that some of the VisualGDB GUI does not display Chinese characters correctly or that VisualGDB is not translated to Chinese?

[support]

No worries. Let us know if you encounter further problems and we will be happy to help.

[support]

Hi,

Unoptimized debug builds are expected to result in much slower execution time; this is by design. This is needed because the optimizer would try to place as many variables as possible into registers and will reuse the same register for a different variable once the old one is no longer needed, making it only possible to evaluate its value while it is still needed by other code. Other optimizations would make stepping less intuitive by combining reusable code fragments like the code for the ‘return’ statements. Our best advice would be to play around with the optimization setting, changing it between -O0, -Og-, -O1, -O2 and -O3. Increasing optimization will increase the speed, but make the debugging experience harder.

Regarding unstable code, most likely your code either contains a bug that corrupts memory (but is not reproduced without optimization) or relies on some assumption that does not hold with full optimization. E.g. the following code may hang in the release build because the optimizer will try to move reading of ‘done’ outside of the loop:

int done;

void InterruptHandler()
{
    done = 1;
}

int main()
{
    //...
    while (!done)
    {
    }
    
    printf("done\n");    
}

Declaring the ‘done’ variable with the ‘volatile’ keyword will solve the problem.

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

[Author]

Posts