Forum Replies Created
-
Posts
-
Hi,
Most likely your device is using a different clock frequency than the device used in the default USB communication sample. Please try locating a sample for your device/board in the ST samples folder and copying the SystemClock_Config() function from it.
Another alternative would be to select “Use STM32CubeMX samples” when creating a new project. This will locate a matching ST sample for your board that should have the correct clock settings specified.
Hi,
This could happen if your Makefile contained a target structure that cannot be easily parallelized. Also the MinGW Make has a bug that often hangs it when using multi-core mode. Our best advice would be to try switching the project to MSBuild. It’s not officially supported for MinGW/Cygwin projects, however if you add the ‘VisualGDB’ platform to the project and manually enter the toolchain location via VS project properties, VisualGDB should pick it up. MSBuild does not rely on Make for local builds, so it will work much faster. If it does not work, let us know and we will try to help.
Hi,
Please try removing the reference to the “STM32 HAL” on the Embedded Frameworks page of VisualGDB Project Properties.
Hi,
This is actually a common point of confusion, so the next VisualGDB preview will come with support for easy out-of-the-box importing of STM32CubeMX projects.
Hi,
Are you still using VisualGDB 5.3 Preview 5? If yes, please check that the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.segger-dmsp\SeggerEDP.dll file exists. If it does, please check the Debug Settings page again. Does it show any settings below the “Segger J-Link” item?
Hi,
This happens if your PATH variable contains multiple Cygwin directories. ESP32 cygwin binaries would try to load an incompatible version of cygwin1.dll causing this problem.
Please double-check your PATH and remove other Cygwin directories from it.
Hi,
OK, thanks, the issue was caused by the FLASH initialization code timing out. We have fixed this in an update to our OpenOCD package and also updated the flash_drivers examples to specify the timeout values instead of hardcoding them in OpenOCD.
Hi,
Thanks, it looks like the debug plugin failed to load. Please try deleting the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.segger-dmsp folder, restarting Visual Studio and creating a new project from scratch. VisualGDB should re-download the plugin. If it does not solve the problem, please check that the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.segger-dmsp\SeggerEDP.dll file is present. If not, please check your antivirus logs, it might be removing the DLL during the installation.
Hi,
Thank you for the screenshots, however looks like you missed the “Debug Settings” page (#4 on your screenshots) that contains the relevant settings that should explain what is going on. Please post it as well.
Hi,
Thanks, we have just rechecked Preview 5 and the latest Segger package and could not reproduce any problem. Please post a screenshot of the Debug Settings page of your VisualGDB Project Properties or the Debug Settings page of the Embedded Project Wizard so that we could check for common errors.
Hi,
It looks like the debug method package is not working properly. Please try re-downloading the VisualGDB 5.3 Preview 5 installer and re-installing it; then ensure you have the latest Segger debug package via Tools->VisualGDB->Manage VisualGDB Packages.
If nothing helps, please make a screenshot of the Debug Settings page in your VisualGDB Project Properties and attach it here. This should help understand what is causing this.
Hi,
Perhaps Keil/Eclipse enables the hardware FP implicitly or the version of port.c you use with those IDEs contains conditional statements that exclude FP-specific code?
Please try searching the port.c file compiled with Eclipes for “vstmdbeq” and see if it has any #ifdef’s around it. If no, please check the exact command line used to build this file. Does it contain any FP-related settings?
