MK3 compilation issue with Arduino 1.8.x

[murphy2712]

I was previously able to compile the MK3 firmware with Arduino 1.8.5 but recently it fails with this error message:

Marlin_main.cpp:2414: error: unrecognizable insn:
...

I was able to revert to a previous commit which worked fine, the failure starts from this commit:
67e90b5

I was able to pinpoint to this change:

-//#define DBG(args...) printf_P(args)
-#define DBG(args...)
+#define DBG(args...) printf_P(args)
+//#define DBG(args...)

Up until this commit no issue to compile (Arduino 1.6.12 or 1.8.5), but since this change, it fails.
I was even able to compile (and flash :P) the up-to-date MK3 branch by reverting these 2 lines.

Please revert these lines (or find a better fix!).
Thanks!

PS: I posted more details on this forum post: https://shop.prusa3d.com/forum/others-archive--f66/compiling-mk3-firmware-t15404-s10.html
I'm using macOS High Sierra (not sure if related).

[rcfsguy]

I resolved this problem by commenting out the DBG lines in xyzcal.cpp. There is one line in particular that is the offender, but I cannot remember the exact one so I just commented all of them. I was using Arduino 1.8.5 on Mac High Sierra.

[murphy2712]

Yes this is what I did (cf the diff), the issue is exactly this line:

#define DBG(args...) printf_P(args)

[mcstoufer]

I can confirm that reverting the change noted by murphy above will compile on 1.6.12 just fine. Surprised how fast it goes w/o errors. Was the printf_P() function not implemented in Sierra anymore?

[GurliGebis]

What OS it is running on shouldn't matter, since it is the Arduino headers that are used.
Looks more like printf_P is undefined, which should be the case for everyone using the same version of the Arduino IDE, since that defines which headers are used.

[Crunch69]

it is strongly recommended to use older version "1.6.8", by which we can assure correct compilation results
note: in versions 1.7.x and 1.8.x there are known some C/C++ compilation disasters, which disallow correct source code compilation

[3d-gussner]

I use IDE 1.8.x since a while and had never issues, even saw that Prusa used newer versions than 1.6.8 in the past.
Since a lot of code cleanup by multiple persons like #138 in the MK2 branch i could compile it with any warnings (IDE debug mode set to 'More').
These code cleanups never made it to the splittend MK3/MK25 branches and now old warnings are still in these branches and makes it difficult to see if new code is good.

Just tested IDE 1.68 with newest Release Source.zip https://github.com/prusa3d/Prusa-Firmware/archive/v3.2.0-RC1.zip and get the same error as in IDE 1.8.5

[thess]

The issue reported by the OP is a problem in the avr-gcc compiler/linker in the Arduino IDE package (avr-gcc v4.9.2). The same GCC version is in both 1.6.x and 1.8.x IDE packages. The problem can be worked-around by removing the "link-time-optimization" (-flto) options from the build flags.

The compiler options live the in <ide-root>/hardware/arduino/avr/platform.txt
Make a backup copy of this file, then edit the line beginning with: compiler.cpp.flags= to remove the -flto option. You should now be able to compile the MK3 firmware with all the usual warnings (bleh!).

PS - I do not have an MK3 to test the result on, so caveat user.

[Crunch69]

I found it you are running the windows version and delete everything in the arduino folder including platform.txt then rerun 1.6.8 then add the missing additions to hardware and libraries everything works perfect. I have had compiling errors if I ran 1.6.8 then updated to a higher arduino versions on the same pc after deleting the folder and then running fresh all of my compiling errors vanished.

[murphy2712]

@Crunch69 I would love to build with "official 1.6.8" but have this error when compiling:

failed MSpanList_Insert 0x30b000 0x17daaa0a1a48f 0x0
fatal error: MSpanList_Insert
runtime stack:
runtime.throw(0x2ac50b)
...
arduino-builder returned 2
Error compiling for board RAMBo.

I tried to remove all the app preferences and to use just Arduino 1.6.8 but same error.

Any idea how to fix?

[murphy2712]

This seems to be an Arduino issue with OSX Sierra, fixed in later Arduino releases (1.6.12+).
https://forum.arduino.cc/index.php?topic=423094.0
arduino/Arduino#5374 (comment)
arduino/Arduino#5360

It seems we can't officially use an old Arduino version forever.

[XPila]

hello guys, problem is in compiler version, please use recomended version Arduino 1.68 and avr-gcc 4.8.1. More details in build instructions.

[murphy2712]

@XPila How can we force to use avr-gcc 4.8.1? I don't see any mention in https://github.com/prusa3d/Prusa-Firmware
Thanks!

[Crunch69]

murphy2712 that appears to be a MacOs issue are you on a mac? I provided instructions for a PC

Can we close this as it is not an issue with the Firmware

[murphy2712]

Yes, I'm on OSX.
However, I disagree with closing this issue: on OSX it seems it is only possible to build this MK3 firmware with Arduino 1.8.5 AND this #620 fix.
In my opinion, to close this issue we either need to:

• fix OSX build possibility on 1.6.8 (and continue to discourage use of other recent Arduinos)
  or
• use Fix compilation issue with recent Arduino #620 fix and restore the ability to build with Arduino 1.8.5

[stahlfabrik]

Agree: not being compatible with the latest Arduino is one thing, but not compile on macOS is a nogo.

I compiled happily 3.1.3 on macOS and it worked perfectly - with the latest Arduino IDE. Now this is a regression that needs to be fixed.

[maximlevitsky]

Note that I could compile the git head of MK3 branch using arduino 1.8.5 (avr gcc version 4.9.2) with this change:

diff --git a/Firmware/xyzcal.cpp b/Firmware/xyzcal.cpp
index 9eb58fd..f12e25c 100644
--- a/Firmware/xyzcal.cpp
+++ b/Firmware/xyzcal.cpp
@@ -30,7 +30,7 @@

#define _PI 3.14159265F

-extern long count_position[NUM_AXIS];
+extern volatile long count_position[NUM_AXIS];

uint8_t check_pinda_0();
uint8_t check_pinda_1();

In my humble opinion, if a variable is declared volatile in one file, it should be declared as such in all files the 'extern' it so that compiler which uses it doesn't apply extra optimizations.

[maximlevitsky]

I must add also that I don't yet own the MK3 or any 3D printer if this matters, so I couldn't test if the result will actually work.

The output from arduino was:

Archiving built core (caching) in: /tmp/arduino_cache_849250/core/core_rambo_avr_rambo_09ff688e17cfe342a76c80acd8dcdce5.a
Linking everything together...
"/opt/arduino-1.8.5/hardware/tools/avr/bin/avr-gcc" -Os -g -flto -fuse-linker-plugin -Wl,--gc-sections,--relax -mmcu=atmega2560 -o "/tmp/arduino_build_427020/Firmware.ino.elf" "/tmp/arduino_build_427020/sketch/adc.c.o" "/tmp/arduino_build_427020/sketch/sm4.c.o" "/tmp/arduino_build_427020/sketch/spi.c.o" "/tmp/arduino_build_427020/sketch/BlinkM.cpp.o" "/tmp/arduino_build_427020/sketch/ConfigurationStore.cpp.o" "/tmp/arduino_build_427020/sketch/Dcodes.cpp.o" "/tmp/arduino_build_427020/sketch/Firmware.ino.cpp.o" "/tmp/arduino_build_427020/sketch/LiquidCrystal_Prusa.cpp.o" "/tmp/arduino_build_427020/sketch/MarlinSerial.cpp.o" "/tmp/arduino_build_427020/sketch/Marlin_main.cpp.o" "/tmp/arduino_build_427020/sketch/MenuStack.cpp.o" "/tmp/arduino_build_427020/sketch/Sd2Card.cpp.o" "/tmp/arduino_build_427020/sketch/SdBaseFile.cpp.o" "/tmp/arduino_build_427020/sketch/SdFatUtil.cpp.o" "/tmp/arduino_build_427020/sketch/SdFile.cpp.o" "/tmp/arduino_build_427020/sketch/SdVolume.cpp.o" "/tmp/arduino_build_427020/sketch/Servo.cpp.o" "/tmp/arduino_build_427020/sketch/Timer.cpp.o" "/tmp/arduino_build_427020/sketch/cardreader.cpp.o" "/tmp/arduino_build_427020/sketch/cmdqueue.cpp.o" "/tmp/arduino_build_427020/sketch/fsensor.cpp.o" "/tmp/arduino_build_427020/sketch/language_all.cpp.o" "/tmp/arduino_build_427020/sketch/mesh_bed_calibration.cpp.o" "/tmp/arduino_build_427020/sketch/mesh_bed_leveling.cpp.o" "/tmp/arduino_build_427020/sketch/motion_control.cpp.o" "/tmp/arduino_build_427020/sketch/pat9125.cpp.o" "/tmp/arduino_build_427020/sketch/planner.cpp.o" "/tmp/arduino_build_427020/sketch/qr_solve.cpp.o" "/tmp/arduino_build_427020/sketch/stepper.cpp.o" "/tmp/arduino_build_427020/sketch/swi2c.cpp.o" "/tmp/arduino_build_427020/sketch/swspi.cpp.o" "/tmp/arduino_build_427020/sketch/temperature.cpp.o" "/tmp/arduino_build_427020/sketch/tmc2130.cpp.o" "/tmp/arduino_build_427020/sketch/ultralcd.cpp.o" "/tmp/arduino_build_427020/sketch/util.cpp.o" "/tmp/arduino_build_427020/sketch/vector_3.cpp.o" "/tmp/arduino_build_427020/sketch/xyzcal.cpp.o" "/tmp/arduino_build_427020/core/core.a" "-L/tmp/arduino_build_427020" -lm
"/opt/arduino-1.8.5/hardware/tools/avr/bin/avr-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 "/tmp/arduino_build_427020/Firmware.ino.elf" "/tmp/arduino_build_427020/Firmware.ino.eep"
"/opt/arduino-1.8.5/hardware/tools/avr/bin/avr-objcopy" -O ihex -R .eeprom "/tmp/arduino_build_427020/Firmware.ino.elf" "/tmp/arduino_build_427020/Firmware.ino.hex"
Sketch uses 240736 bytes (93%) of program storage space. Maximum is 258048 bytes.
Global variables use 6514 bytes of dynamic memory.

[EeroFluge]

maximlevitsky has the right fix to this problem.
extern volatile is needed for long count_position[NUM_AXIS];

I successfully compiled the Mk3 firmware with Arduino 1.8.5 and avr-gcc\4.9.2 on Windows 10 with this simple addition of volatile to line 33 of xyzcal.cpp.

[AYapejian]

Just a note, I use platformio and visual studio code to compile firmware and concur with @EeroFluge , adding volatile as noted allows compilation by running pio run with the following platformio.ini project definition:

;
;   Build options: build flags, source filter
;   Upload options: custom upload port, speed and extra flags
;   Library options: dependencies, extra library storages
;   Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; http://docs.platformio.org/page/projectconf.html
[platformio]
src_dir = Firmware
build_dir = .out

[env:reprap_rambo]
platform = atmelavr
board = reprap_rambo
framework = arduino

[murphy2712]

I agree that adding this volatile keyword is a valid alternative to have compilation working for me.

[maximlevitsky]

@XPila Any update on this? I am just curious if this is the correct fix for this issue.

[stahlfabrik]

+1 that volatile keyword fixes the compilation.

I just stumbled again across the fact that Arduino 1.6.8 does not work on Mac OS High Sierra at all. It does not compile - it is a know issue that got fixed later.

[maximlevitsky]

@XPila sorry to bother you , but any update?

[Zaf9670]

Just updating that I successfully compiled RC 3.4.0-RC1 on 1.8.5 Windows Store 1.8.10.0. I haven't tried flashing at this time but I wanted to see if all the recent commits helped/worked.