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

[ttmut]

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

[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.

[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

[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?