Forum Replies Created
-
Posts
-
Sorry, VisualGDB uses the gdb debugger to debug the code, while Ozone uses its own debugging engine. If the specific project produces an image that breaks gdb, it is outside of VisualGDB’s control to fix this, as it relies on gdb internally. The only workaround we can suggest would be to try a different Keil/GDB version.
No problem. It looks like the gdb debugger is not able to properly report the source location of the breakpoint event:
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x08013366",func="main",args=[],arch="armv3m"},thread-id="1",stopped-threads="all"This sometimes happens due to a bug in the Keil compiler that produces invalid DWARF debug symbols and typically affects code in a specific file beyond a certain line. As a workaround, please consider using the GCC compiler, or try splitting the source file into multiple smaller files. You can also experiment with setting breakpoints in different files to see if there is any pattern.
Sorry, not sure what the question was. In the last post in the thread you mentioned that both frequencies work now.
If you have any other questions, please feel free to repeat them here and we will do our best to answer them.
It looks like you are setting breakpoints in one project and are trying to debug another one. Based on the gdb log, the breakpoint is set in the following file:
C:/Users/dlp/source/repos/MbedProject_testCDC/mbed-os/targets/TARGET_STM/TARGET_STM32L0/TARGET_STM32L072xZ/TARGET_DISCO_L072CZ_LRWAN1/system_clock.c
The -file-list-exec-source-files command reports a different file:
C:/Users/dlp/source/repos/MbedProject_LoRa/mbed-os/targets/TARGET_STM/TARGET_STM32L0/TARGET_STM32L072xZ/TARGET_DISCO_L072CZ_LRWAN1/system_clock.c
Please double-check your settings and make sure you debug the correct project.
Hi,
Please make sure your build the project before debugging. If it doesn’t help, please attach the gdb session log here and we will check what is going on.
Hi,
This looks like something is seriously wrong with the debug settings. Please try re-creating the project from scratch by following one of our tutorials.
If it still doesn’t work, please share the screenshots of all the wizard steps you follow and any settings you change (per our problem reporting guidelines) and we will point out the step that is most likely to cause it.
Hi,
Thanks for reporting this. We are aware of the issue and have already fixed it in our development branch. However, as it does not affect any other part of the program than the About window, we will not make a separate hotfix for this, and will instead include it in the next major update.
Yes, please use the download page to download the latest version: https://visualgdb.com/download/
Thanks, we have confirmed the issue. Indeed, the synchronization link in the wizard was not working as expected with this toolchain (the button in VisualGDB Project properties did).
Please try the following build: VisualGDB-5.5.101.3850.msi
Hi,
No problem, you can change the default location of the base folder for BSPs and other components via Tools->VisualGDB->Manage VisualGDB Packages->Change the default BSP folder (requires VisualGDB 5.5).
The Ubuntu toolchain indeed will not work for the STM32MP1 target.
That said, the regular STM32MP1 toolchain should work out-of-the-box. We have also rechecked it with the hardware and it did work as expected (the STM32MP1 build scripts indeed set the default sysroot location to /not/exist, however the definition in toolchain.xml overrides it).
Please try updating to VisualGDB 5.5 RC1, then completely delete and reinstall the STM32MP1 toolchain. If it still doesn’t work, please share the screenshots of the wizard, showing how you create the project and how exactly you try to synchronize sysroot, and we will investigate this further.
Hi,
Sorry for the delay. This is already supported by selecting the “Import Existing Project” mode in the VisualGDB Embedded Project Wizard. We have just published a detailed tutorial showing this scenario: https://visualgdb.com/tutorials/arm/cmake/import/
Please also feel free to try the following build: VisualGDB-5.5.100.3843.msi. It contains various optimizations to the importing process (e.g. the wizard will now use relative paths and will allow skipping toolchain file generation).
Let us know if you encounter any issues with this workflow and we will be happy to make VisualGDB better.
No problem. That said, incorrect concatenation should normally not happen. Please try checking the VisualGDB Build window for the mbed-cli command line (it will be shown in cyan). You can right-click on it and select “Dump command line to a batch file” to save the exact command line (including the working directory and all environment) to an editable .bat file.
You can then try playing around with the .bat file (e.g. replacing forward slashes with backward slashes, or using relative paths instead of absolute paths) to see if there is any workaround to the broken mbed-cli behavior. If you can find a specific parameter that triggers the issue, we will be happy to update VisualGDB to work around it.
This report uses the same data source as the Embedded Memory Explorer. Please try searching for “stack” and “heap” in the memory explorer documentation for an explanation how they are handled.
No worries. We have added support for custom Mbed targets to the following build: VisualGDB-5.5.100.3839.msi. You can now right-click on the project and select “Target a Custom Board“. Custom targets will now also appear in the Mbed platform list.
The test configurations will have the MBED_TEST_MODE macro defined, so you can check it in a commonly included header to define extra macros.
The building of mbed projects is handled directly by mbed-cli, so VisualGDB is not able to work around the path length limitations. The best workaround would be to check out the project to a shorter location (or to symlink c:\prj to an existing checkout).
We have added variable expansion to Raw Terminal settings to build linked above.
