Porting RIOT OS GNU MAKE project to VisualGDB

[Gordon01]

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.

Attachments:

You must be logged in to view attached files.

[support]

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.

[Gordon01]

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?

[support]

Hi,

The easiest way to do this would be to use Embedded Quick Debug.

[Gordon01]

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.

 

Attachments:

You must be logged in to view attached files.

[support]

No problem, you can configure the path mapping between GDB and VS as shown here: https://visualgdb.com/documentation/pathmapping/

[Gordon01]

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 —————————–

 

Attachments:

You must be logged in to view attached files.

[support]

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.

[Gordon01]

I’ve attached a log file.

 

I wonder, could it be because “Quick debug” dialog doesn’t respect the project’s path mapping?

Attachments:

You must be logged in to view attached files.

[support]

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).

[Gordon01]

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]

[support]

No problem, please try this build: VisualGDB-5.5.8.3769.msi

[Gordon01]

This build works!

Sorry for the late answer.

 

[Author]

Posts