Error building firmware on cygwin

pheripheral · July 28, 2017, 6:43pm

I’ve finally got around to attempting to have a go at building the firmware, so that i can then start to attempt to wrote my own patch.

However have reached an error i just can’t solve when running make on cygwin
(am running windows here).

I’ve got the owlware repository downloaded from git and the submodules, and have installed the STM32 lib in the libraries folder and unzipped the ARM GNU tool into the Tools folder (and suitably updated the makefile to point to the right path (gcc-arm-none-eabi-4_8-2014q3).

When I run make from cygwin it starts to print out what looks like encouraging output:

$ make
./Tools/gcc-arm-none-eabi-4_8-2014q3/bin/arm-none-eabi-gcc -c -O2 -Wall -Wcpp -DUSE_FULL_ASSERT -D__FPU_PRESENT=1 -D__FPU_USED=1 -DEXTERNAL_SRAM  -std=gnu99 -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -I./Libraries -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/ST/STM32F4xx -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/Include -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/inc -I./Source -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/ST/STM32F4xx/Include -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/Include -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32_USB_Device_Library/Core/inc -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32_USB_Device_Library/Class/cdc/inc -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32_USB_OTG_Driver/inc -DUSE_STDPERIPH_DRIVER -DARM_MATH_CM4 -DSTM32F4XX -D__FPU_PRESENT -fno-builtin ./Source/codec.c -o Build/codec.o

but then quickly hits the error i can’t get past:

arm-none-eabi-gcc.exe: error: CreateProcess: No such file or directory
Makefile.common:46: recipe for target &#039;Build/codec.o&#039; failed
make: *** [Build/codec.o] Error 1

Have done some digging and found an article on the gnu arm tools site about it having problems running in cygwin specifically when attempting to deal with cygwin style paths, link to issue and link to bug
I don’t know if this is the issue and therefore it just won’t work for me at the moment until they fix this or if its somehting else.
the makefiles are all using relative paths so this path thing may not be the problem…

Any help very much appreciated…

sgissinger · July 28, 2017, 6:43pm

Does your full path to OwlWare folder contains space characters ?
If yes, try to avoid them like this D:\GitHub\OwlWare (mine)

If not, does your gcc-arm-none-eabi-4_8-2014q3 folder follows the structure

OwlWare\Tools\gcc-arm-none-eabi-4_8-2014q3
OwlWare\Tools\gcc-arm-none-eabi-4_8-2014q3\arm-none-eabi
OwlWare\Tools\gcc-arm-none-eabi-4_8-2014q3\bin
OwlWare\Tools\gcc-arm-none-eabi-4_8-2014q3\lib
OwlWare\Tools\gcc-arm-none-eabi-4_8-2014q3\share

I only start cygwin normally and then change dir to my OwlWare folder cd d:, cd GitHub, cd OwlWare and then do make

pheripheral · July 28, 2017, 6:43pm

my path to owlware is similar to yours D:\Owl\OwlWare and the gcc structure looks the same.

i start cygwin terminal and then navigate to the OwlWare folder in the same way
cd d:, cd Owl, cd Owlware and then make.

have also tried adding the D:\Owl\OwlWare\Tools\gcc-arm-none-eabi-4_8-2014q3\bin into my path but it makes no difference.

mars · July 28, 2017, 6:43pm

Yes the relative paths should be safe for cygwin.

If you copy the path to gcc out to the command line: ./Tools/gcc-arm-none-eabi-4_8-2014q3/bin/arm-none-eabi-gcc - do you get a gcc error, e.g.
arm-none-eabi-gcc: fatal error: no input files

In other words, is the path valid?

You could perhaps try setting TOOLROOT in Makefile.common to the absolute bin path, though I’m not sure why that would make a difference…

Oh, hold on, do you have a Build directory? If not then mkdir Build!

pheripheral · July 28, 2017, 6:43pm

…99% sure i had a Build directory under OwlWare but i’ll check…

will also try the cmd lin path test and perhaps the absolute TOOLROOT

prob won’t be able to have another go at this until thurs eve so will post my results then.

Thanks

pheripheral · July 28, 2017, 6:43pm

have checked the path via grabbing the ./Tools/gcc-arm-none-eabi-4_8-2014q3/bin/arm-none-eabi-gcc to the cmd line and get the error you mention:

arm-none-eabi-gcc.exe: fatal error: no input files
compilation terminated

so i guess this means it is finding the gcc bin.

There was and is a Build directory under OwlWare (containing only the .gitignore file)

i did notice the end of the makefile has ./Source/codec.c but then -o Build/codec.o where the BUild bit does not have the ./ in front of it

so i tried adding this and rerunning but still get the same
arm-none-eabi-gcc.exe: error: CreateProcess: No such file or directory

error as normal

pheripheral · July 28, 2017, 6:43pm

also i’m using Windows Vista if that has any bearing on things…

have thought of a few stupid questions, just to check some of my assumptions:

the pedal doens’t need to be connected to the computer when running make does it?
i don’t need to install any other compilers or anthing do I?
i.e. are the instructions on the readme everything that’s needed?

i took the part where it said that
"To build and deploy the project using the provided Makefiles you will need some version of the make utility, for example GNU make.

For Windows users, we recommend installing Cygwin."

to mean for windows users you only need cygwin ? and not GNU make (think its non windows anyway).

Also i’ve not got st-utli or dfu-util, but i think they are only needed for connecting to the pedal rather than compiling the code?
when installing cygwin i had to run it a second time because the first time it seems i hadn’t selected to specifically install the make part of it. Are there are other bits of cgywin i may have not installed that i need to?

mars · July 28, 2017, 6:43pm

Your assumptions are correct and no, you shouldn’t need anything else from cygwin.

Could it be that you are invoking a different version of make? Have you other cross-compilers or similar tools installed, e.g. CodeSourcery, WinAVR?

What happens if you do ‘make clean’, any errors?

What if you run the entire command as specified by Make, i.e.
./Tools/gcc-arm-none-eabi-4_8-2014q3/bin/arm-none-eabi-gcc -c -O2 -Wall -Wcpp -DUSE_FULL_ASSERT -D__FPU_PRESENT=1 -D__FPU_USED=1 -DEXTERNAL_SRAM -std=gnu99 -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -I./Libraries -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/ST/STM32F4xx -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/Include -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/inc -I./Source -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/ST/STM32F4xx/Include -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/Include -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32_USB_Device_Library/Core/inc -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32_USB_Device_Library/Class/cdc/inc -I./Libraries/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32_USB_OTG_Driver/inc -DUSE_STDPERIPH_DRIVER -DARM_MATH_CM4 -DSTM32F4XX -D__FPU_PRESENT -fno-builtin ./Source/codec.c -o Build/codec.o

I’m sorry you’re having such problems. It’s usually quite straightforward, even on Windows!

I’ve found similar reports here [1], here[2] and here [3], not sure the proposed solutions are relevant for you though it might be worth having a look.

[1] Question #227124 : Questions : GNU Arm Embedded Toolchain
[2] http://hertaville.com/2012/05/28/gcc-arm-toolchain-stm32f0discovery/
[3] http://stackoverflow.com/questions/3848357/createprocess-no-such-file-or-directory

pheripheral · July 28, 2017, 6:43pm

I’ve not got any other make things installed - have never tried to ‘make’ anything before. not played with c++ etc… on this machine before.

running ‘make clean’ doesn’t return any errors, just a rm -f command with a whole heap of Build/<filename>.o and ./Build/<filename>.o and then Build/<filename>.s and ./Build/<filename>.s files, then ending in gdbscript

I assume this looks right

if i just run the command that make generate directly i get the same CreateProcess error

I’ll investigate the links (although had seen 1 and 3 before).

else my next thought is to try it in a VM on my machine…

mars · July 28, 2017, 6:43pm

OK so I think that rules out problems with Make, and points the finger at gcc-arm.
Did you install it from here?
https://launchpad.net/gcc-arm-embedded
Could you try downloading and running their Windows installer?

pheripheral · July 28, 2017, 6:43pm

hi, yep i obtained the gcc from that website.

have now tried it again via the exe installer rather then just unzipping the zip and afraid we end up with the same error message. (once makefile.common altered to point to the installed gcc rather than the unzipped one)

mars · July 28, 2017, 6:43pm

Argh! Really sorry it’s such a hassle - I can’t think what might be wrong!

We’re soon unveiling some drastic changes to the build process and will eventually have an online compiler. I understand that doesn’t help you right now though.

You don’t use VirtualBox or VMWare or similar do you? If so you could build in a Linux virtual machine.

mars · July 28, 2017, 6:43pm

I’ve just managed to build on a new Windows 8.1 machine as follows:

download OwlWare and dependencies [1]
run cygwin installer and select the make package [2]
run the exe installer of gcc-arm [3]
edit Makefile.common (in OwlWare) to set TOOLROOT to the absolute path of the gcc-arm bin directory, e.g.
TOOLROOT=/cygdrive/c/Program\ Files\ (x86)/GNU\ Tools\ ARM\ Embedded/4.8\ 2014q3/bin/
(spaces and parenthesis must be preceded by backslash)
open a cygwin window, cd to your OwlWare directory, and run make

[1] GitHub - pingdynasty/OwlWare: Firmware for the OWL programmable effects pedal
[2] Cygwin Installation
[3] GNU Arm Embedded Toolchain in Launchpad

pheripheral · July 28, 2017, 6:43pm

Hi,
sorry not replied sooner to your previous message
I was about to say that yes I do have access to VMWare so would be able to try it in a VM and / or attempt to setup a linux VM to see how far I got.

But your new windows discovery with the path changes suggest I should try that first and I should be able to do that this weekend…

Many Thanks for persisting with the hunt for a solution for this - Will report back…

pheripheral · July 28, 2017, 6:43pm

ok have tried again
attempts to install gcc form the exex and then edit the path in the makefile to have the backslahses by spaces etc… did not fix my issue - same error message frustratingly.

BUT
I found an old XP VM lying around and installed cywin and make on this and then pointed at base machine (i.e i did not move any of the owlware code or gcc stuff to the Vm) and then ran make on the vm XP machine and finally the make proceeds ok and spits out the glorous message:

“Successfully built OWL firmware Build/OwlWare.bin”

and this was even using the plain toolroot path of $(TEMPLATEROOT)/Tools/gcc-arm-none-eabi-4_8-2014q3/bin

so i’m putting down my problem to some general lurking evil in my old and crowded Vista machine rather than anything actually obviously wrong with the setup / paths etc…

Thanks for all the help.
Next step - try and add patch to my firmware sucessfully, but that is for another day, as i’m stopping fiddling for now while i’m ahead…