[support]

Thanks for pointing this out. This looks like a different issue from the other STM32L0 bug we were aware of (FLASH programming errors triggered by section alignment).

We have just released an updated OpenOCD package adding the dual-bank devices to the device selection menu (and also including latest updates from the OpenOCD repository). Please feel free to install it via Tools->VisualGDB->Manage VisualGDB Packages.

We will also review the STM32L0 device parameters during the next STM32 BSP update and will see if there is an easy way to detect the dual-bank devices automatically.

[support]

Hi,

It looks like you have an empty entry in the mapping list, that might be interfering with the mapping. Please try removing it and check if the problem persists.

[support]

Hi,

Most likely, some headers or definitions are still missing. Unfortunately, as you haven’t posted the build log, it’s hard to suggest anything more specific, so please try following the steps from our previous reply again in order to narrow this down.

[support]

Hi,

v5.3RC1 is quite old. Please try updating to VisualGDB 5.4R5. If the problem persists, please check the messages in View->Other Windows->VisualGDB Diagnostics Console produced while trying to instrument the file and let us know if you find anything suspicious. If not, please consider sending the ELF file to our support email and we will try to see why VisualGDB cannot handle it properly.

[support]

Based on your log, you are still using the old version of the ESP8266 core (2.4.1):

C:\Users\Sharon\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.4.1

Please follow the instructions from our previous reply and actually remove the core so that VisualGDB can install the latest one (version 2.5.0). We have checked it with the WeMOS D1 R1 target and it did build out-of-the-box.

[support]

Thanks for the update. This looks like some of the macros (e.g. portFORCE_INLINE) was not properly expanded. Most likely, this happens because the Keil project overrides some of the advanced settings that were not picked up by the VisualGDB’s project importer.

We have just published a detailed tutorial on extracting comparing the build command lines used by VisualGDB and Keil: https://visualgdb.com/tutorials/arm/import/diagnose/

Please feel free to follow it. As you have already pinpointed a specific source file, you will only need steps 20-25, although we advise reading through the entire tutorial in order to understand the role of the RSP files and various build settings.

If you are not sure, please share the build flags for the problematic file from both Keil and VisualGDB, and also confirm that you can reproduce the problem by building the file manually via command line (per step 22) and we will help you find the root cause.

[support]

It looks like some of the ESP-IDF headers or sample sources might not be fully compatible with C++. As this code comes directly from Espressif and is not maintained by us, unfortunately we cannot guarantee that it will be fully compatible with C++, however we can suggest a way to troubleshoot it.

Please try locating the first error in the build log (View->Output). It is likely responsible for many of the other errors and fixing it will reduce the amount of the remaining errors. Depending on the exact error, you might be able to fix it by wrapping some headers with extern “C” or using #define directives to rename some fields in case their names collide with C++ keywords.

Feel free to post the build log here and we might be able to share a few more hints on fixing this.

[support]

Thanks, we will consider hiding the unused option in one of the next VisualGDB releases (due to the way VisualGDB GUI is structured, it would require a non-trivial change and might have side effects).

The smart clean idea looks good, however we won’t be able to make it default as having the build directory the same as the source directory is a very rare setup and supporting it without changing one extra setting manually does not outweigh the risks of breaking backward compatibility for other users that expect the current behavior to be the default one.

[support]

Hi,

Thanks for reporting this. We have rechecked it and it looks like a recent optimization of the updating logic on our side broke down the check whether the updates are disabled.

Please try this build, it fully fixes the problem: VisualGDB-5.4.105.3139.msi

[support]

Hi,

Thanks for reporting this. We have tried reproducing the issue on our side (ESP-IDF 3.3, GNU Make-based project), however the COMPONENT_SRCDIRS variable got edited as expected, hence the problem must be caused by some other setting.

Please confirm that the problem can be reproduced on a project created from scratch and let us know the exact settings you specify in the wizard so that we could look into this.

Please also note that the tutorial shows the older GNU Make-based project. The newer CMake-based projects specify each source file in the CMakeLists.txt explicitly and hence the COMPONENT_SRCDIRS variable is not used.

[support]

Hi,

No problem, please find the detailed explanation of the related settings below:

1. Working directory is the directory where VisualGDB will physically launch cmake.exe. It defaults to the remote source directory and does not have effect when using cmake in the server mode (i.e. with the Advanced CMake Project Subsystem).
2. Binary directory is the relative path to the directory where CMake will create the binaries.
3. CMakeLists.txt subdirectory is the relative path to the directory where CMake will search for the top-level CMakeLists.txt.
4. This setting controls how VisualGDB will clean the projects. The default setting is to delete the entire binary directory (if you are using direct SSH access and the build directory is the same as the source directory, the latest VisualGDB 5.4R5 will skip the deletion and will suggest changing this setting). For the setup you described, we would advise using the “build the ‘clean’ target” option.

The CMake command line equivalent to the VisualGDB settings mentioned above would be:

cd <working directory> && cmake <CMakeLists.txt subdirectory> -B<binary directory>

We have also double-checked the latest v5.4R5 build and it looks like the “clean mode” setting may not always be shown correctly. We have fixed it in this build: VisualGDB-5.4.105.3138.msi

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Based on our understanding, Espressif is not actively developing the NonOS SDK and is instead focusing on the RTOS SDK 3.x that is based on the ESP-IDF framework.

We have recently added full support for the latest RTOS SDK to VisualGDB and would like to encourage our users to switch to it, as it seems to be more regularly maintained than the old NonOS SDK.

Unless Espressif releases another major version of the NonOS SDK that will work sufficiently reliably, we will not be supporting it officially, sorry. That said, please feel free to use our open-source BSP generator to build a BSP based on the patched SDK you have, so you won’t need to mix different versions manually.

[support]

Unfortunately as you haven’t shared the VisualGDB build number that is usually shown above the stack trace, it’s impossible for us to decode it and locate the exact cause for it.

Generally, as the trace mentions custom debug steps, please try removing them from the .vgdbsettings file and see if the problem persists. If not, please try narrowing it down to a specific debug step that will likely contain an excessively long path. You can also try using View->Other Windows->VisualGDB Diagnostics Console to get a detailed log of the actions performed by VisualGDB.

The second issue looks like you are using a $(ProjectDir) variable in a context where it is not supported (e.g. Quick Debug). Please try searching your .quickdbg file for $(ProjectDir) and edit it to remove the unsupported variable reference. If you are not sure about the exact reference, please try creating a new quick debug preset from scratch, verify that it works and then compare the working and non-working preset.

[support]

Thanks for suggesting this. The boards do look promising and we will consider supporting them out-of-the-box once they get more traction (i.e. major distributors like DigiKey begin carrying them and/or we see more media coverage for them indicating the growing amount of users).

Until the boards are fully supported, you should be able to configure VisualGDB to target them manually by using our RISC-V toolchain and then specifying the build flags manually as shown in this tutorial. We will be happy to help you locate the relevant VisualGDB settings to make this work, however please be advised that as the SDK and the board is relatively new, it may not work as reliably as ARM-based devices.

Edit: VisualGDB now supports K210 boards directly. You can find more details in this tutorial: https://visualgdb.com/tutorials/risc-v/kendryte/k210/

[support]

Thanks for playing fair. Do do appreciate it as it takes considerable effort on our side to provide a maintained and supported product.

The problem you are experiencing is most likely caused by the Keil trying to compile a C++ file as an assembly file, or vice versa. In order to diagnose it, please follow the steps below:

1. Try narrowing down the problem to a specific source file. Check the build output (View->Output) to see what files are built just before the problem triggers. Then try building that specific file by opening it in Visual Studio and pressing Ctrl-F7 (or right-clicking in Solution Explorer and selecting “build”).
2. Once you can reproduce the problem with a specific file, please check its type and input language via File Properties. If you are not sure, please let us know the file extension, the values of Configuration Properties -> Item Type and Configuration Properties -> C/C++ -> Advanced -> Compile As, and also the exact build output.

We have tried reproducing the issue with VS2019, however could not get the behavior you described. Based on the screenshot, it looks like VisualGDB is trying to save the solution before creating the project and Visual Studio fails to complete the save. Please try updating VS2019 to the latest version and also check if the problem can be reproduced when creating a new GCC-based project from scratch. If not, please try comparing the working and non-working setups to narrow down a specific setting that triggers the issue, so that we could add a workaround on our side.

[Author]

Posts