debugging STM32 makefile project on W10 WSL

[kentmartin99@gmail.com]

Hi,

I am trying to debug a project that i have building under command line using WSL on windows 10.

I can currently build using a make command in the WSL console.

I have tried creatinig a project with the embedded project wizard-> import a project built with command line tools->specify a build command line manually->SRM32F413VG->import preserving directory structure(set folder where makefile is kept)

build command , command = make, arguments =””

working directory = <folder where make file is>

same for clean except “clean” as argument

Executable file to debug, bootloader.bin in build directory where binary is output when I manually build by command line

debug using st-link v2

 

This does build as it doesn’t use WSL to build in this config

 

I then tried similar but starting with linux project wizard->import a project->import a project built with other tools->Use W10 linux subsystem

toolchain=default gcc-based toolcahin on localhost-lxss

source are located on W10 computer (secifiy project folder)

store source files on the windows computer

 

This will not build and can’t seem to find arm-none-eabi-g++ which i can run fine from WSL on the WSL console.

specify binary built manually bootloader.bin in folder where it is built.

when debugged get

^error,msg=”No executable file specified.\nUse the \”file\” or \”exec-file\” command.”
No executable file specified.
Use the “file” or “exec-file” command.

 

Is there any help on how to build and run an embedded makefile project using WSL?

 

Thanks

 

 

 

 

 

[support]

Hi,

Sorry, using WSL for embedded projects isn’t directly supported, however there is a good workaround for it.

Please try importing the project as a command-line project using our regular ARM toolchain (you can start with a dummy build command line as it won’t affect debugging). Then specify the location of the ELF file and use the regular debug settings. This will use the gdb executable from our ARM toolchain to debug the ELF file produced by the WSL (if your target is a barebone STM32, they should be compatible). Note that you will need to point VisualGDB to the ELF file that contains symbols, not the stripped .bin file.

You can use the Breakpoint Diagnostics window to set path mappings like /mnt/c <=> c:\ so that  VisualGDB will know how to handle the WSL paths.

Once you get debugging to work, you can configure project building by creating a WSL shell script that will go to the project directory and launch Make, and then specifying “bash.exe <shell script>” as the build command line so that VisualGDB will hand off the build to WSL.

If it doesn’t work or you need more details, please let us know and we will be happy to help.

[kentmartin99@gmail.com]

Hi,

Thanks, I’m new to this product so could you please explain the steps in more detail.

i.e. in my notes I explained what I did for each step of using your tool.

Please outline

new visgdb project?

embedded project wizard

import project with command line tools

specify a build command line manually?

specify part

specify source – import preserving

debug settings – specify bootloader.elf file in original location?

debug using -> specify attached usb st-link

I have done the above and it is debugging, is this the correct process?

You can use the Breakpoint Diagnostics window to set path mappings like /mnt/c <=> c:\ so that  VisualGDB will know how to handle the WSL paths

I did this also

Once you get debugging to work, you can configure project building by creating a WSL shell script that will go to the project directory and launch Make, and then specifying “bash.exe <shell script>” as the build command line so that VisualGDB will hand off the build to WS.

Sorry I haven’t made shell scripts before, as I am using windows and trying to avoid linux, one main reason for using your product.

how do I do theis and then how and where do I specify the build command line.

Thanks for your help.

Could you please explain steps in detail, as I’m likely in a different time zone to you and leaving vital information out like this will waste days and possibly weeks of my time. The reason I chose this product was to avoid exactly that situation.

 

Thanks

 

 

[support]

No problem, we will try to help, however we would like to clarify one thing first.

Is there any specific reason why you need to use WSL? This sounds like a very complicated setup that indeed requires non-trivial manual configuration and if you are not familiar with the Linux internals, it would be much easier to convert the project into a format where VisualGDB fully controls the build and abstracts away the low-level tools and settings (e.g. MSBuild).

If this is an option, we can help you understand various MSBuild-related settings so that you can replicate most of your existing project’s setup in an environment fully managed by VisualGDB.

[kentmartin99@gmail.com]

Hi,

The existing project is built under linux. This is why I use WSL so I can build the code as is without having to hack it into a project.

Trying to get all the build settings out would be quite a task in my experience and hardly ever works.

I  have spent a lot of effort to get other linux based makefile projects running under another project based IDE and it takes a lot of effort and you will be lucky to get it to build and less so to run correctly. This has been my experience and since I do not need to modify the source that much, I really don’t want to waste a couple of weeks on that. Hence why I chose to use a tool that could alleviate some of the pain… so  I thought.

So you ask why I don’t want to learn all required to get the information from the linux build system and also learn msbuild so I can put it into another build system I am not familiar with?  I think that would cause even more delays learning two things instead of one.

BTW our time zones are likely not in sync. so as I requested earlier please give responses that don’t require constant follow up.

 

Thanks

[support]

Thanks for clarifying your constraints and good to know debugging works. Your description of the debugging setup matches what we described.

Regarding building, combining the WSL for building the projects with the regular embedded workflow for debugging them is not trivial. Because it introduces many additional breaking points, we normally do not recommend doing it unless you are familiar with the Linux internals and are prepared to troubleshoot Linux-related issues. As it is a very rare scenario, we do not intend to support it out-of-the-box and would advise choosing a different approach if you do not wish to go deep into the Linux build tool internals. Hence we can offer the workaround below.

Please consider creating 2 projects in the solution: one for building the code (linux project wizard->import a project->import a project built with other tools->Use W10 linux subsystem) and another one for debugging the code (the one you have just created). You should still be able to build the code via Build->Build Solution and will be able to debug it by debugging the debug-only project. If the imported Linux project doesn’t build, please attach the screenshots of your build settings, the error about the missing arm-none-eabi-g++ file and the output from running “which arm-none-eabi-g++” in the WSL’s bash console. Then we will help you modify the build settings to find arm-none-eabi-g++ as expected.

We are sorry our responses require follow-ups. We tried answering as soon as possible (about 30 minutes from your inquiry), hoping that it would not introduce much delay. Unfortunately, as you requested a very specific setup that is not directly supported, we need to understand more about your constraints in order to suggest a reasonable trade-off. If you are looking for a fast turnkey option, please consider one of the 2 following options:

1. We can offer you a paid screen sharing session where we will analyze your existing project, explain the roles of the low-level tools required to build it, make the necessary build scripts and make sure everything matches your expectations. Because this is specific to the project, we charge an hourly fee for this and are not able to include it in a regular product support.
2. We can also offer you our paid project conversion service. If you could send us the project archive, we can give you a quote for converting it to an MSBuild project fully managed by VisualGDB. Once the conversion is over, you will be able to use the regular Visual Studio GUI to edit various project properties and will not need to fight the Linux tools ever again.

 

[kentmartin99@gmail.com]

Hi,

Setting uo a linux build does not work as I explained before.

You still have not supplied all the details required to complete a new linux project.

You omitted Source code location, Source code access, and building and debugging settings.

for you information I will show what I have tried again, and please show what you expected me to have done for fields you have not indicated values for.

 

source code location -> located on the windows computer ( this could be either?, which is correct?)

source code access-> store files on windows computer ( source/repos/…. i can’t change this field. )upload modified source to localhost on each build

left at default /tmp.VisualGDB/c/Users/kentm/source/repos/…. projectname

Building and debugging -> source path on linux  /tmp/visgdb/c/users/kentm/source/repos/ ..project name

-> source path on windows  cL\users\kentm\source\repos\source folder name (move vs projject to source not ticked)

-> build dir: /tmp/visgdb/c/users/kentm/source/repos/projectname

-> build cmd: make

-> clean cmd: make clean

-> executable:  not sure where this will come out with your tools only where wsl will output ?

 

When running build during setup :- “command exited with code 2” make: *** no targets specified and no makefile found. Stop.

output window

1>Directory: /mnt/c/Users/kentm/source/repos/kocherga-demo
1>VisualGDB : error : Command-line action failed
1>VisualGDB : error : Build has failed. See the Output window for more details.
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.MakeFile.Targets(44,5): error MSB3073: The command “”C:\Program Files (x86)\Sysprogs\VisualGDB\\VisualGDB.exe” /build “C:\Users\kentm\source\repos\kocherga-demo-linux\kocherga-demo-linux.vcxproj” “/solution:C:\Users\kentm\source\repos\kocherga-demo-linux\kocherga-demo-linux.sln” “/config:Debug” “/platform:Win32″” exited with code 1.
1>Done building project “kocherga-demo-linux.vcxproj” — FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

 

build settings attached.

Please endeavor to include all details of project creation as I have illustrated twice now.

Again we are in different time zones and time is wasted each time you fail to provide information specifically requested.

This time please include ALL information , please do not assume what I know, include all settings required to complete in one go.

Thanks.

 

 

 

 

 

Attachments:

You must be logged in to view attached files.

[support]

Unfortunately, we cannot provide the exact settings that will successfully build a 3rd-party project that we have never seen before. We do not know the directory where you have stored it. We do not know the structure of the project. We do not know where is its primary Makefile located. We do not know if if requires any additional configuration steps. This is something you need to understand before importing the project, as without this information it is not possible to configure VisualGDB (or any other IDE) to build it.

The settings your mentioned appear correct, however based on the error log you provided, the directory you specified while importing the project (/mnt/c/Users/kentm/source/repos/kocherga-demo) does not have a Makefile, hence the build fails.

Please share the command line (and the output) you use when building the project manually under the Linux subsystem (including the “cd” command for entering any directories) and we will share instructions on updating your current setup to replicate that build.

[kentmartin99@gmail.com]

The folder /mnt/c/users/kentm/source/repos/ is a folder your tool has created and not my source.

my source is located below my github folder other folders are from your tool.

If you read my questions above you can answer in terms of the folder where my source is located (and yes the makefile is in that folder),

or in terms of what extra folder your tool makes to copy or otherwise build the project.

Please read the questions I posted in the description previous.

 

[kentmartin99@gmail.com]

Ok hopefully this will clarify for you, i changed a few options this time since it didn’t work and you won’t answer the question i put previously about which options to use:

my code is at (makefile is in this folder directly):

C:\Users\kentm\Documents\GITHUB\SW4STMWorkspace\kocherga-demo\

or in WSL

/mnt/c/Users/kentm/Documents/GITHUB/SW4STMWorkspace/kocherga-demo/

to setup the process is :->

linux project wizard->import a project->import a project built with other tools->Use W10 linux subsystem (def gcc -subsystem)

source code location->

Q1!!!!   windows or linux ????????????? answer the question!!!! it can be either

I will try windows because you refuse to answer the question

source code access->

Q? which option to use????

This time I will choose “setup shares and mount points manually” since you have not answered this question.

local:C:\Users\kentm\Documents\GITHUB\SW4STMWorkspace\kocherga-demo

remote: /mnt/c/Users/kentm/Documents/GITHUB/SW4STMWorkspace/kocherga-demo

building and debugging->

make and make clean

run build -> command exited with code 2

make

arm-none-eabi-g++ build/obj/crt0_v7m.o build/obj/vectors.o build/obj/chcoreasm_v7m.o build/obj/canard.o build/obj/canard_stm32.o num -Wfloat-equal -fno-strict-aliasing -fno-strict-overflow -Wno-implicit-fallthrough -falign-functions=16 -U__STRICT_ANSI__ -fno-exceptions -fno-unwind-tables -fno-stack-protector -fno-builtin-printf -fno-builtin-fprintf -fno-builtin-vprintf -fno-builtin-vfprintf -fno-builtin-puts -u_port_lock -u_port_unlock -u_exit -u_kill -u_getpid -uchThdExit -u__errno -fno-single-precision-constant -nodefaultlibs -lc -lgcc -lm -O0 -g3 -ffunction-sections -fdata-sections -fno-common -flto -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -nostartfiles -L./ -Wl,-Map=build/kocherga_demo.map,–cref,–no-warn-mismatch,–library-path=/ld,–script=ld.ld,–gc-sections,–defsym=__process_stack_size__=0x1000,–defsym=__main_stack_size__=0x1000 -mno-thumb-interwork -mthumb -o build/kocherga_demo.elf.o build/obj/hal_pwm.o build/obj/hal_qspi.o build/obj/hal_rtc.o build/obj/hal_sdc.o build/obj/hal_serial.o build/obj/hal_serial_usb.o build/obj/hal_spi.o build/obj/hal_st.o build/obj/hal_uart.o build/obj/hal_usb.o build/obj/hal_wdg.o build/obj/nvic.o build/obj/stm32_isr.o build/obj/hal_lld.o build/obj/hal_adc_lld.o build/obj/hal_can_lld.o build/obj/hal_dac_lld.o build/obj/stm32_dma.o build/obj/hal_ext_lld.o build/obj/hal_pal_lld.o build/obj/hal_i2c_lld.o build/obj/hal_mac_lld.o build/obj/hal_usb_lld.o build/obj/hal_qspi_lld.o build/obj/hal_rtc_lld.o build/obj/hal_i2s_lld.o build/obj/hal_spi_lld.o build/obj/hal_sdc_lld.o build/obj/hal_st_lld.o build/obj/hal_gpt_lld.o build/obj/hal_icu_lld.o build/obj/hal_pwm_lld.o build/obj/hal_serial_lld.o build/obj/hal_uart_lld.o build/obj/hal_wdg_lld.o build/obj/chprintf.o build/obj/memstreams.o build/obj/nullstreams.o build/obj/syscalls.o build/obj/app_shared.o build/obj/board.o build/obj/main.o build/obj/libstdcpp.o build/obj/sys_console.o build/obj/sys.o build/obj/uavcan.o build/obj/ch.o build/obj/syscalls_cpp.o -mcpu=cortex-m4 -Wdouble-promotion -Wswitch-e
make: arm-none-eabi-g++: Command not found
chibios/os/common/startup/ARMCMx/compilers/GCC/rules.mk:258: recipe for target ‘build/kocherga_demo.elf’ failed
make: *** [build/kocherga_demo.elf] Error 127

Please this time read the questions in line and answer? Please!

 

 

 

 

 

 

[kentmartin99@gmail.com]

console output from build,

1>—— Build started: Project: kocherga-demo-linux, Configuration: Debug Win32 ——
1>VisualGDB: Run “make ” in directory “/mnt/c/Users/kentm/Documents/GITHUB/SW4STMWorkspace/kocherga-demo” on (Windows 10 Linux subsystem)
1>
1>arm-none-eabi-g++ build/obj/crt0_v7m.o build/obj/vectors.o build/obj/chcoreasm_v7m.o build/obj/canard.o build/obj/canard_stm32.o build/obj/crt1.o build/obj/chsys.o build/obj/chdebug.o build/obj/chtrace.o build/obj/chvt.o build/obj/chschd.o build/obj/chthreads.o build/obj/chtm.o build/obj/chstats.o build/obj/chregistry.o build/obj/chsem.o build/obj/chmtx.o build/obj/chcond.o build/obj/chevents.o build/obj/chmsg.o build/obj/chdynamic.o build/obj/chmboxes.o build/obj/chmemcore.o build/obj/chheap.o build/obj/chmempools.o build/obj/chfactory.o build/obj/chcore.o build/obj/chcore_v7m.o build/obj/osal.o build/obj/hal.o build/obj/hal_buffers.o build/obj/hal_queues.o build/obj/hal_mmcsd.o build/obj/hal_adc.o build/obj/hal_can.o build/obj/hal_crypto.o build/obj/hal_dac.o build/obj/hal_ext.o build/obj/hal_gpt.o build/obj/hal_i2c.o build/obj/hal_i2s.o build/obj/hal_icu.o build/obj/hal_mac.o build/obj/hal_mmc_spi.o build/obj/hal_pal.o build/obj/hal_pwm.o build/obj/hal_qspi.o build/obj/hal_rtc.o build/obj/hal_sdc.o build/obj/hal_serial.o build/obj/hal_serial_usb.o build/obj/hal_spi.o build/obj/hal_st.o build/obj/hal_uart.o build/obj/hal_usb.o build/obj/hal_wdg.o build/obj/nvic.o build/obj/stm32_isr.o build/obj/hal_lld.o build/obj/hal_adc_lld.o build/obj/hal_can_lld.o build/obj/hal_dac_lld.o build/obj/stm32_dma.o build/obj/hal_ext_lld.o build/obj/hal_pal_lld.o build/obj/hal_i2c_lld.o build/obj/hal_mac_lld.o build/obj/hal_usb_lld.o build/obj/hal_qspi_lld.o build/obj/hal_rtc_lld.o build/obj/hal_i2s_lld.o build/obj/hal_spi_lld.o build/obj/hal_sdc_lld.o build/obj/hal_st_lld.o build/obj/hal_gpt_lld.o build/obj/hal_icu_lld.o build/obj/hal_pwm_lld.o build/obj/hal_serial_lld.o build/obj/hal_uart_lld.o build/obj/hal_wdg_lld.o build/obj/chprintf.o build/obj/memstreams.o build/obj/nullstreams.o build/obj/syscalls.o build/obj/app_shared.o build/obj/board.o build/obj/main.o build/obj/libstdcpp.o build/obj/sys_console.o build/obj/sys.o build/obj/uavcan.o build/obj/ch.o build/obj/syscalls_cpp.o -mcpu=cortex-m4 -Wdouble-promotion -Wswitch-enum -Wfloat-equal -fno-strict-aliasing -fno-strict-overflow -Wno-implicit-fallthrough -falign-functions=16 -U__STRICT_ANSI__ -fno-exceptions -fno-unwind-tables -fno-stack-protector -fno-builtin-printf -fno-builtin-fprintf -fno-builtin-vprintf -fno-builtin-vfprintf -fno-builtin-puts -u_port_lock -u_port_unlock -u_exit -u_kill -u_getpid -uchThdExit -u__errno -fno-single-precision-constant -nodefaultlibs -lc -lgcc -lm -O0 -g3 -ffunction-sections -fdata-sections -fno-common -flto -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -nostartfiles -L./ -Wl,-Map=build/kocherga_demo.map,–cref,–no-warn-mismatch,–library-path=/ld,–script=ld.ld,–gc-sections,–defsym=__process_stack_size__=0x1000,–defsym=__main_stack_size__=0x1000 -mno-thumb-interwork -mthumb -o build/kocherga_demo.elf
1>make: arm-none-eabi-g++: Command not found
1>chibios/os/common/startup/ARMCMx/compilers/GCC/rules.mk:258: recipe for target ‘build/kocherga_demo.elf’ failed
1>make: *** [build/kocherga_demo.elf] Error 127
1>————————————————————-
1>Command exited with code 2
1>Executable: make
1>Arguments:
1>Directory: /mnt/c/Users/kentm/Documents/GITHUB/SW4STMWorkspace/kocherga-demo
1>VisualGDB : error : Command-line action failed
1>VisualGDB : error : Build has failed. See the Output window for more details.
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.MakeFile.Targets(44,5): error MSB3073: The command “”C:\Program Files (x86)\Sysprogs\VisualGDB\\VisualGDB.exe” /build “C:\Users\kentm\source\repos\kocherga-demo-linux\kocherga-demo-linux.vcxproj” “/solution:C:\Users\kentm\source\repos\kocherga-demo-linux\kocherga-demo-linux.sln” “/config:Debug” “/platform:Win32″” exited with code 1.
1>Done building project “kocherga-demo-linux.vcxproj” — FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

please read above posts before responding and answer questions posed in them.

 

 

[kentmartin99@gmail.com]

Please note.

my code exists in only one folder on one windows machine.

There are 2 paths either through WSL or windows to the same folder.

The makefile is in the root of this folder.

[support]

If you know the directory where the Makefile is located, please simply select the following:

1. Project Type: Import a project -> Import a project built with other tools
2. Source code location:
   1. The sources are located under the Linux root filesystem
   2. Source directory: the directory where you have the Makefile (Linux-style path such as /mnt/c/foo)
3. Building and debugging:
   1. Build command: make
   2. I don’t know the main executable yet.

The “Source Code Access” page is intended for setups involving Linux machines accessed via network and can be ignored when using LXSS.

We have not anticipated it to cause that much confusion and have removed it for imported Linux Subsystem projects in the following build: VisualGDB-5.5.1.3339.msi

Please try the new build, it should make the importing process very straight-forward.

[kentmartin99@gmail.com]

Hi,

Thanks,

The source code access page is required since it won’t let me complete until this is filled.

I cannot continue with your tool.

It is set by default to setup shares and mounts manually and has by defult the windows path to the source.

It however will not let me continue with this value.

Please explain

 

[kentmartin99@gmail.com]

please note the screen shots not allowing further setup if code access not setup

Attachments:

You must be logged in to view attached files.

[Author]

Posts