Forum Replies Created
-
Posts
-
Hi,
This looks like an internal error in GNU Make itself. The easiest workaround would be to switch to a different project type that does not use Make (e.g. MSBuild or CMake + Ninja).
Hi,
The MSP430 support in VisualGDB is implemented via an open-source tool called msp430-gdbproxy. Although it currently only supports erasing the entire FLASH memory, you can easily modify it to erase a custom range instead.
You would need to clone the msp430-gdbproxy repository and edit the MSP430Target.cpp file to support an additional command (e.g. “erase_range”). Then you can remove the original “erase” command from the <sysgcc>\msp430\msp430-bsp\debuggers\core\edp.xml file and add a custom “erase_range” command to VisualGDB Project Properties -> Additional GDB Commands.
No worries and good to know it works. We have updated our documentation to explain the color coding of exportable command lines to avoid any further confusion.
Yes, clicking on “Dump command line to Batch File” should open a dialog asking for the location of the .bat file. If this doesn’t happen, please try attaching a screenshot of the build window showing the context menu with the “Dump command line to Batch File” option.
Hi,
VisualGDB should normally fill the stack automatically as long as you enable the option in Embedded Debug Tweaking.
Once a breakpoint in main() is hit, it will try to find one of the following symbols in the order shown below: __StackLimit, end ,_ebss, _edata. Then, it will fill the area between the first found symbol and the current value of $sp, and will begin monitoring it. The __StackTop or _estack symbol will be used to determine the total stack size.
BTW, the stack monitoring logic is implemented in our open-source Live Watch plugin, so you can always tweak it if you would like to support special project layouts.
Hi,
VisualGDB 5.6 Beta 3 already supports it, as long as you our latest ESP32 toolchain, ESP-IDF 4.3 and the most recent OpenOCD package.
Sorry for confusion. If OpenOCD is running on a Linux machine, indeed the “dump_image” command with a Windows path won’t work.
The easiest way to get it working would be to port the mbatch command from our OpenOCD fork (see this commit). You may need to adjust the code slightly, since the interfaces used by OpenOCD to implement custom commands change from version to version. You can use this fork as a reference. Once VisualGDB detects that OpenOCD supports the mbatch command, it will keep using it instead of dump_image.
Hi,
We have just rechecked the latest ESP-ADF framework. Just as our tutorial mentions, it doesn’t work with the latest GCC 8.x, but does work if you install GCC 5.2.0. This happens because ESP-ADF is based on an older ESP-IDF, that expects that specific old compiler version. Most likely, you ended up using GCC 5.2.0 with VS Code and GCC 8.x with VisualGDB.
Please double-check your GCC versions in the toolchain selection drop-down and make sure you are using GCC 5.2.0 with ESP-ADF as explained in the tutorial.
Hi,
As you have never provided the complete non-ambiguous steps to reproduce the problem from scratch, all we could do is re-run our standard coverage tests on a STM32CubeMX project during the v5.6 Beta 3 release cycle. They did uncover a glitch that could be causing this issue and we have fixed it in the Beta 3. Please try downloading and installing it from the download page.
Hi,
Sorry, this is by design. The “transfer files” command is intended for transferring them to/from Linux hosts and will not work between 2 local directories.
As a workaround, please consider launching xcopy.exe as a custom pre-build step to copy files within the Windows machine.
Hi,
Please double-triple check that you are importing the correct project. The import logic of the wizard never generates any new files, it simply references existing files linked by the project file. You can find out the full path of the file containing the main() function by right-clicking on the tab header in Visual Studio and selecting “Copy full path”. You can then compare it with the path of the file in the original STM32CubeIDE project.
Hi,
As far as VisualGDB is concerned, it will handle the semihosting calls regardless of the interrupt context. So it semihosting is not working, the underlying library is not issuing the semihosting calls properly. You can track it down by disabling semihosting handling on the VisualGDB side and calling printf() outside an interrupt handler. The semihosting call trigger by it will cause the debugger to stop like it was a breakpoint, so you can analyze the call stack, and then review the C library sources to understand why this branch of code is never reached within an active interrupt.
Hi,
It looks like something is preventing OpenOCD from creating a temporary file:
Debug: 1490 5911 command.c:146 script_debug(): command – dump_image C:/Users/user_name/AppData/Local/Temp/tmpD616.tmp 0x200011b8 8 Error: 1492 5912 fileio.c:90 fileio_open_local(): couldn’t open C:/Users/user_name/AppData/Local/Temp/tmpD616.tmp
It could be a buggy antivirus, or non-English characters in the actual user name that you have edited out. Either way, please make sure you are using our OpenOCD fork. It includes a patch that uses a special command for batch memory operations instead of the slower “dump_image” one.
Hi,
Based on the screenshots you attached, this is an advanced ESP-IDF project. It is completely different from the MSBuild projects mentioned by the original poster in this thread, and indeed has different settings.
Please refer to the following page for detailed instructions on building it outside Visual Studio: https://visualgdb.com/documentation/espidf/#buildproblems
