On RP2040, multiple calls to addLeds() results in "Error: invalid offset, value too big"

[rah2501]

Compiling any of the examples in the "Multiple" subdirectory results in an error similar to this:

{standard input}: Assembler messages:
{standard input}:1100: Error: invalid offset, value too big (0x00000494)

Commenting out all but one of the calls to addLeds() results in a successful compilation in each case.

[samguyer]

Not a lot of information! Could it be a compiler bug? Do we even have any assembly code in the ARM platform implementation?

[rah2501]

Not a lot of information!

Enough to reproduce the issue.

Could it be a compiler bug?

Could be.

Do we even have any assembly code in the ARM platform implementation?

FastLED contains Arm assembly code, yes.

[samguyer]

I'll talk to Kriegsman about it. I don't know anything about the ARM code, and with basically zero information about where the error is occuring in the compilation process or in the code, it's hard to know where to look.

[rah2501]

with basically zero information ... it's hard to know where to look

If you want to work on this issue, I would suggest that reproducing the error for yourself would be the first step.

[samguyer]

Remind me again: what is the exact configuration you're using? Are you using the Arduino IDE? What version and what board?

[rah2501]

Are you using the Arduino IDE?

The error occurs compiling with both the Arduino IDE and PlatformIO.

What version and what board?

Arduino 1.8.19, Raspberry Pi Pico/RP2040 3.6.2, FastLED 3.6.0; board Raspberry Pi Pico

PlatformIO 6.1.1, framework-arduinopico 1.30600.0+sha.41b0686, FastLED 3.6.0; board pico

[samguyer]

It looks like we've got multiple issues for this problem already. We need to figure out a solution, but you can see what others have done: https://github.com/FastLED/FastLED/issues/1481 https://github.com/earlephilhower/arduino-pico/discussions/1649

[rah2501]

It looks like we've got multiple issues for this problem already.

Bit of a waste of my time getting those version numbers.

[samguyer]

Well, it was a bit of a waste of my time to find the links for the existing issues for you. So, I think we're square on that account.

[samguyer]

But snarkiness aside, it's never a waste of time to provide that kind of information. I started to work on reproducing the error using that information before I realized that it was an existing issue with a bunch of work already done.

[zackees]

This typically happens when asm code is compiled with debug symbols on. Arduino was surprisingly compiling in debug by default in a lot of cases. I'm not sure if this asm generation bug is still lurking. Recently I've moved the RPXXXX builds to an open source version and it seems to have gone away in our tests.

I might suggest moving to platformio and using the platform authored by @max.

Here are some of our platformio.ini build changes from our config file to reflect this:

"rpipico2": [
    "platform=https://github.com/maxgerhardt/platform-raspberrypi.git",
    "platform_packages=framework-arduinopico@https://github.com/earlephilhower/arduino-pico.git",
    "framework=arduino",
    "board_build.core=earlephilhower",
    "board_build.filesystem_size=0.5m"
],

[zackees]

I want to mention that this issue may have been fixed. It turns out that some code can overflow if the generated assembly is too big to fit on a 64k code page. I've gone ahead and added a GCC attribute to compile code using Os here https://github.com/FastLED/FastLED/commit/5016c54e121323f2db950ffb2b112ac43806e2ce

[zackees]

This should be fixed now. It looks like our M0_FALLBACK was supposed to be NOT included by default (according to the comments) but it was anyway. Users found disabling this fixed it. I went ahead and fixed the issue and it seems not break the tests so making it the default to align with the comments in the codebase.