Forum Replies Created
-
Posts
-
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
Hi,
Indeed, the STM32CubeIDE comes with its own fork of OpenOCD and slightly different scripts. You can install an equivalent of it by selecting OpenOCD (ST Fork) as the debug method instead of the regular OpenOCD. Please note that this requires VisualGDB 5.6 or later.
Hi,
Indeed, the .rsp files are generated after all variables have been expanded and contain very low-level instructions to GCC and other similar tools. The easiest work around it would be to use a simple custom script that will patch the paths inside the .rsp files when they are checked out under a different path. This should be still easier than setting up a complete development environment, including VS and VisualGDB on a docker container.
Thanks for renewing your license.
The page on the screenshot you attached is a completely different window from the Visual Studio project properties, and it indeed does not contain the project properties. Please see our MSBuild Documentation page for an explanation how to open the Visual Studio project properties and this section for a specific location of the “Generate a .bat file” setting.
Hi,
MSBuild indeed uses its own set of variables that work separately from VisualGDB variables. Due to the architecture of MSBuild, unfortunately it’s not possible to easily propagate all VisualGDB variables to the MSBuild level. As a workaround, please consider using MSBuild property sheets. They allow defining reusable variables and targets and importing them from one or more projects.
