SDK 2.3.0 default RAM memory consumption increase

[shtirlic]

After updating to the Pico SDK 2.3.0, I am unable to build my project due to over ~40KB increase in RAM consumption. Does anyone know where I can find documentation on these changes, or the best way to identify what is causing this increase?

 cd /home/shtirlic/projects/8086/picocalc_x86/build && /home/shtirlic/.local/bin/picotool uf2 convert --quiet /home/shtirlic/projects/8086/picocalc_x86/build/picocalc_x86.elf picocalc_x86.uf2 --family rp2350-riscv --abs-block
/opt/riscv/bin/../lib/gcc/riscv-none-elf/15.2.0/../../../../riscv-none-elf/bin/ld: picocalc_x86.elf section `.bss' will not fit in region `RAM'
/opt/riscv/bin/../lib/gcc/riscv-none-elf/15.2.0/../../../../riscv-none-elf/bin/ld: section .scratch_x VMA [20080000,2008057f] overlaps section .bss VMA [200159d8,2008a533]
/opt/riscv/bin/../lib/gcc/riscv-none-elf/15.2.0/../../../../riscv-none-elf/bin/ld: region `RAM' overflowed by 42292 bytes
Memory region         Used Size  Region Size  %age Used
           FLASH:      374352 B         4 MB      8.93%
           PSRAM:           0 B          0 B
         XIP_RAM:           0 B        16 KB      0.00%
             RAM:      566580 B       512 KB    108.07%
       SCRATCH_X:        3456 B         4 KB     84.38%
       SCRATCH_Y:          32 B         4 KB      0.78%
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
build finished with error(s).

[lurch]

An 8% increase seems pretty surprising! Are you using the same compiler-version as you used with SDK 2.2.0?
Are you able to checkout/install the SDK 2.2.0 to a separate directory, and still build your project successfully? Can you see if any of the compiler or linker flags are different when building with SDK 2.2.0 versus building with SDK 2.3.0? (Also, which platform and OS are you building on?)

[kilograham]

Yeah; there should be no massive (or indeed even much of any) increase in RAM usage - I have seen some accounting differences w.r.t. scratch RAM where data overlaid what was set aside for stack. Still this is not the issue here.

I would

1. get the .map file from the old build
2. get the .map file from the new build to compare. Note you may have to remove/adjust the RAM limit in the linker script to get this to work, and possibly disable picotool (otherwise the failed build may delete the output files)

@will-v-pi what is the easiest way to make changes for 2 - i think you can do both via CMake defines now!

[will-v-pi]

@will-v-pi what is the easiest way to make changes for 2 - i think you can do both via CMake defines now!

Add this before add_executable(<target_name>) in CMakeLists.txt

set(PICO_NO_PICOTOOL 1)

and add this after add_executable (you need to move scratch x/y to prevent overlaps, in addition to increasing ram length)

pico_set_linker_script_var(<target_name> RAM_LENGTH 0x90000)
pico_set_linker_script_var(<target_name> SCRATCH_X_ORIGIN 0x20090000)
pico_set_linker_script_var(<target_name> SCRATCH_Y_ORIGIN 0x20091000)

[shtirlic]

@lurch yes, switched to 2.2.0 tag and it builds just fine.
Toolchain is the same (https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/tag/v15.2.0-1)

Here is the gist with map with 3 map files, 2.2.0, 2.3.0 and with RAM override https://gist.github.com/shtirlic/9838bfb535ef32cf778209ec06a63f7f

Host is Arch and platform x86_64, zen4

Linux proteus 7.1.2-zen3-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Fri, 03 Jul 2026 23:25:06 +0000 x86_64 GNU/Linux

My cmake file is https://github.com/shtirlic/picocalc_x86/blob/main/CMakeLists.txt

BTW, are there some big changes to macros for time_crit/inline defs? I see warnings for Ian Scott psram lib

[build] Memory region         Used Size  Region Size  %age Used
[build]            FLASH:      421484 B         4 MB     10.05%
[build]              RAM:      513388 B       512 KB     97.92%
[build]        SCRATCH_X:        3456 B         4 KB     84.38%
[build]        SCRATCH_Y:          32 B         4 KB      0.78%


[build] Memory region         Used Size  Region Size  %age Used
[build]            FLASH:      417528 B         4 MB      9.95%
[build]            PSRAM:           0 B          0 B
[build]          XIP_RAM:           0 B        16 KB      0.00%
[build]              RAM:      569332 B       512 KB    108.59%
[build]        SCRATCH_X:        3456 B         4 KB     84.38%
[build]        SCRATCH_Y:          32 B         4 KB      0.78%

[will-v-pi]

It looks like the big change is due to a bug fix in the linker scripts - there was a missing space between *libc.a: and *lib*_a-mem*.o which meant that the memory functions (memcpy etc) that were intended to be placed in RAM were actually being placed in FLASH. In 2.3.0 this was fixed by adding a space between them, so that they are now placed in RAM, and it looks like that accounts for most of the RAM usage increase in your binary.

You can override that change by creating a folder containing files called default_text_excludes.incl and default_rodata_excludes.incl, copied from src/rp2_common/pico_standard_link/script_include/default_text_excludes.incl, and then delete the *libc.a: from both to place those functions back in FLASH. Then add this to your CMakeLists.txt to use that folder to override the default files:

pico_add_linker_script_override_path(<target_name> ${CMAKE_CURRENT_LIST_DIR}/<folder> FILES default_text_excludes.incl default_rodata_excludes.incl)

@kilograham it might be worth revisiting whether this new behaviour is what we want, given it is now placing a lot more code in RAM in addition to memcpy - the change was this dc3a2e8

[shtirlic]

Yes, back to normal, thank you.

[build] Memory region         Used Size  Region Size  %age Used
[build]            FLASH:      417696 B         4 MB      9.96%
[build]            PSRAM:           0 B          0 B
[build]          XIP_RAM:           0 B        16 KB      0.00%
[build]              RAM:      513712 B       512 KB     97.98%
[build]        SCRATCH_X:        3456 B         4 KB     84.38%
[build]        SCRATCH_Y:          32 B         4 KB      0.78%

[lurch]

@kilograham it might be worth revisiting whether this new behaviour is what we want, given it is now placing a lot more code in RAM in addition to memcpy - the change was this dc3a2e8

Or least make it configurable, so that it's easier to opt-out of the mem-functions-in-ram behaviour without having to create custom linker scripts? 🤔

[shtirlic]

Configurable option would be ideal(since it's almost ~10% of current SRAM on pico 2) while I am still waiting for next pico with 1MB of SRAM ;)

[will-v-pi]

I've raised #3075 to fix this, which only places mem functions in RAM (taking up ~800 bytes of space), rather than all on libc.a. I don't think that needs to be configurable, as it's only 800 bytes (rather than the current 40kB).

While investigating, I discovered that libc.a is only linked when PICO_DEBUG_INFO_IN_RELEASE=0 on my regular Arm build, otherwise libg.a is linked instead (which caused the original issue where mem functions were left in Flash) - @shtirlic do you set PICO_DEBUG_INFO_IN_RELEASE=0 in your project?

EDIT: It looks like the RIsc-V toolchains don't do the libc.a/libg.a substitution, so you're probably hitting this bug without needing to change PICO_DEBUG_INFO_IN_RELEASE, whereas Arm toolchains generally do use the substitution, hence Arm builds don't hit this bug without PICO_DEBUG_INFO_IN_RELEASE=0

[shtirlic]

Yes, I do not set the PICO_DEBUG_INFO_IN_RELEASE=0, so as you said this is toolchain difference.