Forum Replies Created
-
Posts
-
Hi,
The -stack-list-frames –thread 1 error sometimes happens when the ESP32 gdb port tries to interpret the stack of the old program (that is still programmed in the board) using the symbols from the new program (that was just built). This happens relatively rarely, and appears to be a bug in the ESP32 tools.
If this happens, please try programming the FLASH memory over the serial port (right-click on the project in Solution Explorer and select ‘Program FLASH Memory’). This should overwrite the old program in the ESP32 FLASH memory and will make sure you can debug the new one.
Sorry, this looks like an STM32-specific problem and not something specific to VisualGDB. Please consider asking on the STM32 forums instead.
Update: Please also consider looking through this tutorial. Although it involves a Linux-based project, it explains the difference between the C/C++ function declarations and definitions and might be helpful in troubleshooting the issue.
Sorry, the exact timelines of OpenOCD supporting various devices are outside of our control. Either way, if you prefer out-of-the-box integration with the latest devices, using Segger J-Link should be the best option.
Hi,
It looks like your device is not yet supported by OpenOCD. Please consider waiting 1-2 months until OpenOCD supports it, using Segger J-Link instead (that adds device support faster), or patching OpenOCD on your side (our OpenOCD fork can be conveniently built using VisualGDB and CMake as shown here: https://visualgdb.com/tutorials/arm/openocd/build/).
Hi,
Unfortunately, the ESP32 tools are considerably more fragile than ARM-based tools, hence it is possible to break them by installing incompatible versions of different components or by accidentally patching some open-source components.
Our best advice to resolve it would be:
- Delete the ESP32 toolchain and the ESP32 OpenOCD package via Tools->VisualGDB->Manage VisualGDB Packages.
- Try creating a new ‘ledblink’ project from scratch. Make sure you use the ESP-IDF version that is shipped with the toolchain.
- Ensure the ledblink project works and can be debugged.
- Once you get the ledblink project to work, try opening the previously broken project and check if it behaves differently. If it still doesn’t work, please try comparing the configuration files for the 2 projects (or simply move the code from the broken project to the working ledblink project).
Hi,
We would be happy to help you, however it looks like your support period has expired. Please renew it via this page and we will help you resolve this issue.
Hi,
No problem, we have released an updated BSP based on msp432_driverlib_3_21_00_05. You can update it via Tools->VisualGDB->Manage VisualGDB Packages.
No worries and good to know it works. The advanced target-specific settings indeed only appear once the project has been created (and VisualGDB got a chance to query them from the Arduino tools).
If you encounter further issues, feel free to start another thread and we will be happy to help.
Sorry, it looks like the file did not get uploaded properly. Would you mind compressing it and trying again?
Also please double-check that you have selected the same upload method via VisualGDB Project Properties -> Project Settings (please attach a screenshot if you are not sure).
Hi,
It looks like some issue with the drivers or Arduino tools. Please try checking if you can program the board using Arduino IDE. If yes, we can help you achieve the same results with VisualGDB. If not, please try posting on Arduino forums.
No problem, please find the explanation below:
- When NOT using fixed heap/stack, VisualGDB projects will use the default gcc/newlib logic for placing stack/heap:
- The stack begins just before the _estack symbol (typically, end of RAM) and grows downward (i.e. address decreases with each push).
- The heap begins after the end symbol (per linker script) and grows upward.
- There are no hard stack/heap size limits. Each time the heap is extended, the heap logic checks whether the new end-of-heap would be beyond the current stack pointer. There is no check for stack pointer overrunning into the heap later.
- When using fixed stack/heap, VisualGDB does the following:
- It adds the ReservedForStack and FixedSizeHeap symbols into the built executable (see the StackAndHeap.c file).
- The heap is located inside the FixedSizeHeap variable and will never grow beyond it.
- The stack is still located _estack (growing downwards). It gets to use the space allocated for ReservedForStack and all the space after it (before the end of RAM). The ReservedForStack variable ensures that you get a link-time error if there is not enough space to place the requested stack size.
You can see this by reviewing the .map file produced by VisualGDB (use the VisualGDB Project Properties or VS Project Properties -> Linker to enable map files) or by using the Embedded Memory Explorer.
Currently, VisualGDB does not offer any special tools for analyzing hardfaults, sorry.
Sorry, this is way too project-specific and is not covered by our regular product support. We can help you understand specific settings of VisualGDB, but we are not able to troubleshoot project-specific issues without charging consulting fees.
Sorry, this looks like a project-specific issue (e.g. stack/heap overflow somewhere in the code), so we can provide limited help on this topic.
Our best advice would be to use the Embedded Memory Explorer to compare the memory layout of the 2 builds (https://visualgdb.com/tutorials/arm/comparebuilds/) and try making something in between to narrow down the problem (e.g. manually fill the same area of the FLASH memory with 0xFFs).
