Forum Replies Created
-
Posts
-
Hi,
It could be caused by updating the ESP32 IDF then.
You can try the older version by downloading the older toolchain from here: http://gnutoolchains.com/esp32/. There is no need to reinstall VisualGDB.
Hi,
We have encountered similar behavior with ESP8266 – some firmware (specifically AT commands) triggered some undocumented hardware mode that prevented the breakpoints from being handled properly. Unfortunately this is something beyond our control so the only advice we could give here is to experiment with moving the functions to RAM and setting explicit breakpoints (asm(“break 1,1”)) in various functions to understand what triggers this mode.
Hi,
Looks like you might be compiling the code with the -O0 optimization level that triggers a bug in the ESP32-IDF.
Please try switching it to -Og via Visual Studio Project Properties -> C/C++ -> Optimization.
Hi,
The ESP32 OpenOCD sometimes shows this message if one of the cores is not stopped properly. Please try running the “mon targets” command to see if both cores are stopped. You can then forcibly stop them by running “mon halt”.
Hi,
Please ensure that you are using the latest VisualGDB 5.2 and the new MSBuild subsystem.
Alternatively you can try manually setting the optimization level to -Og instead of -O0 and specifying the -std=gnu++11 language standard.
Hi,
Sorry about that. First of all please note that the ESP32 chip is very new and often behaves unpredictably, so this is to be expected.
Our best advice here would be to try something very simple and see if this works. Does building and programming a basic “LEDBlink” project with VisualGDB work? If no, does flashing the same ELF file with esptool.py work?
If you can confirm that the file built with VisualGDB does not work even when flashed with esptool, please ensure that you are using an unmodified toolchain from us and that the optimization is set to -Og, not -O0.
Hi,
We are sorry about the inconvenience. You can easily use the VisualGDB test functionality to test complex libraries as well; simply create a test application that will reference your library and you can write tests for the library functions.
Regarding the “ReadFile failed”, this refers to a pipe between the component that controls debugging and the one responsible for selecting tests and forwarding output from them. We would be happy to help you pinpoint this if we knew at what point the problem happens and what other information is shown along with the error. So if you ever feel like trying this again, please let us know and we will help you troubleshoot this.
Hi,
If VisualGDB does not show any extra error output, most likely the gcc executable simply fails to start. This could be if the toolchain is corrupt or your antivirus is blocking it. Please try running the “arm-none-eabi.gcc.exe -v” from the toolchain manually. Does it successfully output the version? If yes, what happens if you ignore the toolchain testing error and proceed with creating and building the project?
Hi,
This error is a generic one that indicates a hardware exception (e.g. trying to read an invalid address) and usually happens for simple projects when the project configuration does not match the board (e.g. the configured memory size is larger than the actual memory size).
To track it down, please check the call stack window to see where in the code it happens. If this does not work, please open the Embedded Debug Settings page of VisualGDB Project Properties, select “step into new instance-> entry point” and start debugging with F10 instead of F5. Then you should be able to step through the startup code and understand what causes the error.
If you are not sure, feel free to post the details about the error here and we will help you resolve it.
Hi,
Most likely the HSE_VALUE macro defined in your project configuration does not match the speed of the clock oscillator on your board. Please double-check your project configuration and the board schematics.
Hi,
Unfortunately it’s hard to say what is causing this based on the message alone. Looks like one of the paths specified in the settings is wrong. Can you pinpoint a specific step that triggered the problem?
Hi,
No problem. BTW, you can conveniently edit the signal settings by pressing the ‘signals’ button (with the lightning icon) in the GDB Session window.
Hi,
No problem. The ‘generate graph of include files’ command actually comes from the VS IntelliSense, so that header file is not recognized by VisualGDB. This could happen if your solution had both VisualGDB and non-VisualGDB projects. Is this the case? If not, how many projects does your solution have?
Hi,
It is hard to give any detailed hints without knowing the exact errors you encounter. The general advice would be to understand what causes the error message and how to modify the configuration (or patch the source) to eliminate it. E.g. some of the timeval problems happen because of this definition (that can be located by viewing the ‘output window’ and locating the ‘previous definition’ line):
#ifndef LWIP_TIMEVAL_PRIVATE #define LWIP_TIMEVAL_PRIVATE 1 #endif #if LWIP_TIMEVAL_PRIVATE struct timeval { long tv_sec; /* seconds */ long tv_usec; /* and microseconds */ }; #endif /* LWIP_TIMEVAL_PRIVATE */Defining LWIP_TIMEVAL_PRIVATE=0 effectively disables the conflicting definition. If you are getting a different error and still cannot pinpoint it, please let us know the details and we will point you to the right direction.
Hi,
If you are getting build errors, most likely the toolchain got corrupt, so removing and reinstalling it should help.
FLASH reading errors are tougher and could indicate a dead chip. During our tests with ESP8266 three different boards routinely died under different circumstances, so we would suggest simply getting another one.
