spi_loopback test fails on MCUs with SRAM blocks smaller than 128KB

[ttmut]

Describe the bug
#69081 increases RAM usage by an extra ~100KB, causing .bss section overflows on devices with small memories. I have encountered this on an out-of-tree Arm Cortex M4 board however I expect similar results with other boards.

The PR adds below buffers that I suspect are the cause of overflows.

#define BUF3_SIZE 8192
...
static const char large_tx_data[BUF3_SIZE] = "Thequickbrownfoxjumpsoverthelazydog\0";
static __aligned(32) char large_buffer_tx[BUF3_SIZE] __used __NOCACHE;
static __aligned(32) char large_buffer_rx[BUF3_SIZE] __used __NOCACHE;
...
static uint8_t large_buffer_print_tx[BUF3_SIZE * 5 + 1];
static uint8_t large_buffer_print_rx[BUF3_SIZE * 5 + 1];

Expected behavior
Test should compile successfully.

Logs and console output

...
.../arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: region `RAM' overflowed by 58432 bytes
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' --build
...

Environment (please complete the following information):

• OS: Windows
• Toolchain: Zephyr SDK 0.16.3

[github-actions]

Hi @ttmut! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[tbursztyka]

@krish2718 Can you look at it? (perhaps make the test optional via a dedicated option into tests/drivers/spi/spi_loopback/Kconfig )

[krish2718]

I can make BUF3 configurable and add a min_ram in twister for larger tests for 8192, so, that lower memory boards are skipped.

[erwango]

I think you should add a new test variant "long-transfer" that enable BUF3 testing using a dedicated Kconfig flag

[krish2718]

I think you should add a new test variant "long-transfer" that enable BUF3 testing using a dedicated Kconfig flag

Sure, but instead of conditional test at build time, if I can make BUF3 as default say 128 it would server as a 3rd test, and for those boards that have higher memory, we can run with 8192, this would still be a build time option, but the tests would be constant. WDYT?

[erwango]

ok, that should be fine too indeed

[krish2718]

Looking at the code, the buffer itself is only 8K, it's the buffers used printing the diff that take up too much memory, and for a large buffer it's not that useful, so, I guess we can just remove the display part for large buffer and it should run on all platforms? If there is a fundamental issue then small buffer's diff can be used for debugging.

@ttmut can you please share a build command or board name that reproduces the build overflow?

[ttmut]

It's an out-of-tree board but you can check the resource usage summary to get an idea. I have not tested on another board.

west build -p -b board_desc .\tests\drivers\spi\spi_loopback

Below is the memory usage summary of another out-of-tree board that has enough RAM:

Memory region         Used Size  Region Size  %age Used
           FLASH:       49980 B         3 MB      1.59%
             RAM:      108096 B       128 KB     82.47%
        IDT_LIST:          0 GB        32 KB      0.00%

If I eliminate print buffers, RAM usage becomes ~26KB:

Memory region         Used Size  Region Size  %age Used
           FLASH:       49980 B         3 MB      1.59%
             RAM:       26432 B       128 KB     20.17%
        IDT_LIST:          0 GB        32 KB      0.00%

This would be enough to solve my case. However, if there are boards with less than ~26KB memory it could still be an issue. I am not sure if there are though.

[krish2718]

Well, let's start with that as its a simple fix, and even the last time CI had passed, and having extra 8K buffer for a test is reasonable. Will raise a PR, thanks.

[ttmut]

Thanks for looking into this, @krish2718