Forum Replies Created
-
Posts
-
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.
Hi,
It looks like you have hardcoded an invalid sysroot directory (/not/exist) somewhere in the settings. Please try creating a new project from scratch and make sure you don’t accidentally specify the invalid sysroot directory.
Thanks for the update, this makes sense. You might be able to work around the inaccessible DHCSR register by creating a global variable (e.g. g_DebuggerAttached) and checking it from the custom CanInvokeSemihostingCalls() implementation. Then you can use gdb scripting to set a breakpoint in some of the functions executed at startup (VisualGDB already sets a breakpoint in main()) and set this variable to 1, once the breakpoint is reached. This would require some non-trivial scripting, but should achieve the same effect as the DHCSR register.
