[support]

Hi,

You may have purchased the Linux edition then. You can always upgrade it here: https://sysprogs.com/splm/mykey

Also if you don’t need to copy this file each time, you can simply upload it once with SmarTTY and keep on using the Linux edition.

[support]

Hi,

If you want to upload a text file to the target before debugging, you can add a new upload action to the custom pre-debug actions on the Debug Customization page of VisualGDB Project Properties (requires Custom edition or higher).

[support]

Hi,

First of all, please try the latest VisualGDB 5.2, as it contains fixes for many issues found in v5.1.

The behavior you described with deleting .user files looks like a bug. Please check if you can still reproduce it with v5.2. If yes, please let us know the steps to reproduce it and we will investigate it.

[support]

Hi,

Most likely either you modify some global header file used by all other headers, or VisualGDB believes it is modified and does a full rebuild.

Please try opening the Clang IntelliSense Diagnostics Console and check for messages like thi:

[+0:00:33.084] Found an outdated PSF 0 due to <file> during initial check. It will be re-built

It should explain why VisualGDB reparses the files.

The Error List behavior is by design – showing all errors from the entire project would require constantly rebuilding all the files in the background. Currently VisualGDB only does that when you use the ‘Go to definition’ or ‘Find all references’ commands.

[support]

Hi,

VisualGDB should not interfere with this command. If you believe it does, please try reproducing this with one VisualGDB-based and one non-VisualGDB based projects and post screenshots here. We should be able to investigate it based on that.

[support]

Hi,

Yes, it is a regular ARM GCC toolchain, so you can use it to build any project designed for that type of toolchain.

We don’t provide any support on using the toolchain outside VisualGDB though, as there are too many things that can go wrong.

[support]

Hi,

This error does not look like anything related to VisualGDB, so something else is most likely causing this.

Can you see any specific pattern that leads to the exit? What happens if you attach another instance of VS to your primary one, do you get an ‘unhandled exception’ message?

[support]

Hi,

Are you using the Custom edition or higher? If you were using a lower edition, the button would be disabled and would not work.

[support]

Hi,

Yes, we have previously used a different versioning scheme. Please try downloading the v3.0 BSP.

[support]

Hi,

No problem. BTW, if you cannot find a solution quickly, feel free to open a new topic and we will help you resolve the problems you encountered.

[support]

Hi,

The watch window contents looks normal. The [actual members] element is shown by VisualGDB in case you want to debug some low-level issues. If no other elements are shown, the list is most likely empty. If you can confirm that adding elements to the list still does not change the view, please attach an updated screenshot (code for adding elements + watch window contents) so that we can investigate this further.

[support]

Hi,

This is a known limitation of the ESP32 toolchain. To work around this, please wrap your function call with another one, e.g.:

void ThreadBodyWrapper()
{
    ThreadBody();
}

As long as the esp32 gdb can see the previous frame (ThreadBodyWrapper), it will be able to show the variable values in the current frame (ThreadBody).

[support]

Hi,

Thanks, we have fixed the search functionality. It should find forum posts now.

[support]

Hi,

Thanks for the screenshot. The setup looks correct, but the “JTAG scan chain interrogation failed” error suggests something is wrong with the wiring.

As mentioned in the previous posts, ESP8266 devices could be tough from the reliability point of view, so we would recommend starting with a board that we have successfully tested and then moving back to NodeMCU once you can confirm that the rest of the setup works. Otherwise it’s hard to diagnose what’s going on as ESP8266 does not report the internal errors in a very understandable way.

[support]

Hi,

You are using the correct toolchain. xtensa-lx-106 is the CPU architecture for ESP8266 (like ARM would be for STM32). The ESP8266 toolchain can be installed either in esp8266 folder or the xtensa-lx-106-elf folder depending on which installer you use.

Regarding the wiring, from our experience with ESP8266 and ESP32 the chip has great features, but it’s extremely flimsy. Same setup may work on one board and randomly break on another one; sometimes a board works for some time and then randomly dies; sometimes doing a full erase helps, sometimes it does not.

It also looks like the Olimex boards are more reliable than the original ESP-XX modules and NodeMCU. So our advice would be to get it working on the Olimex one to rule out problems with JTAG cable, JTAG debugger and software bugs and then try the same setup on NodeMCU. We understand this is a big inconvenience, but unfortunately the ESP8266/ESP32 devices are still very fresh and not very reliable.

[Author]

Posts