Forum Replies Created
-
Posts
-
Hi,
Based on the error message you shared, it looks like VisualGDB is not installed on the machine you are using to build the project.
Please ensure VisualGDB is installed and activated on the user account used to run the automated builds.
Please feel free to look through the following tutorial for a detailed step-by-step example: https://visualgdb.com/tutorials/ci/tfs/
If you can confirm that VisualGDB is installed, please try building the solution using devenv.exe, not msbuild.exe (see this page).
Sorry, this is way to specific to be covered directly. Please consider asking on the Littlevgl or ESP32 forum.
Sorry, this is by design. Different boards have different clock configurations, so unless you specifically clone a sample designed for your board (via the “STM32CubeMX Samples” switch in the wizard), you would need to adjust the clock settings to match your board.
If you believe the clock configuration for a board-specific sample in invalid, please consider reporting it to ST, as VisualGDB takes the STM32CubeMX samples directly from the STM32 SDKs.
Sorry, unfortunately it’s beyond the scope of our product support to help troubleshoot project-specific issues. Our best advice would be to step through the clock-related code in both projects and compare it side-by-side.
If this doesn’t help, please consider creating a topic on the STM32 forums or on StackOverflow to get help from other developers.
No problem. We have double-checked it and indeed the precompiled mbed binaries for Python 3 would not work on some machines.
We have updated VisualGDB internally to launch the .py script instead, that should resolve the problem. This fix will be included in the upcoming VisualGDB 5.5 Preview 3. Until then, using Python 2.7 instead of 3.x should be the best workaround.
Hi,
Most likely, some mbed tools (e.g. Python environment) are corrupt. Please try this build, it will display more information about the errors: VisualGDB-5.5.2.3426.msi
If some mbed tools fail to launch, please try deleting the entire Python environment containing them and let VisualGDB re-install it from scratch. If nothing helps, please check whether the mbed tools reported in the error details can be launched manually. If not, please check your antivirus for false positives.
Sorry, unfortunately target-specific issues like this one are not covered by the regular VisualGDB support.
If you believe an STM32 device is not operating as expected, please consider contacting ST support, or posting on ST forums.
Good to know it works. Most likely, you have initially upgraded the toolchain, but not the SD card image (or the other way) and synchronized an incompatible SD card image with a toolchain that expected different versions of the headers/libraries. Either way, the procedure you described is the correct way of resetting the toolchain, so it should now work as expected.
Hi,
Thanks for finding this out. Normally, the clock-related code in stm32fxxx.cfg would get executed just after starting a debug session. It would raise the system clock frequency, allowing for faster FLASH programming and faster JTAG communication, and once the SystemClock_Config() runs, it would override the parameters set via stm32fxxx.cfg.
The clock parameters set by the stm32fxxx.cfg would only affect the code that runs before SystemClock_Config() (i.e. startup code) and should not affect the rest of the program.
Either way, if you prefer disabling this mechanism, you can copy a modified version of the .cfg file to the project directory and replace the path to it in OpenOCD settings (expand the Advanced view to edit it) to $(ProjectDir.forwardslashes)/<cfg file name>.
Regarding the startup file, VisualGDB normally does not allow replacing it because the file shipped with VisualGDB is 100% equivalent to the original .s file. It only defines the interrupt vector table and the reset handler and does not handle the clock. If you absolutely need to override it, please consider setting the “excluded from build” flag for the .c file and adding the .s file to the project manually.
Hi,
This looks like a corrupt toolchain. Unfortunately, as you have cropped the screenshot, it’s hard to tell whether it’s an IntelliSense-only issue, or a full-scale toolchain corruption (see this page for best error reporting practices). Either way, the easiest way to solve this would be to delete the entire Raspberry Pi toolchain, reinstall the one compatible with your SD card image (see the full list here), and verify that newly created projects build after reinstalling the toolchain.
If the projects stop building after you resynchronize the toolchain’s sysroot, your SD card image is likely incompatible with the toolchain. If this is the case, simply start with a fresh compatible image from the list and you should be able to build the projects.
The actual clock initialization is performed by the SystemClock_Config() function. Hence if the clock is initialized incorrectly, the function either does not get executed, or uses incorrect parameters. The only way to diagnose this is to step through the SystemClock_Config() function in the debugger and double-check the values it sets.
Hi,
The clock setup for STM32 devices is normally done by the SystemClock_Config() function. Please try locating it in the files generated by STM32CubeMX (if you cannot find it, try searching for functions calling HAL_RCC_OscConfig()) and then check whether the VisualGDB project includes the file defining this function and whether it is called from your main() function.
Our consulting focuses on issues that are too specific to be supported directly by the off-the-shelf products. E.g. porting specific libraries to new platforms, porting projects between compilers or SDKs, creating tools for automatically importing large multi-project solutions in a custom format, creating BSPs and detailed setup tutorials for niche devices that are not sufficiently popular to be supported directly, etc. We also do paid screen sharing sessions helping our users troubleshoot weird problems in their codebase that would otherwise take too long to narrow down. Feel free to reach out to our sales if you need an estimate for a specific issue.
Indeed, VisualGDB normally uses the GCC compiler (that is itself one of the most popular compilers in the embedded space), so all the solutions that work with GCC would also work with VisualGDB.
Also a heads up that our support covers VisualGDB-specific issues (e.g. help finding features like Live Memory or fixing bugs in VisualGDB itself), however we are generally not able to provide help with the external components (e.g. the GCC compiler, vendor-specific SDKs, connectivity/power issues, external libraries, etc.), as those components are outside of our control. We do offer paid consulting services for everything that isn’t covered, however in order to make sure we can allocate resources to develop our products and fix issues that are within our control, we have to be fairly strict about what we can address via our regular product support.
