Migration to NCS 3.2.4 causes pthread_attr_t error and RAM overflow with Picolibc

[Obaid ur Rehman]

Hi Nordic team,

We are currently migrating our project from nRF Connect SDK v3.1.1 to v3.2.4 on the nRF9160.

Our application was working without issues on v3.1.1. After upgrading to NCS 3.2.4, we encountered the following compilation error:

In file included from C:/ncs/v3.2.4/zephyr/include/zephyr/posix/time.h:62,
 from C:/ncs/v3.2.4/nrf/lib/date_time/date_time_modem.c:9:
C:/ncs/v3.2.4/zephyr/include/zephyr/posix/signal.h:102:9: error: unknown type name 'pthread_attr_t'
 102 | pthread_attr_t *sigev_notify_attributes;

After investigation, we determined that this issue is related to NEWLIB_LIBC no longer being supported in NCS 3.2.4. To resolve this, we switched to Picolibc.

However, enabling Picolibc introduced a new problem:

c:/ncs/toolchains/fd21892d0f/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: zephyr\zephyr_pre0.elf section `noinit' will not fit in region `RAM'
c:/ncs/toolchains/fd21892d0f/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: region `RAM' overflowed by 55008 bytes

This is significantly beyond our available memory budget and prevents the application from running.

We are enabling picolib using the following configs 

CONFIG_PICOLIBC=y

CONFIG_COMMON_LIBC_MALLOC=y

CONFIG_COMMON_LIBC_MALLOC_ARENA_SIZE=512

Any guidance or best practices for handling this migration would be greatly appreciated.

Thanks!

[Syed Maysum Abbas Zaidi]

Hi,

Thanks for sharing the ram_report. Looking at your NCS 3.1.1 build, your application is already using around 246KB out of 256KB of available RAM, leaving very little headroom. This means the RAM overflow in NCS 3.2.4 is not purely a Picolibc issue, but a result of the NCS 3.2 framework having a slightly larger footprint on an already near-full memory budget.

To fix this we need to profile and reduce your thread stack sizes. Please add the following to your prj.conf and run it on your NCS 3.1.1 build:

CONFIG_THREAD_ANALYZER=y
CONFIG_THREAD_ANALYZER_USE_PRINTK=y
CONFIG_THREAD_ANALYZER_AUTO=y
CONFIG_THREAD_NAME=y
CONFIG_INIT_STACKS=y

You may also read this guide that walks through exactly how to use the Thread Analyzer and reduce memory consumption: Memory Optimization with the nRF Connect SDK 

Based on your report, the largest consumers in your noinit section are your BLE thread stacks combined, net_buf_data_pkt_pool, and send_from_flash_to_cloud. The Thread Analyzer output will help to determine exactly how much each thread stack can be reduced.

Best Regard,
Syed Maysum