Forum Replies Created
-
Posts
-
Hi,
The parametrized tests unfortunately won’t solve the problem, however we are planning to extend our advanced semihosting framework to support reading test data same way it currently outputs test results. We should be able to give a time estimate on this in the next 1-2 weeks.
Hi,
VisualGDB would normally use the clang-format engine to format the source code. Clang-format uses its own configuration files that are not 100% in sync with the regular Visual Studio formatting options (although VisualGDB does synchronize the main options).
That said, VisualGDB comes with a graphical editor for the clang-format configuration files, so you can easily tweak the code formatting behavior by clicking the button shown below:
Hi,
This might indicate that the KGDBoE module (debugging over Ethernet) is not fully compatible with your target, or it could indicate a symbol problem.
If you could attach a gdb log from the debug session, we should be able to tell what is going on. Please also consider debugging the target via JTAG, as it is generally less fragile.
Sorry, if the esptool.py doesn’t work, the device or board might be malfunctioning. Please consider posting more details on the Espressif forums and asking whether there is a workaround.
If you could get the underlying tools to work with the device, VisualGDB should be able to work with it as well.
It looks like due to the differences between Solaris and Linux, the logic responsible for creating a remote terminal is not working. Unfortunately, as Solaris is much less popular than Linux, VisualGDB does not support it.
Hi,
Sorry, the Additional Memories window only works for GCC-based projects, however we can help you configure your Keil-based project to achieve similar results.
Please make sure that the CCM memory in your scatter file (e.g. RW_IRAM2 shown below) is inside the main load region (LR_IROM in the example below). It will ensure that its contents get programmed into the FLASH memory and the Keil startup code copies them into the actual CCMRAM before calling main().
Below is an example of a Keil scatter file defining both RAM and CCMRAM memories:
LR_IROM1 0x08000000 0x00100000 { ; load region size_region ER_IROM1 0x08000000 0x00100000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) .ANY (+XO) } RW_IRAM1 0x20000000 0x00020000 { ; RW data .ANY (+RW +ZI) } RW_IRAM2 0x10000000 0x00010000 { ; CCM data .ANY (CCM_DATA) } }You can place a specific variable into the CCM memory by declaring it with the section attribute:
int __attribute__((section("CCM_DATA"))) g_Test = 5;If this still doesn’t work, please let us know and we will help.
Sorry, as the steps for this are the same for all C/C++ IDEs, hence there is no specific VisualGDB documentation for this point.
Indeed, adding the .c file providing the function definition to Solution Explorer should solve the problem. You can read more about C/C++ declarations vs. definitions in the following thread: https://stackoverflow.com/questions/1410563/what-is-the-difference-between-a-definition-and-a-declaration.
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.
