Forum Replies Created
-
AuthorPosts
-
September 13, 2019 at 04:03 in reply to: Calling to FastSemihosting from interrupts before initialization finished loops #25797
support
KeymasterHi,
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().
September 12, 2019 at 17:13 in reply to: "When running without debugger" option doesn't work as intended #25794support
KeymasterNo 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.
support
KeymasterHi,
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.
support
KeymasterHi,
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.
support
KeymasterGood 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).
support
KeymasterHi,
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.
September 11, 2019 at 15:41 in reply to: "When running without debugger" option doesn't work as intended #25776support
KeymasterHi,
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.
support
KeymasterHi,
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/
support
KeymasterHi,
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.
support
KeymasterHi,
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.
support
KeymasterNo 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.
support
KeymasterGood 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.
support
KeymasterHi,
No problem, it looks like VisualGDB doesn’t support the FreeRTOS version you are using, but it should be very easy for us to resolve. Could you please share a link/attach the exact SDK you are using so that we could ensure we are looking at the same thing?
support
KeymasterThanks for getting back to us. We have released an update to the profiler framework resolving the issue. Please update it via Tools->VisualGDB->Manage VisualGDB Packages.
September 5, 2019 at 02:15 in reply to: Exec format error with Hello World project on RaspberryPi #25751support
KeymasterHi,
Good to know it works. Normally, VisualKernel should be able to find an incomplete sources/tools directory and continue the build. Once the build completes, it is registered with the VisualKernel and is automatically reused for all future projects. If you believe this is not working, please feel free to share the exact instructions to reproduce the behavior you encountered and we should be able to fix it or suggest a workaround.
-
AuthorPosts