region `flash' overflowed by 933 bytes
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
make: * [px4fmu-v2_default] Error 1
Please use the recommended arm-none-eabi GCC version.
arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
It worked the last few months and all other targets build perfect,
did the recommended Version change and a newer is needed now?
In the CI GCC 7 is used and I would suggest that you should also use that one for the build. You can download it here.
Could we have the build instructions updated to reflect this? I am running into the exact same issue as taileron but with 1881 bytes overflowed. Running Ubuntu 16 btw.
@sparky002 yes, will do.
@hamishwillee
For me on Mac 10.12.6 GCC 7.2.1 doesn´t work at all (various errors). GCC 5.4.1 runs perfect expect for V2_default targets (several bytes overflowed)
I tried to narrow down a temporary fix for still using GCC 5.4.1 and building V2_default. Here are my findings.
For example, if i comment out say, "modules/vtol_att_control" in the nuttx_px4fmu-v2_default.cmake file located in "~/src/Firmware/cmake/configs/" , the firmware builds successfully. I don't have a previous version of the firmware saved locally right now to compare the cmake files but maybe the newer firmware had an extra module or two slip in that were supposed to be commented out for the V2_default? Not sure though.
@mhkabir what is the recommended GCC version? The devguide has several mentions of 5.4.1 and this has been the stable choice for a while so I doubt we have moved on yet, right?
I have the same problem.
Hi guy! You should use "make px4fmu-v3_default" to your device. Your isn't Pixhawk 1, but is mRo Pixhawk. You can see https://dev.px4.io/en/setup/building_px4.html.
@julianoes you can see above answer!
@black2sky no I have older Pixhawks where I can only flash 1 MB, so I need px4fmu-v2_default.
@julianoes 1.7.3 is change! You can see https://dev.px4.io/en/setup/building_px4.html
@julianoes The following list shows the build commands for common boards:
Pixhawk 1: make px4fmu-v2_default
HKPilot32: make px4fmu-v2_default
Pixfalcon: make px4fmu-v2_default
Dropix: make px4fmu-v2_default
mRo Pixhawk: make px4fmu-v3_default (supports 2MB Flash)
mRo X-2.1: make auav-x21_default
Pixhawk 2: make px4fmu-v3_default
Pixracer: make px4fmu-v4_default
MindPX/MindRacer: make mindpx-v2_default
Pixhawk Mini: make px4fmu-v3_default
Pixhawk 3 Pro: make px4fmu-v4pro_default
Crazyflie 2.0: make crazyflie_default
Intel® Aero Ready to Fly Drone: make aerofc-v1_default
Pixhawk 4: make px4fmu-v5_default
AUAV-X2 (Discontinued): make px4fmu-v2_default
@julianoes mRo Pixhawk: make px4fmu-v3_default (supports 2MB Flash)
@julianoes your device is mRo Pixhawk, in 1.5.4 is make px4fmu-v2_default, but int 1.7.3 is px4fmu-v3_default
@julianoes you can see tht git log. you will see
commit 01691e626bcae674a6b36a9ee0c6053fe7f52565
Author: Daniel Agar daniel@agar.ca
Date: Wed Nov 22 23:56:13 2017 -0500
Merge FMUv3 into FMUv2
@julianoes your device is mRo Pixhawk
No, my devices are mostly Pixhawk 1 by 3DR, probably from 2013/2014.
check your devices
@julianoes
Pixhawk 1:
Main System-on-Chip: STM32F427
CPU: 180 MHz ARM Cortex M4 with single-precision FPU
RAM: 256 KB SRAM (L1)
Failsafe System-on-Chip: STM32F100
CPU: 24 MHz ARM Cortex M3
RAM: 8 KB SRAM
@julianoes
mRo Pixhawk Flight Controller (Pixhawk 1)
Microprocessor:
32-bit STM32F427 Cortex M4 core with FPU
168 MHz/256 KB RAM/2 MB Flash
32 bit STM32F103 failsafe co-processor
@julianoes your also can see the old version "cmake/configs/nuttx_px4fmu-v2_default.cmake". There have setting that flash to 2M.
@black2sky my Pixhawk 1s have the silicon errata and therefore only safely support 1MB:
MCU: STM32F42x, rev. Y
WARNING WARNING WARNING!
Revision Y has a silicon errata:
This device can only utilize a maximum of 1MB flash safely!
https://pixhawk.org/help/errata
That's why the target px4fmu-v2_default exists.
@julianoes I have to say that is wrony! Because I have make px4fmu-v3_default upload! I also have your log.
This device can only utilize a maximum of 1MB flash safely!
You can flash more than 1MB using px4fmu-v2_default on a device with silicon errata but you might with little chance run into problems. So one log doesn't prove anything.
@julianoes I have seen your bug px4fmu-v2 vs px4fmu-v3 confusion #8809! Your devices in the picture is same to my device! I have open the device and find that ailsafe co-processor is STM32F103, not the STM32F100. One of difference bettwen Pixhawk 1 and mRo Pixhawk is chip! So I think your device is mRo Pixhawk .
@julianoes I also think that the log "This device can only utilize a maximum of 1MB flash safely!" is not-fixed bug yet !
@black2sky I have worked for 3DR and co-developed Pixhawk, I know which one I have.
And it is a hardware silicon bug so not a software bug.
@julianoes OK! You are right ! I didn't know you are co-developer! haha“^_^”
I feel like this has gotten off the subject matter of not being able to build the px4fmu-v2_default firmware successfully. Any further development into getting this to build properly?
@dagar What GCC are we running on CI currently?
We're using GCC 7, the current latest GNU Arm Embedded Toolchain.
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
Updating the documentation has taken longer than expected because we're putting some pieces in place to keep the documentation, containers, and CI build environment completely in sync.
is there an easy way to get rid of these errors:
arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]
with gcc 7.2.1 it doesn´t compile at all:
FAILED: NuttX/nuttx/mm/libmm.a
cd /Users/ahuber/src/Firmware/build/px4fmu-v4_default/NuttX/nuttx && find mm -type f -name .o -delete && make -C mm --quiet --no-print-directory libmm.a TOPDIR=/Users/ahuber/src/Firmware/build/px4fmu-v4_default/NuttX/nuttx KERNEL=n EXTRADEFINES= >nuttx_build.log
arm-none-eabi-gcc: error trying to exec 'cc1': execvp: No such file or directory
make[1]: [bin/mm_initialize.o] Error 1
ninja: build stopped: subcommand failed.
make: * [px4fmu-v4_default] Error 1
Is there anything we can scrapt from v2 to free some flash space?
@julianoes there are a few minor drivers we could drop, but we're mainly hurting users at this point by stripping it down further. I'd like to focus on cutting out some of the bloat instead. For example this PR saves more than enough to fit with the older compilers and gives us some breathing room. https://github.com/PX4/Firmware/pull/8466
@taileron FYI, re https://github.com/PX4/Firmware/issues/8773#issuecomment-363508948 I did not get build errors with px4fmu-v2_default or px4fmu-v2_default on latest master using GCC7. The developer environment setup (in progress) is https://github.com/PX4/Devguide/pull/452
I can agree with @hamishwillee . I did not get build errors anymore with px4fmu-v2_default on the latest master using GCC7. I ran the new build-script just to be sure.
@dagar I agree, removing bloat seems what we should aim for.
now it works with GCC 7.2.1 as soon as the whole toolchain is replaced and all paths are correct so even v2_default builds perfect without memory overflows
@taileron I still think we can't force everyone on GCC 7.2.1 just yet.
By the way, will it still be possible to compile a tagged 1.6.5 version with GCC 7.2.1 ?
It can be done with an additional static system path to the GCC by copying the suitable whole toolchain substructure into it. For some other projects I need GCC 6.3.1 so I have to change between the versions anyway.
By the way, will it still be possible to compile a tagged 1.6.5 version with GCC 7.2.1 ?
@dagar How, and how far back, do/can we support people who want to work on older versions of PX4. Specifically, I just updated docs to GCC7.2.1 - will that work for building earlier versions? We should probably state at which version the toolchain is known to work in the docs and ideally link back to earlier version of docs for earlier setup.
Thoughts?
I don't have a good answer for that. As we go forward and have nearly everything tagged to specific docker container versions we can at least provide them with a good environment.
in some other projects it´s done like this (wrong GCC displays an error notification):
make/tools.mk:296: * **ERROR your arm-none-eabi-gcc is '7.2.1', but '6.3.1' is expected. Override with 'GCC_REQUIRED_VERSION' in make/local.mk or run 'make arm_sdk_install' to install the right version automatically in the tools folder of this repo. Stop.
... sorry, closed it accidentally
Was this resolved?
Compiles for me with arm-none-eabi-gcc version 5.4.1.
with the current master fmu-v2 compiles perfect with both GCC - so finally it is really solved
currently I´m using a fixed visible system path by copying the desired GCC folder structure into for changing GCC versions on the fly
But which is now the better/recommended one to work with 7.2.1 or 5.4.1 ?
I´m using GCC 6.3.1 for other projects and that compiles it as well
@mhkabir @hamishwillee @julianoes @taileron
Hello, sorry for re-open this topic but I'm in trouble whith gcc compiler while trying to build px4 code
As reported in https://dev.px4.io/en/setup/building_px4.html, I must have a supported GCC version to build make px4fmu-v2_default. I've followed the instructions in https://dev.px4.io/en/setup/dev_env_linux_ubuntu.html#nuttx-based-hardware, I've executed the script GCC 7-2017-q4 and reboot my computer. However, I still have arm-none-eabi-gcc 4.9.3 when I check the version (instead of version 7.2.1 as reported in the docs).
I've noticed that when executing sudo apt-get remove gcc-arm-embedded I got the following:
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package gcc-arm-embedded
Does anyone has suggestions on how to fix it?
Thank-you in advance
@matteoscanavino Please don't hijack old issues. Repost with your symptoms, including information like what OS you are running on etc etc. If you think a closed issue like this is relevant then link to it.
Most helpful comment
@matteoscanavino Please don't hijack old issues. Repost with your symptoms, including information like what OS you are running on etc etc. If you think a closed issue like this is relevant then link to it.