- This topic has 12 replies, 2 voices, and was last updated 3 years, 8 months ago by
.
-
Posts
-
I’m trying to migrate to VisualGDB completely, but struggling with some legacy projects.
The project I’m talking about is based on RIOT OS and is configured to be built by basic Autotools and GNU Make, however, I still have problems with it 🙂
I want to migrate one-way and get rid of makefiles.
Also, I have only basic knowledge about Autotools and I don’t fully understand makefiles so this complicates things.
What is the best way to approach this task?
Right now, I’m trying an “Import a project built with command-line tools”.
On a step “run build command” I get this error message from build script:
Aborting compilation for your safety.
Related variables = RIOTBASE RIOTCPU RIOTBOARD RIOTMAKE RIOTPKG RIOTTOOLS RIOTPROJECT APPDIR BUILD_DIR BINDIRBASE BINDIR CCACHE_BASEDIR GITCACHE PKGDIRBASE DLCACHE_DIR
C:/Projects/pwr_meter/apps/pwrmeter/../../Makefile.include:73: *** Make sure no path override is empty or contains spaces!. Stop.also with an error about not found “pwd” command.
We build this project under WSL with just issuing a make command. A compiler is “normal” arm-none-eabi-gcc version 9.3.1
My ultimate goal is this project completely converted to MSBuild format and built without WSL with the latest version of arm-none-eabi-gcc.
Hi,
The best way to convert the project into an MSBuild-based one would be to find a way to dump all the gcc command lines used by the current setup (each Makefile handles this differently, so please check the RIOT OS documentation for more details), and then create a new VisualGDB project from scratch and adjust its build settings to match the captured command lines.
You can find the exact command lines used by VisualGDB to build an MSBuild-based project in the .rsp files.
We also have a detailed tutorial on using .rsp files to troubleshoot imported projects here: https://visualgdb.com/tutorials/arm/import/diagnose/
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.
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?
Hi,
The easiest way to do this would be to use Embedded Quick Debug.
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.
No problem, you can configure the path mapping between GDB and VS as shown here: https://visualgdb.com/documentation/pathmapping/
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 —————————–
Hi,
The path mapping looks correct now. If the problem persists, please send us a screenshot of the problem along with a gdb log and we will help you understand what is going on.
I’ve attached a log file.
I wonder, could it be because “Quick debug” dialog doesn’t respect the project’s path mapping?
Yes, Quick Debug has its own path mappings stored in the .quickdbg files under %LOCALAPPDATA%\VisualGDB\QuickDebugPresets.
You can edit the Quick Debug path mappings using the path mapping icon in the GDB Session window (item #3).
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]No problem, please try this build: VisualGDB-5.5.8.3769.msi
- You must be logged in to reply to this topic.