Apologies if I’m not asking this in the right place.
I had been successfully building 3D printer firmware at the previous revision level. The latest version is failing with errors however, and I don’t know how to fix it.
This is the source code I can build just fine with no errors:
This is the latest version that throws errors when I try to build:
Here is the output when I attempt to build:
Executing task: C:\Users\teook\.platformio\penv\Scripts\platformio.exe run <
Processing reprap_rambo (platform: atmelavr; board: reprap_rambo; framework: arduino)
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelavr/reprap_rambo.html
PLATFORM: Atmel AVR 1.15.0 > RepRap RAMBo
HARDWARE: ATMEGA2560 16MHz, 8KB RAM, 252KB Flash
PACKAGES: toolchain-atmelavr 1.50400.190710 (5.4.0), framework-arduinoavr 4.1.2
Converting Firmware.ino
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 14 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <Wire> 1.0
Compiling out\reprap_rambo\src\Firmware.ino.cpp.o
Linking out\reprap_rambo\firmware.elf
wiring.c.o (symbol from plugin): In function `__vector_23':
(.text+0x0): multiple definition of `__vector_23'
out\reprap_rambo\src\heatbed_pwm.cpp.o (symbol from plugin):(.text+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
*** [out\reprap_rambo\firmware.elf] Error 1
Thank you for the extremely detailed reply. I deserved the admonishment to google first…
It worked! And just for the record, even if I had googled and found the existing issue threads in the project I wouldn’t have know how to force PIO to play nice with the altered board and core definitions. So thanks for spelling it all out for me.
Ah, I’m glad people who actually know what they are doing are working this issue.
I will qualify my earlier “it works!” statement however by noting that the UI is funky with firmwares built with this method. The printer functions properly, but the LCD screen UI is not filling in with all the information it normally would.
So, we are getting closer but not quite there yet.
Hm interesting info because the exact same problem is described in the PR… What exact config are you having on your build and what hardware LCD device do you have?
[env:reprap_rambo]
monitor_speed = 115200
platform = atmelavr
board = reprap_rambo
framework = arduino
build_flags = -w -Os -Wl,-u,vfprintf -lprintf_flt -lm -Wl,--gc-sections
;required now that prusa have modified rambo
board_build.core = rambo
[platformio]
src_dir = Firmware
build_dir = out
Here is a drop in replacement for the standard LCD. Unfortunately it does not list any of the specs. I think it’s just a standard 4 line interfacing with I2C.
And this might be releated? PIO is flagging several problems in the LCD code but we are in way over my head at this point already…
First message indicates a problem with the return value of the function, second one is more interesting because it tells you that there’s an overflow for to-be-fitted data compared to the available space. This commit seems to address it. Do you have a version of the firmware where these changes are applied?
Also can you show a comparison of how the LCD looks like correctly with Arduino IDE with PIO?
Seems like we don’t copy the right variant .h file as the script does
if [ ! -f "$SCRIPT_PATH/Firmware/Configuration_prusa.h" ]; then
cp $SCRIPT_PATH/Firmware/variants/1_75mm_MK3-EINSy10a-E3Dv6full.h $SCRIPT_PATH/Firmware/Configuration_prusa.h || exit 8
fi
Can you replace the Configuration_prusa.h file found in the firmware prject with the .h file for the MK3 and recompile?
The LCD should work regardless of the printer variant.
The fact that it’s compiling for MK3 in Ubuntu is I think a different issue and is probably user error. I have the MK3S variant file selected in both cases. I just haven’t figured out why the build.sh seems to ignore it (never used it until today while trying to troubleshoot building in PIO).
I can flash the official firmware for either MK3 or MK3S and the screen displays correctly in both cases.
Should work or does work is important here. Can you compile the MK3S variant with the build.sh (overwriting Firmware/Configuration_prusa.h with the config file for the MK3S and then executing build.sh should be enough) so that we can get a picture on what the MK3S firmware is supposed to look like correctly?
This is a regression issue with the extended undergoing optimizations at the PR Marlin.
I've reported it and they acknowledged it, but they haven't fixed it yet.
If I understand correctly, it depends on the optimizations that the compiler chooses.
To fix this do the following changes:
At the lcd.cpp, at line ~192 change the whole function:
static void lcd_putchar(char c, FILE *)
with:
static int lcd_putchar(char c, FILE *)
{
lcd_write(c);
return 0;
}
and at the lcd.h, the definition:
extern void lcd_putchar(char c, FILE *stream);
with:
extern int lcd_putchar(char c, FILE *stream);
I made the suggested edits, and the UI now displays correctly when building with platformIO.
But I didn’t think it would be that severe. In hindsight, if the compiler expects an int as the return value it will pop a value from the stack after calling the function, however corrupting the stack if there is no such value pushed by the function. Or just undefined behavior. Case closed then I guess.
reprap_rambo board will use the wrong core. The ‘arduino’ core defines the TIMER0 and it’s redefined in the Prusa Firmware code; so build error. That’s why I pushed a PR with a new ‘rambo’ core and new ‘prusa_rambo’ board for building Prusa Firmware.
There is a special change in the wiring.c file linked to the fact that the Prusa firmware has its own TIMER0 implementation. And what about other rambo boards based on reprap that still needed the TIMER0 ?
