Question about UART freeze when using CONFIG_LOG_BACKEND_FS on nRF5340 DK

[ayumin]

Hello Nordic team,

I am using an nRF5340 DK with Zephyr, and I am facing an issue where the UART console freezes whenever CONFIG_LOG_BACKEND_FS=y is enabled.

My logging configuration is:

# LOGGING
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y
CONFIG_LOG=y
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_DEFAULT_LEVEL=3
CONFIG_PRINTK=y
CONFIG_LOG_BACKEND_FS=y
CONFIG_LOG_BACKEND_FS_AUTOSTART=y
CONFIG_LOG_BACKEND_FS_FILE_SIZE=20960
CONFIG_LOG_BACKEND_FS_FILES_LIMIT=1
CONFIG_LOG_BUFFER_SIZE=8192
CONFIG_LOG_BACKEND_FS_DIR="/lfs"

With the FS backend enabled, UART output stops during runtime.
If I disable the FS backend, UART works normally.

I would like to keep FS logging enabled, so I would like to know how to configure Zephyr or the nRF5340 to avoid UART freeze when using LOG_BACKEND_FS.
In other words, what settings or best practices can ensure stable UART output while FS logging is active?

Thank you.

[Kazi Afroza Sultana]

Hello,

I have run your sample on nRF5340DK. With or without this config CONFIG_LOG_BACKEND_FS=y in the prj.conf file I can get output on the UART terminal following output

then I was now concerned about stack overflow. 

After adding these two configuration 

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_MAIN_STACK_SIZE=4096

I got the correct output. 

You can try to do that and let me know the result

Thanks

[ayumin]

Hello Kazi,

Thank you very much for your previous suggestions regarding the stack sizes (CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE and CONFIG_MAIN_STACK_SIZE). While those specific changes didn't resolve our UART freeze directly, they helped us narrow down the root cause of the issue.

We have identified that the problem was a mismatch between the software-requested log capacity and the physical partition size defined in the devicetree.

Our Findings:

In our prj.conf, we initially requested a total log capacity of approximately 102.3 KB ($20,960\text{ bytes}\times 5\text{ files}$):

# LOGGING
CONFIG_LOG_BACKEND_FS=y
CONFIG_LOG_BACKEND_FS_FILE_SIZE=20960
CONFIG_LOG_BACKEND_FS_FILES_LIMIT=5

However, the default storage_partition for the nRF5340 DK is only 32 KB (reg = <0xf8000 0x8000>). When we tested reducing CONFIG_LOG_BACKEND_FS_FILE_SIZE to 16384, the logs began to display correctly because the total volume fit within the physical limits.

Current Solution:

To support our requirement of 128 KB of storage, we created a devicetree overlay to "make room" by shrinking the application slots (slot0 and slot1). Both slots were reduced from the default 464 KB to 416 KB to maintain symmetry for MCUboot.

nrf5340dk_nrf5340_cpuapp.overlay:

&flash0 {
    partitions {
        /* Resize slot0 from 464 KB to 416 KB (0x68000) */
        slot0_partition: partition@10000 {
            label = "image-0";
            reg = < 0x00010000 0x00068000 >;
        };

        /* Delete and relocate slot1 to match slot0 size (416 KB) */
        /delete-node/ partition@84000;
        slot1_partition: partition@78000 {
            label = "image-1";
            reg = < 0x00078000 0x00068000 >; 
        };

        /* Delete old 32 KB node and expand storage to 128 KB (0x20000) */
        /delete-node/ partition@f8000;
        storage_partition: partition@e0000 {
            label = "storage";
            reg = < 0x000e0000 0x00020000 >;
        };
    };
};

Questions for you:

1. Risk of Shrinking Slots: By reducing slot0 and slot1 to 416 KB, are there any long-term risks regarding MCUboot stability or future Zephyr SDK updates that we should be aware of?

2. Symmetry for MCUboot: We kept slot0 and slot1 at the exact same size to ensure compatibility with MCUboot "Swap" upgrades. Is this the recommended approach when repartitioning internal flash?

3. Alternative Solutions: Are there better best practices for increasing storage capacity on the nRF5340 DK (e.g., using the external flash on the DK via QSPI) that would avoid shrinking the primary application slots?

Thank you for your time and expertise!

[Kazi Afroza Sultana]

Hello,

You are welcome.

For your recent queries about mcuboot and alternative solutions I have feedback from the team.

1. Risk of Shrinking Slots: By reducing slot0 and slot1 to 416 KB, are there any long-term risks regarding MCUboot stability or future Zephyr SDK updates that we should be aware of?

We strive to keep the core parts of the SDK as small as possible, so in general applications should not increase in size between updates. So, it is good to have some extra space available, then you have the option to add future features to your own application. 

2. Symmetry for MCUboot: We kept slot0 and slot1 at the exact same size to ensure compatibility with MCUboot "Swap" upgrades [Conversation History]. Is this the recommended approach when repartitioning internal flash?

MCUboot has a hard requirement on that its slot has the same sizes for SWAP upgrades.

 3. Alternative Solutions: Are there better best practices for increasing storage capacity on the nRF5340 DK (e.g., using the external flash on the DK via QSPI) that would avoid shrinking the primary application slots?

For the nRF5340DK, external flash is frequently used when we need more flash. For example, this is what we do when we enable FOTA in Simultaneous updates for both cores of the nRF5340.

[ayumin]

Thank you for the clear answers to my questions and for providing the link regarding simultaneous updates.

It is very helpful to confirm that keeping slot0 and slot1 at the same size is a hard requirement for MCUboot SWAP upgrades. We also understand the trade-off regarding application space for future features.

Following your recommendation, I will test using the external QSPI flash on the nRF5340 DK for our logging backend. 

With this, I have all the information I need to proceed. I will close this thread now.

Thank you again for your great support!

Best,

[Kazi Afroza Sultana]

Hello,

Thanks for letting me know.

Happy to help.

BR
Kazi