Problem compiling - Cannot plug gap greater than alignment

[fmakara]

I don't really know if this is a problem with micropython or the pico-sdk (or even if my own computer is haunted right now, since this error was triggered while working, no update done), but I consistently have gotten the following error compiling micropython (and, in my personal interest, forks of):

[ 96%] Linking CXX executable firmware.elf
ERROR: Cannot plug gap greater than alignment - gap 254032, alignment 32
make[3]: *** [CMakeFiles/firmware.dir/build.make:7192: firmware.elf] Error 253
make[3]: *** Deleting file 'firmware.elf'
make[3]: Leaving directory '/home/makara/micropython/ports/rp2/build-RPI_PICO'
make[2]: *** [CMakeFiles/Makefile2:1791: CMakeFiles/firmware.dir/all] Error 2
make[2]: Leaving directory '/home/makara/micropython/ports/rp2/build-RPI_PICO'
make[1]: *** [Makefile:91: all] Error 2
make[1]: Leaving directory '/home/makara/micropython/ports/rp2/build-RPI_PICO'
-e See https://github.com/micropython/micropython/wiki/Build-Troubleshooting
make: *** [Makefile:65: all] Error 1

The trigger for this post is as fresh build of micropython as I can get. Windows 11 running fresh WSL, Ubuntu 22.4.5 LTS (as in, unregistered [uninstalled] previous instalation). In the following commands, I install the dependencies of pico-sdk, then follow the instructions from micropython:

sudo apt update
sudo apt install cmake python3 build-essential gcc-arm-none-eabi libnewlib-arm-none-eabi libstdc++-arm-none-eabi-newlib git git-gui
git clone https://github.com/micropython/micropython.git --recursive
cd micropython/mpy-cross/
make
cd ../ports/rp2
make submodules
make clean
make

In my basic research, I already found that this error comes from picotool, which seems to mis-interpret something from the linker. Unfortunately, I have very poor knowledge debugging linker errors, so treat my interpretation with a grain of salt. I have manually changed picotool (previously to reseting my setup) and recompiled to print the addresses in question, and the "gap" seems to come from the space between the last bit of pre-alocated RAM (?) (0x200027b0) and the SCRATCH_Y (0x20041000).
firmware.elf.map.txt

Have someone had a similar problem?

[edtink]

I am having the same problem that started yesterday for me (04/04/25).

I tried a clean build using "git clone https://github.com/micropython/micropython.git --branch master" and got a the same error (different gap):

[ 98%] Linking CXX executable firmware.elf
ERROR: Cannot plug gap greater than alignment - gap 254000, alignment 32

I then tried a clean build using "git clone https://github.com/micropython/micropython.git --branch v1.24-release" and it builds successfully.

So, the problem appears to have very recently been introduced in the master branch.

[shariltumin]

Yes, the problem is related to the latest picotool v2.1.2-develop (Linux, GNU-11.4.0, Release). The previous version that works for RP2040 is picotool v2.1.1-develop (Linux, GNU-11.4.0, Release). I have no problem linking RP2350.

Now, the problem was:

. . .
_deps/picotool/picotool uf2 convert --quiet /home/sharil/ssd/mp/20250405/micropython/ports/rp2/build-RPI_PICO/firmware.elf firmware.uf2 --family rp2040
ERROR: Cannot plug gap greater than alignment - gap 254032, alignment 32

If we can somehow use the older version of picotool (version v2.1.1) then we will be able to link firmware.elf and convert to firmware.uf2.

I have not found out how to do this "officially", but manage to hack the "lib/pico-sdk/tools/Findpicotool.cmake"

As a test, I copied the picotool-v2.1.1 to "/tmp/picotool". And with the "Findpicotool.cmake":

# Finds (or builds) the picotool executable
#
# This will define the following imported targets
#
#     picotool
#
cmake_minimum_required(VERSION 3.17)

if (NOT TARGET picotool)
    set(picotool_BUILD_TARGET picotoolBuild)
    set(picotool_TARGET picotool)

    set(picotool_EXECUTABLE /tmp/picotool)
    add_executable(${picotool_TARGET} IMPORTED GLOBAL)
    set_property(TARGET ${picotool_TARGET} PROPERTY IMPORTED_LOCATION
            ${picotool_EXECUTABLE})

    add_dependencies(${picotool_TARGET} ${picotool_BUILD_TARGET})
endif()

After that I was able to build a working firmware.uf2.

. . .
/tmp/picotool uf2 convert --quiet /home/sharil/ssd/mp/20250405/micropython/ports/rp2/build-RPI_PICO/firmware.elf firmware.uf2 --family rp2040
/usr/bin/arm-none-eabi-size --format=berkeley /home/sharil/ssd/mp/20250405/micropython/ports/rp2/build-RPI_PICO/firmware.elf
   text	   data	    bss	    dec	    hex	filename
 334076	      0	   5080	 339156	  52cd4	/home/sharil/ssd/mp/20250405/micropython/ports/rp2/build-RPI_PICO/firmware.elf

Pay attention to the lines that say "/tmp/picotool" above.

$ mpr
Connected to MicroPython at /dev/ttyACM0
Use Ctrl-] or Ctrl-x to exit this shell
MicroPython v1.25.0-preview.442.g3805e65ed.dirty on 2025-04-05; Raspberry Pi Pico with RP2040
Type "help()" for more information.
>>> 

[fmakara]

Thanks for the solution @shariltumin ! Found a cleaner way (IMHO):
In the same file (lib/pico-sdk/tools/Findpicotool.cmake), around line 40 replace the desired GIT_TAG from the picotool repository:

        message("Downloading Picotool")
        FetchContent_Populate(picotool QUIET
            GIT_REPOSITORY https://github.com/raspberrypi/picotool.git
            GIT_TAG 2.1.1
            SOURCE_DIR ${picotool_INSTALL_DIR}/picotool-src
            BINARY_DIR ${picotool_INSTALL_DIR}/picotool-build
            SUBBUILD_DIR ${picotool_INSTALL_DIR}/picotool-subbuild
        )

@edtink 's solution also seems to work, but would mean rebasing my commits... which is probably the most correct answer.... sigh, will do it after the vacations... edit: I got too curious and made the rebase, which compiled flawlessly. Marking as the solution, since unless you are working with bleeding edge features, you (in this case, me) should always use the last release, and not the development.

This, by itself, makes me think there is one more "quick and dirty" solution: Just bump the lib/pico-sdk to v2.1.1 (the same used by micropython v1.24). No idea what bugs this by itself might introduce thou....

[edtink]

More info here: #17081