Forum Replies Created
-
Posts
-
Hi,
This one is tricky. VisualGDB projects are designed to be debuggable outside Visual Studio as well (e.g. to run tests or record traces), so the debug engine does not receive the regular Visual Studio variables.
VisualGDB-level variables (e.g. $(ProjectDir)) will work and you can also pass arbitrary variables via environment. The $$SYS:MCU_ID$$ syntax is used for BSP-level variables (that are not specific to a particular project) and are used for tasks like translating the same BSP definition into both CMake rules and MSBuild rules.
Hi,
It could be possible to do this via user variables. Feel free to let us know your the project type so that we can provide more details.
Yes, this means it is working correctly.
On a second thought, do you have the “sudo” explicitly specified as the build command? If yes, it actually won’t work unless sudo is configured to run without asking for password for this user.
When VisualGDB decides to use sudo (there’s an option to enable it for debugging, but not for building), it uses special workarounds to handle sudo prompts, that won’t work if you just specify “sudo” as a part of the command line.
The plugins are included with VisualGDB and will work out-of-the-box. The only reason why we publish the sources is so our users can tweak them to some specific cases (e.g. using a custom queue class and wanting to plot its utilization without stopping the program).
Hi,
VisualGDB does fully support ThreadX and FreeRTOS object view. It actually users a special memory reading mechanism that works without interrupting the target, so it can display the state of various objects while your program is running. See this tutorial for more details.
Both thread plugins are open-source, so you can tweak them to a particular project.
That said, it is an advanced feature that requires the Custom edition or higher. If you are using a lower edition, you can always upgrade here.
Hi,
VisualGDB handles WSL by launching a monitor process on the Linux side that forwards the actual application output back Windows via TCP. The most likely explanation why it’s not working is that the firewall either on Linux or Windows side is preventing VisualGDB from connecting to it.
If turning the firewall off doesn’t work, you can try narrowing it down by running VisualGDB.exe /lxsstest. It will run the “uname -a” command inside WSL, but will launch the monitor process in a separate window, so you can check if it does anything suspicious.
Hi,
You can just patch the linker script file under %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs.
If you want to fix it for multiple devices, you can try regenerating the entire BSP from the STM32 SDKs using our BSP generator. However, it involves some manual setup (e.g. downloading STM32CubeMX) and will download huge SDK packages from ST.
Hi,
You can try this build: VisualGDB-6.0.104.5230.msi. It uses relative paths for BSP sources, include directories and linker scripts, as long as they are within the project directory.
Hi,
The procedure for getting exactly the same output would be to compare the builds, narrow down on specific differences, and track each of them to the root cause. That said, the ELF files will not be 100% equal due to source file paths stored in them, and the symbol in the final binary could be in a different order if the linker does not pick them deterministically.
VisualGDB works just fine, as long as the board itself is debuggable and not broken. If you are already struggling to get it working, just connecting to it with VisualGDB won’t automatically fix the issues, and our support won’t be able to troubleshoot or replace the board for you.
Hi,
The memory definitions are automatically parsed from the device definitions inside the original SDKs, and sometimes they don’t match the datasheets. Normally, ST fixes this in the next SDK release. Until then, patching the linker script manually should be a reasonable workaround.
Sorry, we tried helping our users with such issues before, but it always backfired. Users would then run into much bigger problems further down the road, and would expect our support to review complex schematics of custom boards, or look through large projects written by someone else, that somehow interfere with debugging logic.
So, we had to limit our regular support to issues that are specific to our tools. If you would like us to explain anything else, we can do it at our consulting rate. You can read more about it here.
Hi,
Based on what you described, it looks like a wiring issue. Please refer to your board and JTAG debugger documentation for details on getting the wiring correctly. VisualGDB cannot automatically fix it for you, or troubleshoot any wiring issues.
If you are not sure, please make sure you can debug the same board with the same example by running OpenOCD manually. If it works outside VisualGDB, we can help you configure VisualGDB to match that setup. If the board doesn’t work outside VisualGDB either, you will have to figure it out first before trying VisualGDB.
Hi,
We are aware of the new STM32H7S series and have the BSP based on the official SDK from STM32, however have not tried the hardware on our side yet.
If you would like to replicate the 2-project structure from STM32CubeIDE, we would advise using the Advanced CMake Project Subsystem to create the bootloader + application projects separately, and then manually combine them into the same project by editing CMakeLists.txt. Specifically you would need to:
- Move the find_bsp() statement from the second project into the first one, adding an ALIAS parameter (e.g. BSP2)
- Move the add_bsp_based_executable() statement as well, setting BSP_ALIAS to match the second BSP.
You can also just create 2 separate MSBuild projects and have them in the same solution (right-click on Solution node -> Add -> Existing Project).
We do not have the hardware yet to give exact advice on replicating the ExtMemLoader logic (we will be publishing a tutorial in a couple of weeks), however, you can try checking what exactly does the STM32CubeIDE do in this mode. If it’s running OpenOCD with some special arguments, or executing the STM32CubeProg, we can help you configure VisualGDB to match that.
Hi,
Thanks, looks like the new preview build introduces additional type checking that fires false positives in some cases.
We have added a workaround to this build: VisualGDB-6.0.104.5221.msi
