SamBlenny Zephyr Quest: Troubleshooting a Pi Pico2 build error

Zephyr Quest: Troubleshooting a Pi Pico2 build error

by SamBlenny
Last updated February 05, 2025
Save
  • Report this Note
  • Export as JSON

Getting Started

Adafruit Playground is a wonderful and safe place to share your interests with Adafruit's vibrant community of makers and doers. Have a cool project you are working on? Have a bit of code that you think others will find useful? Want to show off your electronics workbench? You have come to the right place.

The goal of Adafruit Playground is to make it as simple as possible to share your work. On the Adafruit Playground users can create Notes. A note is a single-page space where you can document your topic using Adafruit's easy-to-use editor. Notes are like Guides on the Adafruit Learning System but guides are high-fidelity content curated and maintained by Adafuit. Notes are whatever you want them to be. Have fun and be kind.

Click here to learn more about Adafruit Playground and how to get started.

🤯 2

As part of a series on Zephyr with Adafruit hardware, this guide documents the process I used to diagnose a problem with building Zephyr's hello_world sample app for Raspberry Pi Pico 2. By the time you read this, there's a good chance the Zephyr folks may have already fixed the problem that tripped me up. But, perhaps my troubleshooting process will be a useful reference.

TLDR: Use west build ... -- -DCONFIG_PICOLIBC_USE_MODULE=y to build picolibc from source, or delete the ~/.cache/zephyr cache directory.

The Linker Error

Working towards the goal of writing a new board definition for the Adafruit Feather RP2350, I've been looking at how the device tree setup for the existing Raspberry Pi Pico 2 board definition works. When I got around to trying to build the hello world sample app for the Pico 2, which also uses the RP2350, I got stuck on a linker error.

Below, I've included a console log which is a bit long. But, it shows some interesting details. The main error messages come in pairs that follow this pattern:

  • ...arm-zephyr-eabi/lib/./libc.a(strcmp.S.o): conflicting CPU architectures 17/2
  • ...ld: failed to merge target specific data of file ... /libc.a(strcmp.S.o)

After the console log, I'll explain how I tracked this down and found a workaround.

Copy Text

Research

Often, the first thing I do when a build crashes mysteriously is feed the error message to a search engine and see what comes up.

"conflicting CPU architectures"

When I started searching for the "conflicting CPU architectures 17/2" error message, I found forum threads discussing the possibility of attempting to link ARM object code that had been compiled for incompatible architectures. In particular, there was some talk about hardware floating point and software floating point implementations (-mfloat-abi=soft, -mfloat-abi=hard, etc). The floating point stuff caught my eye because the RP2350's Cortex-M33 has hardware floating point, but the RP2040's Cortex-M0+ does not. So, it seemed maybe relevant.

At that point, I decided to look for more information about which object files were being linked together and which architectures those files had been compiled for.

Which files were being linked?

My first problem was to identify what the build system was doing when all the errors happened. Looking at the console log, the trouble seems to start on a line that begins with

 FAILED: zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map ...

On the next line, there was a really long command line that starts with

 : && ccache /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc ...

Then, the first error line included this stuff (I added line breaks with \ for easier reading):

/home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/\
../../../../arm-zephyr-eabi/bin/ld: \
error: /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../\
lib/gcc/../../picolibc/arm-zephyr-eabi/lib/./libc.a(strcmp.S.o): \
conflicting CPU architectures 17/2

So, pulling that error line apart, and resolving the .. relative directories, the most interesting bits are:

  • zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/ld
  • zephyr-sdk-0.17.0/arm-zephyr-eabi/lib/picolibc/arm-zephyr-eabi/lib/libc.a(strcmp.S.o)

What I read there is, the ld linker from the arm-zephyr-eabi toolchain of the version 0.17.0 Zephyr SDK got angry about something involving strcmp.S.o from the libc.a prebuilt library file. Also, that library comes from the version of picolibc which is bundled with the arm-zephyr-eabi toolchain.

Based on that, I came up with these questions:

  1. Where did the reference to strcmp.S.o come from that caused ld to try linking against libc.a?
  2. Why is Zephyr's build system using that version of picolibc instead of the picolibc module from the Zephyr workspace directory (downloaded as part of west init ...)?
  3. Once I identify the two files being linked, can I tell which architecture those files were compiled for?
  4. Once I know the target architectures of the object files, will it turn out that one is for hardware floating point and the other is for soft floating point?

For the first question, I used grep to examine the build/zephyr/zephyr_pre0.map file that west build creates in the build directory:

Copy Text 
(.venv) $ grep strcmp build/zephyr/zephyr_pre0.map 
/home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/./libc.a(strcmp.S.o)
                              zephyr/kernel/libkernel.a(device.c.obj) (strcmp)
 .text          0x0000000000000000       0x1c /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/./libc.a(strcmp.S.o)
 .data          0x0000000000000000        0x0 /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/./libc.a(strcmp.S.o)
 .bss           0x0000000000000000        0x0 /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/./libc.a(strcmp.S.o)
 .ARM.extab     0x0000000000000000        0x0 /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/./libc.a(strcmp.S.o)
 .ARM.exidx     0x0000000000000000        0x8 /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/./libc.a(strcmp.S.o)
 .debug_frame   0x0000000000000000       0x20 /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/./libc.a(strcmp.S.o)
                0x000000000000109a       0x1a /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/./libc.a(strcmp.S.o)

I'm not an expert on what everything means in the zephyr_pre0.map file. But, I see that the lines which include strcmp.S.o refer to libc.a from picolibc and zephyr/kernel/libkernel.a. So, it looks like the other file was build/zephyr/kernel/libkernel.a.

Objdump .o and .a files

To check the target architectures, I used arm-zephyr-eabi-objdump that comes with the arm-zephyr-eabi toolchain, like this:

Copy Text 
(.venv) $ ~/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/arm-zephyr-eabi-objdump -f \
    ~/zephyr-sdk-0.17.0/arm-zephyr-eabi/picolibc/arm-zephyr-eabi/lib/libc.a | grep -A 4 strcmp.S.o
strcmp.S.o:     file format elf32-littlearm
architecture: armv4t, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000

(.venv) $ ~/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/arm-zephyr-eabi-objdump -f \
    build/zephyr/kernel/libkernel.a | head -n 6
In archive build/zephyr/kernel/libkernel.a:

main_weak.c.obj:     file format elf32-littlearm
architecture: armv8-m.main, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000

What I see there is:

  1. libc.a was compiled for armv4t (really old, no hardware floating point)
  2. libkernel.a was compiled for armv8-m.main (Coretex-M33 with hardware floating point)

So, at this point, it seems likely the linker error was trying to tell us those two CPU targets were incompatible. For another data point, when I compiled the hello world sample app successfully for a Pi Pico (RP2040), the architecture for libkernel.a was armv6s-m. It looks like maybe linking armv6s-m with armv4t is okay, but perhaps armv8-m.main with armv4t is not possible.

If you want more background on the different ARM architecture target names, take a look at the gcc ARM Options documentation.

Finding a Workaround

Once I learned the zephyr-sdk-0.17.0/arm-zephyr-eabi/lib/picolibc version of picolibc was not suitable, my next question was, how do I get west build to compile picolibc from source?

It turns out the Zephyr config option CONFIG_PICOLIBC_USE_MODULE exists and does just what I need. Based on my reading of various Zephyr documentation pages, GitHub discussions, and so on, it sounds like the Zephyr SDK toolchains are normally supposed to have a prebuilt picolibc library. But, in the case of the RP2350 SoC, which was only recently added to Zephyr, maybe that isn't working yet. I'm not sure. In any case, compiling picolibc from source works.

This is my workaround:

Copy Text 
(.venv) $ west build -p always -b rpi_pico2/rp2350a/m33 samples/hello_world -- -DCONFIG_PICOLIBC_USE_MODULE=y
...[irrelevant stuff edited out]...
-- west build: building application
[1/1095] Preparing syscall dependency handling

[6/1095] Generating include/generated/zephyr/version.h
-- Zephyr version: 4.0.99 (/home/sam/code/zephyr-workspace/zephyr), build: v4.0.0-4610-gb7cfa54c1837
[1095/1095] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
 IMAGE_DEF_FLASH:          28 B        128 B     21.88%
           FLASH:       15716 B    4194048 B      0.37%
             RAM:        3968 B       520 KB      0.75%
        IDT_LIST:          0 GB        32 KB      0.00%
Generating files from /home/sam/code/zephyr-workspace/zephyr/build/zephyr/zephyr.elf for board: rpi_pico2
Converted to uf2, output size: 32256, start address: 0x10000000
Wrote 32256 bytes to zephyr.uf2

The important part is the -- -DCONFIG_PICOLIBC_USE_MODULE=y at the end of the west build ... line.

When you give a command to west build, the options after -- will get passed along to CMake. So, it's possible to alter some configuration settings, similar to putting the settings in one of the various CMake config files that Zephyr uses.

I still don't know why west build was trying to link against an unsuitable picolibc library. But, telling it to compile picolibc from source seems to be an effective workaround.

Another Fix

Thanks to GitHub user @xudongzheng for the suggestion that clearing the Zephyr cache might resolve the problem. I tried that and it worked, but I have no clue what caused the problem with the cache:

Copy Text 
(.venv) $ rm -r ~/.cache/zephyr
(.venv) $ rm -r build
(.venv) $ west build -p always -b rpi_pico2/rp2350a/m33 samples/hello_world
...
-- west build: building application
[1/138] Preparing syscall dependency handling

[3/138] Generating include/generated/zephyr/version.h
-- Zephyr version: 4.0.99 (/home/sam/code/zephyr-workspace/zephyr), build: v4.0.0-4610-gb7cfa54c1837
[138/138] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
 IMAGE_DEF_FLASH:          28 B        128 B     21.88%
           FLASH:       15272 B    4194048 B      0.36%
             RAM:        3968 B       520 KB      0.75%
        IDT_LIST:          0 GB        32 KB      0.00%
Generating files from /home/sam/code/zephyr-workspace/zephyr/build/zephyr/zephyr.elf for board: rpi_pico2
Converted to uf2, output size: 31232, start address: 0x10000000
Wrote 31232 bytes to zephyr.uf2

By checking the map file in the build directory using grep, we can see that this time strcmp was coming from zephyr-sdk-0.17.0/arm-zephyr-eabi/picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main/nofp/libc.a, which is a suitable choice for Cortex-M33:

Copy Text 
(.venv) $ grep strcmp build/zephyr/zephyr_pre0.map
/home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main/nofp/libc.a(strcmp.S.o)
                              zephyr/kernel/libkernel.a(device.c.obj) (strcmp)
 .text          0x0000000000000000       0x14 /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main/nofp/libc.a(strcmp.S.o)
 .data          0x0000000000000000        0x0 /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main/nofp/libc.a(strcmp.S.o)
 .bss           0x0000000000000000        0x0 /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main/nofp/libc.a(strcmp.S.o)
 .ARM.extab     0x0000000000000000        0x0 /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main/nofp/libc.a(strcmp.S.o)
 .ARM.exidx     0x0000000000000000        0x8 /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main/nofp/libc.a(strcmp.S.o)
 .debug_frame   0x0000000000000000       0x20 /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main/nofp/libc.a(strcmp.S.o)
                0x000000000000109a       0x20 /home/sam/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v8-m.main/nofp/libc.a(strcmp.S.o)

This page (Zephyr Quest: Troubleshooting a Pi Pico2 build error) was last updated on February 05, 2025.

Text editor powered by tinymce.

Search

Getting Started

Adafruit Playground is a wonderful and safe place to share your interests with Adafruit's vibrant community of makers and doers. Have a cool project you are working on? Have a bit of code that you think others will find useful? Want to show off your electronics workbench? You have come to the right place.

The goal of Adafruit Playground is to make it as simple as possible to share your work. On the Adafruit Playground users can create Notes. A note is a single-page space where you can document your topic using Adafruit's easy-to-use editor. Notes are like Guides on the Adafruit Learning System but guides are high-fidelity content curated and maintained by Adafuit. Notes are whatever you want them to be. Have fun and be kind.

Click here to learn more about Adafruit Playground and how to get started.