Forum Replies Created
-
Posts
-
Hi,
Please note that VisualGDB does not change the original STM32CubeIDE project. If you believe this is not the case, please share the complete instructions how to reproduce the problem from scratch per our problem reporting guidelines and we will try to investigate it further.
Hi,
Most likely, you have selected an incompatible combination of settings at some point. If you can reproduce the problem reliably, please share the exact steps we could follow on our side from scratch to reproduce the problem, including all relevant screenshots per our problem reporting instructions and we will investigate it further.
Hi,
Instrumenting functions for profiling changes their timing and also increases the stack footprint (the code that outputs profiling information takes extra time and requires non-trivial amounts of stack). Most likely, in your scenario this triggers a stack overflow, or makes the interrupt handler run longer than the period between the interrupts.
Unfortunately, there is no fully automated way to troubleshoot such issues. Our best advice would be to try excluding some functions from instrumentation, and to experiment with increasing the stack size and decreasing the complexity of the affected functions.
Hi,
Sorry, this is by design. Instrumenting the image for profiling indeed changes its contents based on the exact instrumentation settings selected for a particular debugging session. As a workaround, please consider modifying the bootloader to temporarily suspend CRC checks during debug sessions (you can check whether a debugger is attached to an ARM chip via the debug module registers – see the your device documentation for more details).
No problem. Please feel free to run OpenOCD with gdb manually. If you can confirm that the debugging works outside VisualGDB, but doesn’t work with VisualGDB, we can definitely fix it.
Regarding the tests, we indeed run a few very basic tests on a few devices before releasing each OpenOCD package, but it doesn’t include programming FLASH memory on STM32L4.
In general, we provide the package mechanism so that our users would not need to locate the relevant code and build if from scratch. They are built automatically on our side with a few very basic tests, and are provided free of charge. Unfortunately, it not viable to extend our technical support to a huge code base maintained by thousands of external developers without directly charging for the time needed to investigate and fix these issues.
As mentioned before, please consider using VisualGDB with the J-Link software. It is maintained and tested by Segger and generally works more reliable than free OpenOCD.
Thanks, we have reproduced the issue and fixed it in the following build: VisualGDB-5.6.5.4257.msi
Hi,
Please make sure you also follow the step 8e of the tutorial. It shows how to fix this exact issue.
As another alternative, please consider updating to VisualGDB 5.6 Beta 4. It uses the new path syntax by default and doesn’t require adjusting it manually.
Hi,
Please refer to the following page for an overview of the typical structure of STM32 projects, and their main components: https://visualgdb.com/documentation/embedded/stm32/
Hi,
This is by design. FreeRTOS does not always keep a global list of all synchronization primitives, so VisualGDB obtains it by looking through all global variables.
If you would like VisualGDB to automatically locate a queue or another similar primitive, please consider declaring a global handle variable and assigning it with a copy of your object.
You can also try extending the primitive location logic by extending our open-source FreeRTOS plugin, however this is something to do at your own risk.
Hi,
This looks like an issue specific to a particular ST board and not to VisualGDB. Please feel free to post it on the ST forum to see if anyone else has encountered it.
Hi,
VS2022 Preview 2 indeed changed the MSBuild platforms location from:
C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Microsoft\VC\v160\Platforms
to
C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Microsoft\VC\v170\Platforms
You can fix the issue either by manually moving the VisualGDB platform from the old location to the new one, or by installing the following build: VisualGDB-5.6.5.4247.msi
Hi,
No problem. Please try setting the Tools->Options->VisualGDB->Advanced Build->Build Results Window Stickiness option to 0.
You can find more about various VisualGDB settings, including a searchable list of them on this page.
Hi,
OpenOCD support for specific devices is usually contributed by the device vendors or someone from the OpenOCD community. We periodically release builds based on the latest OpenOCD source, however we do not maintain device-specific parts of it.
The OpenOCD code base is evolving very fast, so there is a high chance the issue is already fixed in the latest OpenOCD build released today. Please try installing it via VisualGDB Package Manager.
Alternatively, please consider using Segger J-Link with the J-Link software. The J-Link software is a proprietary replacement to OpenOCD that is maintained and tested by Segger, and it usually works more reliably than open-source tools. VisualGDB is integrated with both tools equally well, so you can chose the best one for your setup based on your requirements.
