Forum Replies Created
-
Posts
-
I’m getting this error after clicking “OK” in the “Edit Path Mapping” dialog.
But I have .quickdbg file under %LOCALAPPDATA%\VisualGDB\QuickDebugPresets
VisualGDB version: 5.5.7.3666
—————— System.ArgumentException ——————
System.ArgumentException: Settings file path not specified
в VisualGDB.VisualGDBProjectSettings2.SaveAsOrThrow(String settingsFilePath, Boolean updateCurrentFileName)
в VisualGDB.Add_In.Tool_Windows.WPF.GDBSessionToolControl.editMappings_Click(Object sender, RoutedEventArgs e)
trace=[VisualGDB.VisualGDBProjectSettings2.SaveAsOrThrow:21, VisualGDB.Add_In.Tool_Windows.WPF.GDBSessionToolControl.editMappings_Click:503]I’ve attached a log file.
I wonder, could it be because “Quick debug” dialog doesn’t respect the project’s path mapping?
Thank you.
However, I’m still getting “Frame not in module”
Path in the ELF file looks strange:
— \mnt\c\Projects\pwr_meter\apps\pwrmeter\main.c —————————–
I’m getting ‘Frame not in module”
I think this is probably due to different path in the ELF file because it was compiled under WSL.
I use them too, I think, the main complication is the GUI for UDB itself and other miscellaneous things like clocks and GPIO matrix
If you do not want to spend time learning the autotools/Make internals, or porting the project from WSL to Windows-based build tools, please try importing the project as a Linux-based project built with external tools under WSL and make sure the manual build command line matches one that is already working. As long as both VisualGDB and the manual build are using WSL, they should produce identical results.
Thank you, this works easily.
But how do I debug and flash it?
stm32.props contains a line with:
TINY_EMBEDDED_TEST_HOOK_STDIO=$$com.sysprogs.testsettings.redirect_stdio$$
Changing setting “Redirect printf() to Test Output” changed the previous line to TINY_EMBEDDED_TEST_HOOK_STDIO=0 so it works normal now
Oh, It’s not so clear from the first try.
Cortex-M0+ doesn’t allow to read core debug registers from software at all! https://community.st.com/s/question/0D50X00009XkbSDSAZ/detect-debugger-connected-to-stm32l0-
OK, I’ve googled more thoroughly and discovered that I missed enabling DBGMCU interface with
__HAL_RCC_DBGMCU_CLK_ENABLE();
Looks like it’s now working as intended (except for increased power consumption).
But “Live Variables” still not work properly: it shows 0 most of the time and the real value for just a fraction of second.
