Marlin: [BUG] Compile error using Platformio (Creality Ender-3) - Arduino IDE works

[StephanReich]

Bug Description

My Configurations

Required: see .zip file

Steps to Reproduce

1. Edit platformio.ini to use default_envs = sanguino_atmega1284p
2. Use Visual Studio Code and the Platformio IDE extension
3. Clean und Build and you will get the following error:
   Compiling .pio\build\sanguino_atmega1284p\FrameworkArduino\wiring_shift.c.o
   Archiving .pio\build\sanguino_atmega1284p\libFrameworkArduino.a
   Archiving .pio\build\sanguino_atmega1284p\lib5a7\libU8glib-HAL_ID1932.a
   Linking .pio\build\sanguino_atmega1284p\firmware.elf
   avr-g++: error: CreateProcess: No such file or directory
   * [.pio\build\sanguino_atmega1284p\firmware.elf] Error 1
4. If I use Arduino IDE with the same config - it works!
5. This error is with all Marlin versions > 2.0.1 compiling with Visual Studio Code and Platformio IDE
   Configuration.zip

[bill-orange]

Has it worked before? Is this a Windows 10 machine and did you install GIT?

[sjasonsmith]

I can reproduce the same issue. I think it is a command length issue, even though PlatformIO normally handles that better than Arduino.

I noticed that melzi builds fine, but sanguino_atmega1284p still fails even if I configure them identically.

If I rename sanguino_atmega1284p to s1284p, it can then build.

[StephanReich]

I can reproduce the same issue. I think it is a command length issue, even though PlatformIO normally handles that better than Arduino.

I noticed that melzi builds fine, but sanguino_atmega1284p still fails even if I configure them identically.

If I rename sanguino_atmega1284p to s1284p, it can then build.

Thanks for your workaround - renaming to s1284p solved this issue.

[StephanReich]

Has it worked before? Is this a Windows 10 machine and did you install GIT?

Yes - it worked until Marlin 2.0.1. I'm using Win10 and GIT
The actual path for the Marlin firmware is:
D:\Develop\Projekte\FlashEnder3\Marlin-2.0.1 --> works
D:\Develop\Projekte\FlashEnder3\Marlin-2.0.4 --> error (works now with the workaround)

[sjasonsmith]

I'm not sure what the proper solution is for this. Renaming the sanguino environments would resolve it for now, but it might just come back again as included libraries evolve.

I don't know why other environments with long names (such as STM32F103RC_bigtree_512K_USB don't have the same issue. It might just be that the AVR toolchain uses gcc 5.4 and the ARM toolchains use gcc 7.2.1.

[jesasi]

Got this same error.
I'm so newbie with marlin and visual studio code, that could not figure out where / how / what i must change to get it working again?

So, if you could, please newbie friendly tips =)

Thanks!

[StephanReich]

Got this same error.
I'm so newbie with marlin and visual studio code, that could not figure out where / how / what i must change to get it working again?

So, if you could, please newbie friendly tips =)

Thanks!

Did you installed Visual Studio Code and Platformio?
(see https://marlinfw.org/docs/basics/install_platformio_vscode.html)

Use the default Ender-3 config and modify the settings to your needs or leave it as it is.
(https://github.com/MarlinFirmware/Marlin/tree/2.0.x/config)

Use the attached platformio.ini file to compile your Marlin firmware.
(changes made in lines 21 and 125)
platformio.zip

[cybercatgurrl]

I was going mad and thought I was alone in this. I am glad I am not. Thank you for the workaround. It finally compiled.

[jesasi]

Thanks! Will try it when back in home.
BTW, before I got this popup, just hour ago when I tried, it was not anymore there:
https://photos.app.goo.gl/rSN48g4A2kk7SntK9

[jesasi]

.. Just tried with .ini what was in zip, now result is this:
https://photos.app.goo.gl/ob2QifcpX8hEBRR58

[StephanReich]

.. Just tried with .ini what was in zip, now result is this:
https://photos.app.goo.gl/ob2QifcpX8hEBRR58

You cannot use the visual studio code marlin extension because of the changes in the platformo.ini
Please go direct to the platformio icon on the left side and click to clean. After clean to build.

[jesasi]

Thanks.

I'm trying these over teamviewer with my phone, looks like when doing what you suggested on your last screenshot, build goes OK.

But when pushing build button from marlin auto builder, I get same error what was shown on my last screenshot.

Will try to upload firmware when home.

[StephanReich]

But when pushing build button from marlin auto builder, I get same error what was shown on my last screenshot.

As I wrote.
Because of the change in the platformio.ini from "sanguino_atmega1284p" to "s1284p" the Marlin Auto Build will not work. Marlin Auto Build is using a fix build command with "sanguino_atmega1284p".

If you would like to use it please enter the following command after your error in Marlin Auto Build: (see also screenshot)
platformio run -e s1284p

[jesasi]

StephanReich, thanks for your patience and kind help, got it working!

Anyways, something else gone wrong, sometimes when powering on, lcd has nothing, and some times lcd, motion, heating etc works fine, but every time I connect octopi or laptop to printer USB, printer halts totally, no even response from knob.

Must find quickly Uno and learn way to flash bootloader and firmware again.

[thinkyhead]

Because of the change in the platformio.ini from "sanguino_atmega1284p" to "s1284p" the Marlin Auto Build will not work.

You also have to replace that string where it appears in pins.h so Auto Build will see it.

[sjasonsmith]

@thinkyhead people have workarounds for this but it isn’t really fixed. The Sanguino targets are completely unusable by default on Windows.

I tracked down the commit where it started failing and it was completely unrelated. The list of source files simply grew slightly too long.

If you’re ok with the env name changing I can post a PR this morning. I already did it, just hadn’t tried auto-build yet.

I opted to simply remove ATmega from the name, to leave sanguino_1284p, which is short enough to prevent the issue.

[thinkyhead]

If you’re ok with the env name changing I can post a PR this morning. I already did it, just hadn’t tried auto-build yet.

I don't think there's any point in trying to mitigate this issue with Windows. I would actually nag the PlatformIO project about it at this point, because they could assign a long path to a short shell variable name and use that in the command-line instead, and that would solve the issue for all large projects.

[sjasonsmith]

They already pass them in an argument file. I suspect the older gcc used by AVR simply has a shorter length limit, apparently ~32k.

This is currently impacting one of the most common printers on the most common operating system. Doing nothing will mean it just keeps being brought up repeatedly.

Another option without renaming environments is to have more boards use the melzi environment. 644p isn’t an option, but I assume most of these boards never actually shipped with a 644p.

[thinkyhead]

Doing nothing will mean it just keeps being brought up repeatedly.

Shorten the names of all the environments and people will complain who have deep folder structures. There won't be any end to it. What do other projects to when they come up against the lameness of Redmond?

[sjasonsmith]

Shorten the names of all the environments and people will complain who have deep folder structures.

In this case the actual location of the user's folder does not matter. The argument file generated by PIO only includes relative paths from the Marlin root, so are completely within Marlin's control. That was one of the first things I considered, as I thought simply moving the the Marlin folder to a shorter path on disk might help.

[sjasonsmith]

What do other projects to when they come up against the lameness of Redmond?

They don't use Arduino on AVR ;)

[thinkyhead]

The location of the project folder surely does, as this prefixes the .../.pio/my_environment folder. Is the path to .pio also project-relative?

[sjasonsmith]

The location of the project folder surely does, as this prefixes the .../.pio/my_environment folder. Is the path to .pio also project-relative?

I am looking at the arguments in the longcmd file that is generated in the .pio/<env> folder. All the files in there are relative, starting with "./pio". Now that I look this is just the link step, perhaps the location on disk matters for the compile step, but I didn't have to relocate my Marlin folder to fix the current set of issues.

[thinkyhead]

I've suggested a few things to the PlatformIO project. I don't see any reason, for example, that the linker stage has to occur in the same cwd as the build stage. Why not cd into the .pio/build/<env>/ folder for the link?

And, of course…

Q=.\.pio\build\my_environment ; linky-link $Q\this.o $Q\that.o ...

[toastyrhombus]

Just ran up against this one. Found the issue discussed on another site and decided locally on the same workaround as proposed here. Bit more information below on the issue, for what its worth.

The issue appears to be related to the size of the argument passed to, I assume, avr-ld from avr-g++ (Correct me if i'm wrong). The longcmd file inside my build environment was over 32kB large, it is my understanding the contents of this file is used as an argument to create the avr-ld process. Based on https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa - the lpCommandLineparameter of the CreateProcessAmethod accepts only 32,768 characters which mine was over....just. Bit of a stretch but the theory checks out when given a cursory glance.

[sjasonsmith]

Try it in the bugfix-2.0.x branch. I believe these environment names have already been changed to fix this.

[thinkyhead]

Only _slightly_ shortened. But every bit helps.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.