ROM overflow when compiling MPMD under ubuntu 20.04.1LTS

[mgouget]

Dear All,

I just got a minidelta, found that the stock firmware was horrible, and installed MPMD, which is a HUGE improvement; thanks A LOT!!! But the first layer was not perfect, even using AUTO_CALIBRATE.gcode, so I began tinkering. I was able eventually to recompile a working MPMD, using Ubuntu 18.04LTS and platformio.

Then I upgraded to Ubuntu 20.04.1LTS, and the Makefile (make all) made a fatal error when linking: /usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld:/home/mgouget/mpminidelta/mpmd_marlin_1.1.x/stm32f0xx/LinkerScript.ld:181 cannot move location counter backwards (from 0000000008020c68 to 000000000801f800)

When commenting the UNUSED_FLASH_MEMORY section in LinkerScript.ld around line 181, I got: /usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld: mpmd_marlin_1.1.x-119r14-ACfan.elf section '.rodata' will not fit in region 'ROM' /usr/lib/gcc/arm-none-eabi/9.2.1/../../../arm-none-eabi/bin/ld: region 'ROM' overflowed by 5224 bytes

I tried to spare some memory by commenting in configuration.h EEPROM_CHITCHAT, but I got the same 5224 overflow.

It seems that the new version of the tool-chain is not as space-efficient as the old one.

Here are the versions: arm-none-eabi-g++ (15:9-2019-q4-0ubuntu1) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] GNU ld (2.34-4ubuntu1+13ubuntu1) 2.34

Unfortunately, I don't have the versions of the previous tool-chain.

Any tricks or ideas to be able to recompile MPMD again?

Cheers,

Michel

[PurpleHullPeas]

I don't have a direct answer to your question, but is there some reason you need to custom compile your firmware instead of using one of the pre-compiled binaries?

Regarding the imperfect calibration, I am of the opinion that certain core design flaws of the MPMD cannot be compensated for with software, alone. My approach is to perform all reasonable hardware upgrades/alignments and then do software calibration after that. You can find more information here.

[mgouget]

Thanks PurpleHullPeas, and thanks for the links that I have already read.

I am using the pre-compiled binary that works very well (thanks again Aegean-Odissey!) but I always try to build my software myself as I want to be autonomous, and also have fun tinkering with parameters ;) There is no urgency, but it will have to be done one day or another, and now this difficulty is known.

Concerning calibration, I agree with you that the MPMD is an entry level system, but it works remarkably well for its price. I already did the belt tensioning, and, apart changing the switches for removing the throw and lubricating everything, there are no special easy upgrades.

I use a WhamBam plate, which can be reversed so that the contact of the inox verso with the (clean) head can be used as a (unreliable) switch. I wrote a nodejs piece of code to drive it and probe the surface (G30) using this system and display a heat-map using gnuplot:

I do X-Y then Y-X in reverse and I average to take the amount of play into account.

Based on that, I want to write a filter that transform tthe Cura-generated gcode, as I have understood that a 7x7 matrix is not enough for a correct bed leveling. While accumulating statistically significant data (a double probe cycle with a 21x21 matrix takes 30 min...) I am doing some research to find the correct mathematical model that can be fitted to our delta printer :)

[PurpleHullPeas]

FWIW, one of my MPMDs has:

1. Upgraded+Adjusted bed clips.
2. WhamBam
3. Adjusted Arm Lengths
4. Bed Shimmed Square to the rails
5. Belts tuned, parts lubed, other maintenance, etc.
6. M92+M665+M666 calibration.
7. Other misc upgrades not related to delta kinematics.

Bed leveling still isn't quite as good as the MPMDs I've calibrated with glass beds, but is good enough for my purposes. My current conclusion is that having a perfectly flat surface is more important than I had originally expected. Haven't really messed with it much since, because I've been printing stuff.

[aegean-odyssey]

@gouget, I am of the same mind. Somehow, I think the firmware's auto-calibration should be able to do a better job with the "stock equipment". I am trying to come up with some ways to improve the firmware's auto-calibration for printer's stock hardware. The common wisdom seems to be that my endeavor is pure folly, and truthfully, progress has been (at best) slow. I've put up a few tools at mpmd-calibration-experimental to help with some of the experimenting, and I'm doing some analyses off-line, but so far I've not garnered any great insights.

To your building the firmware question:

• I ran into the same problem when setting up the travis-ci build system -- using the newer Ubuntu OS, the development tools produced larger (too large) firmware images. Adding to the confusion, I used the same Debian OS docker container with Debian and gcc tool chain to compile the firmware -- I think, particularly in this case, the Debian+tools docker image on older Ubuntu or newer Ubuntu should produce the same result; but no. It's on a "back-burner" to-do list to figure out why the choice of Ubuntu version makes a difference. For a local build system, I install a minimal Debian plus the gcc tool chain, git, and editor into a chroot enviroment and do all the development (git, edit, compile, etc) from within the chroot environment. It works well.

• The current firmware project includes the STM32 SDK (1.10), so I don't think that the PlatformIO stuff is necessary (and could be working against you). I think the installing (apt get install) following packages should be sufficient to build the firmware: build-essential, gcc-arm-none-eabi, binutils-arm-none-eabi, libnewlib-arm-none-eabi, libnewlib-dev, and libstdc++-arm-none-eabi-newlib.

  The files in folder stm32f0xx/ more or less patch up the 1.10 version of the SDK -- and it turns out that the 1.11 version of the SDK is changed significantly (generally improved, but adding quite a bit of overhead), plus not compatible with my changes in the stm32f0xx/ folder. It's possible that a newer PlatformIO is using the newer 1.11 version of the SDK under the hood, and another reason why the firmware ends up being so large.

[aegean-odyssey]

@mgouget, following up... hoping that you've some progress to share.

I put a little build experiment into the repository.

Using "github actions", I was able to create two build processes: one using debian buster (via docker and ubuntu-18.04), and one using ubuntu-20.04 straight away. Everything is pretty much identical with the exception of the toolchain, and as you pointed out ubuntu-20.04 fails to build because the compiled firmware image is much too large.

I haven't a clue why this is the case, but my quick look at "changes" documentation for the various components of the toolchain leads me to think that there are substantial differences between old and new. I'll do some more investigating.

[aegean-odyssey]

@mgouget, I don't have an exact answer for you, but after installing the latest GNU ARM toolchain (10-2020q4) into the ubuntu-20.04 os, the firmware compiles just fine with only a couple of compiler warnings (since cleaned up).

Not only does it work, the new toolchain produces a much smaller firmware image, leaving about 4K bytes of code space unused!

So much of an improvement that I've updated the build process in the repository to use the new toolchain. In the process, I tweaked the Makefile so that it is easier to build a one-off version of the firmware, which you can see in use under the Github Actions to build the firmware. Essentially it's, make select="option option option" to build the firmware.

There is nothing special about the toolchain installation. I unpack the archive and make sure its bin/ directory can be found via the PATH environment variable. You can see what I've done in the Github Actions "workflows" files .github/workflows/* and the .travis_dockerfile.