PlatformIO Community

Cannot compile a useable Marlin 2.0 firmware

I’m new to PlatformIO, and I’m struggling on where to turn for help on this issue. I’ve downloaded several source codes for firmware builds for my 3D printer. Every one I’ve compiled has generated a firmware.bin file which when flashed to my printer results in a bricked printer. I get a blank lit blue LCD control panel, and it is simply unresponsive.

Here’s an example of one user who uploaded a firmware.bin file and his source. His firmware.bin file flashes to the printer fine, unless I compile it on PlatformIO. I’ve followed several tutorials on YouTube on usage of PlatformIO. Some use Atom, others VSCode as the shell to run PIO under. I’ve tried both platforms, both yield useless firmware.bins.

I’ve noticed in the YouTube videos that the PIO core # was older. Is it possible the newest core is inducing an error? If so how do I attempt an older build of PIO?

Or any other suggestions as what to do? I’ve run fc (file compare) against my bins vs. the supplied bins, and the files are the same size but have an oddly similar pattern in mixed HEX values during the file compare.

Thanks for your support.

Well these are the PIO build-system support forums but we’ve got such a massive amount of threads of people needing help for their 3D printer software, in particular Marlin, that it doesn’t make a difference, and we’re glad to help.

First of all we’d need to know which exact 3D printer model you have, and which firmware you’re attempting to compile for it, then what platformio.ini you’ve overridden, and how you’re running PIO to compile and upload the firmware.

1 Like

Hey maxgerhardt, thanks for your reply.

First off I’m using a Creality Ender3 printer. I’ve replaced the motherboard with a SKR v1.2 board with 2209 TMC drivers preinstalled. Here’s the support page for the board.

The board came loaded with Marlin 2.0, and works great. I’ve also added a bltouch probe which must be configured within the firmware.

Here’s a link to one of the more accessible firmwares I’m attempting to compile.

Within the CompiledFirmware folder, there is a firmware.bin file which when loaded to an SD card and inserted to my printer, the printer will flash the firmware.bin, rename to a firmware.cur, and it boots fine.

What I’m doing is downloading the above source code, using Open Folder in PlatformIO and pointing it to the root directory of the source package. I open that way, then click the build check mark. Without any mods to the downloaded source I open in PIO, then compile.

It produces a firmware.bin within the .pio folder, and a few subfolders. I dump that onto my SD card and load into the printer. It never boots, but the LCD screen just stays lit and blank, and attempting to connect via OctoPrint (RPi terminal USB connected to the mainboard) yields that there is nobody home in the printer. The firmware.bin does get renamed to firmware.cur as normal, but until I reload a known good firmware my printer is useless. In (my) theory I should be able to load the source folder (the Github download is unpacked into Vanilla Firmware folder and that’s the folder I load with PIO), click the build check mark, and it should produce a firmware.bin identical to the one in CompiledFirmware folder. (The firmware.bin that the source provider guy already made from the same code)

I’ve never modified the platformio.ini file, it is unchanged from the GitHub download.

1 Like

Also, I tried the same on the SKR v1.2 GitHub source files. Same result, when I build the firmware.bin it compiles ok, but bricks the printer. Their included firmware.bin flashes & works fine. Same result on a 3rd set of source files which I don’t have a comparable firmware.bin for. It is this 3rd one I ultimately want to get going, but I’m trying the other two builds as there are known firmware.bins which work from the code, but I cannot compile the code in a way that creates a usable firmware.bin. Something is clearly wrong with my procedure.

Functionally equivalent yeah if the CompiledFirmware is the firmware produced by just running compilation with unaltered environments etc. Binary equivalent is hard because builds are not 100% reproducable.

Well let’s do a simple sanity check then. I have cloned the repository and compiled the firmware with no modificiations here: https://drive.google.com/open?id=1BKQPnczgizYYV5dUolAh4htm4q8lSwFq

Does that induce the same behavior of “no startup”?

1 Like

Great Max, I’ll check it later this evening, should tell us something.

1 Like

Do you use the latest source files? I did PR with fixes.

Please re-download source files from https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/tree/master/firmware/V1.2

2 Likes

Well you’ve at least given me a moment of sanity. I’m not the only one building bricks. The firmware.bin you provided did the same as my firmware. And when I run a fc (file compare) vs. your firmware to the one I compiled, it finds ONE mismatch vs the 100s it finds when comparing your firmware and mine to the precompiled firmware.

At least you’ve told me I’m likely not doing something amuck. Ivan, a Victor fellow from another chat pointed me at your updated scripts and I tried to splice them into another build. But for consistency sake I will attempt to do a clean download now and compile the SKR v1.2 source and build that. I’ll report back later.

What is this witchcraft!? I believe I just successfully compiled a build!

I’ve managed to compile two different firmware.bin files using the last source files you provided. Do you know what was causing me to build bricks before?

Sadly while I was able to overwrite the config.h files in the Marlin folder with the ones from Teaching Tech, and the build did work & flash properly, something seems amuck. My stepper motors are super loud again. The SKR v1.2 board with the TMC2209 drivers quieted the steppers, but for some reason attempting to add Teaching Tech’s bltouch config.h files made them noisy again.

This however is a Marlin problem, and not PlatformIO. I’m finally able to build usable firmware.bin files. Thanks Ivan.

1 Like

I have the same issue with SKR MINI E3 DIP v1.0. I can compile without errors. The firmware.bin file flashes the printer without any issues but then the printer bricks…

Precompiled firmware.bin files like the one provided here from MATHEUS MARQUES can flash my printer and the printer is working.

However I need to make adjustments to the firmware and thats not possible when I am not able to compile any working .bin files… Spend a lot of time already on this issue… :frowning:

# ivankravets Is this an issue with my PIO (on VSCode) installation?

I already uninstalled everything and deleted .pio folder in the working director as well as the .platformio folder in my home directory. My workingenviroment is MACOS Catalina…

Hope someone can provide help…

Maxenium, I’m pretty sure something about the PlatformIO core 4.1.0 started creating problems when compiling our Marlin projects. Unfortunately the compile succeeds fine, not warning of any errors, but the firmware.bin doesn’t produce a usable firmware once flashed to the printer.

If you check this source from GitHub, you’ll notice a " [Override default LD Script using LINKFLAGS build scope]" note on the folders which if you follow down into PlatformIO\Scripts, it appears that the developer Ivan here has updated the scripts for the new 4.1.0 core, and after I used those my firmware.bin files compiled fine.

I’m unsure if the link above works specifically for the DIP board, but I assume the DIP vs soldered drivers boards were functionally the same.

The change to the linker file path would certainly be the reason for the firmware being broken (but still compiling fine). As to whether it stems from PIO 4.1 or not, I don’t know… it could very well be related to the fact that a month before the SKR repo updated to the latest Marlin 2.0, so maybe it broke then, and Ivan fixed it? Or, the STM32 platform files also updated around the same time, and the SKR guys haven’t version locked locked that in their platformio.ini, so it’s possible something broke there? All I’m saying is until you systematiclaly ensure that the same version of the platform and framework files are used, and then change between versions of PIO, it’s unclear if there was a change there that broke things.

Again, I’m new to the PlatformIO world. So how the compiler works exactly is beyond me. However this link:

Is one where I got the impression that there was a known error induced by PIO 4.1 which was causing Marlin builds not to boot. I used the exact source code that a couple of guys used in YouTube videos, and their PlatformIOs had an earlier core, 4.0.6 was one I believe, another may have been even earlier. Whatever the case, the script files that Ivan updated in the PlatformIO folder of the Marlin source has caused the firmwares to compile and boot properly.

So from my experience it appears that versions before 4.1.0 compiled usable firmware.bin files, and it required script updates to get the same source codes to then create usable firmware.bin files under 4.1.0. I did not figure out how to downgrade the PIO core to try the original source files, but it’s fixed, and I’m thankful!

1 Like

Essentially there’s three main parts to PlatformIO…

  • PlatformIO core (glue that holds everything together)
  • PlatformIO Platforms (platform/vendor specific stuff… Atmel AVR, STM32, ESP8266, TI)
  • PlatformIO Frameworks (frameworks that run on different platforms - Arduino, MBED, ESP-IDF)

For the platforms and frameworks, depending on your OS (Windows/Linux/Mac), and architecture (x86/x64/armhf/etc) and the version of the platform and/or framework (either a specified version, or the latest compataible version) PlatformIO will then install the appropriate toolchain, etc, to make everything work.

Hence my concern about was it PlatformIO 4.1, or the update to the STM32 package about a week before, which was probably pulled down at the same time. Since the devs aren’t using something like platform = ststm32@5.6.0 in the platformio.ini to lock the version of the stm32 platform to a specific version rather than use whatever random version the user might have installed… and I don’t have a SKR board to test on, I can’t answer that. So just have to hope they did actually test properly before jumping to conclusions, as I know I’ve done the same at times and got it wrong! :wink:

Either way, it’s working now, so enjoy a working printer again! :smiley:

Worked to use firmware provided by Ivan. Did the changes needed for the DIP version of the board and it worked.

Thanks Ivan.
:+1:

1 Like

#include errors detected. Please update your includePath. Squiggles are disabled for this translation unit (H:\Marlin-2.0.x SKR mini E3 V1.2 updated - BLtouch fil runout\Marlin-2.0.x SKR mini E3 V1.2 updated - BLtouch fil runout\Marlin\src\Marlin.cpp).

Anyone able to point me in the right direction to resolve this error?
Thanks