[support]

Hi,

No problem, we can share a few techniques to diagnose this, however it looks like your support period has expired. Please renew your license here (in case you have purchased another key already, please let us know the email associated with it) and we will provide instructions for narrowing this down.

[support]

Yes, please try using the Tools->VisualGDB->Manage VisualGDB Packages->Online->Show previous versions checkbox.

[support]

Hi,

VisualGDB would require this framework if you are running the embedded profiler, or have real-time watch/other dynamic analysis options enabled via VisualGDB Project Properties -> Dynamic Analysis. Please double-check that the project doesn’t have any dynamic analysis options turned on and that you are starting debugging via the regular Debug->Start New Instance command.

[support]

Thanks for clarifying this. Removing the Arduino IDE from the system was not necessary, as the problem is likely caused by the ESP8266 Arduino core that we suggested to delete (if you are not familiar with this term, please see this explanation on StackExchange).

The directory of the core is actually mentioned in the error message you posted, so it should be very straight-forward to locate it.

That said, to reduce the chance of interference from other components you might have installed earlier, please try deleting (or actually first renaming) the entire Arduino packages folder:

C:\Users\Sharon\AppData\Local\Arduino15

This will ensure that there are no leftovers and you should be able to create the project per our tutorial.

[support]

Hi,

We have rechecked the LPC1769 memory map and it indeed looks like a bug. The memory size definitions for the legacy NXP devices were taken from the NXP’s product lists and most likely there was an error there at the time when our BSP was generated. As a workaround, please consider creating a copy of the LPC1769_flash.lds file in the project directory (via VisualGDB Project Properties) and patching it in place.

Generally, for NXP devices we would advise using newer device families that are using the MCUXpresso framework (e.g. see this tutorial) so that VisualGDB will automatically import the correct linker scripts, device definitions and examples. The older LPCOpen-based SDKs have considerably lower quality and are no longer maintained, so VisualGDB could have picked up some incorrect definitions from them.

The checksum is specific to certain NXP device families and is indeed not automatically computed by VisualGDB. If you are using VisualGDB with Segger J-Link, it might provide a special command for updating the checksum on-the-fly (please double-check if with Segger support if you are not sure). For stand-alone programming scenarios, NXP recommends doing it manually, sorry. We can help you understand the VisualGDB-driven build process and the underlying tools that could be used to inject the checksum, however unfortunately we will not be adding out-of-the-box support for it as it only affects a small subset of no-longer-maintained devices.

The programming error can be normally diagnosed by clicking the “view details” button or link (depending on the way the message is shown) or via View->Other Windows->VisualGDB Diagnostics Console. It is likely generated by the underlying tool (e.g. Segger J-Link) and examining the tool log should point to the root cause.

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

[Author]

Posts