Forum Replies Created
-
Posts
-
Hi,
Please try temporarily removing the package directories and creating a new project via the VisualGDB Arduino Project Wizard. This should re-download the necessary packages and get everything to work.
If not, please check the Output window (not just error list) – it should contain a detailed build log, providing more details about the cause of it (most likely some other component is missing or corrupt and the Arduino builder tool should mention it in the log).
Hi,
No problem. VisualGDB actually provides a few mechanisms specifically aimed at simplifying the workflow for multiple users:
- In order to remove the user-specific host/user names from the settings files, please consider defining host aliases (e.g. “Main build machine”) referencing them from the project settings instead (see this tutorial).
- Please consider moving other user-specific settings to custom per-user variables (see this tutorial). The values of the variables will be stored separately in the .vgdbsettings.<username>.user files, so you can avoid checking them into source control.
You may also find the team settings useful for quickly deploying common configuration parameters to multiple computers in your team.
That said, this will address the settings in the .vgdbsettings files. If you believe the .vcxproj files also contain some user-specific values, please let us know the details and we will try to suggest a way to handle them as well.
Hi,
No problem, we have published an update to the profiler framework that introduces a new setting: Disable interrupts during semihosting operations.
Please try updating the framework and then set the new option to “Yes” in order to automatically disable interrupts during the execution of WriteToFastSemihostingChannel().
No problem and thanks for checking this.
Looks like the default implementation of CanInvokeSemihostingCalls() will indeed not work in this scenario, however you should be able to work around it using some advanced scripting:
- Define a global variable (e.g. int g_DebuggerAttached).
- Create an implementation of CanInvokeSemihostingCalls() that will check the global variable and set the “When running without debugger” setting to “Use a custom function to decide”.
- Create a noinline function with a “nop” statement and call it from main()
- Create a GDB script file that will add a breakpoint in the empty function and run the “set g_DebuggerAttached 1” command when the breakpoint is hit (see this page for details).
- Add “source <gdb script file>” to VisualGDB Project Properties -> GDB Commands -> Commands after selecting target.
This won’t be as flexible as using the ARM Cortex registers (e.g. it won’t detect when a debugger is detached after starting the program), however it should allow distinguishing between starting a new debug session and just resetting the device without a debugger.
Hi,
This looks like a question specific to the ESP-IDF implementation and not VisualGDB itself. Please check the ESP-IDF documentation and/or contact Espressif for further help with ESP-IDF-specific issues.
Hi,
You can use the Debug->Windows->Registers command to show the CPU registers window.
The peripheral registers shown by VisualGDB are ordered according to their physical address (i.e. exactly the same order as they appear in the memory space). If you would like to quickly locate a set of specific registers, please try using the filter field and then marking the registers as favorite.
Good to know it works. We are also planning to release a fully integrated version of this toolchain (including ESP-IDF 4.0) together with the upcoming VisualGDB 5.5 Preview 1 (the internal structure of ESP-IDF 4.0 has changed compared to 3.x, so we are updating VisualGDB to accommodate those changes).
Hi,
This is something managed by the ESP-IDF itself rather than VisualGDB. Please check with Espressif whether the ESP-IDF version you are using supports C++17 and whether there is a configuration option that enables it.
Hi,
We have indeed not checked this functionality with STM32L071, so it is possible that this MCU simply does not implement the “debugger attached” bit. Please try checking the DEBUGEN bit in the DHCR register either via the Hardware Registers window, or manually. Please also check the STM32 documentation for details on this. If this particular MCU does not implement a ‘debugger attached’ bit, the automatic enabling/disabling of semihosting based on it will indeed not work.
Hi,
This is likely affected by the same limitations as Live variables, so please refer to our explanation in the following thread: https://sysprogs.com/w/forums/topic/debug-in-stop-mode-how-it-should-work/
Hi,
The Live variables function relies on the CPU’s ability to read the memory contents without completely stopping. The exact details of this mechanism are target-specific and it is completely plausible that entering the STOP mode would power down either the memory itself, or the logic responsible for reading the memory through SWD/JTAG.
Our best advice is to check the STM32 documentation for the description of the STOP mode logic. There might be a configuration register that allows specifying which clocks actually get stopped during the STOP mode and you might be able to prevent the memory from being powered down (checking what exactly __HAL_RCC_DBGMCU_CLK_ENABLE(); does can provide some clues as well).
Please also feel free to ask on the ST forums, or contact ST support, as they have a better insight into the STM32 tutorials.
Hi,
The socat will actually no longer be required in the upcoming VisualGDB 5.5 as it is switching to the more advanced CMake file API. Once it is released, please simply build/install our latest CMake fork on the target machine (the regular CMake will do as well, although it will not support stepping through the CMake statements) and VisualGDB will use the new API, eliminating the need for socat.
No problem, we have rechecked the latest generated SDK and fixed both the build issue and the field offset detection problem.
Please try this build: VisualGDB-5.5.1.3252.msi
Please note that you would need to re-import the KSDK from the VisualGDB wizard in order to fix the FreeRTOS-related build errors.
Good to know it works. For older project types (e.g. GNU Make), the IntelliSense compilation settings are computed separately from the build settings (as GNU Make doesn’t automatically report the build flags in a structured way) and hence editing some settings manually instead of using the VisualGDB GUI might get IntelliSense out-of-sync with the actual build.
