SPI4 on nRF5340 not working when using k_sleep() in main

[alexsven]

Describe the bug
When building a release build with no serial, no debug etc. I've noticed that SPI4 won't work if there is a k_sleep() in main. I know this is a very special edge case, but it could be part of a larger issue.

The bug can be seen using a logic analyzer connected to:
MOSI: P0.09
MISO: P0.10
SCK: P0.08
CS: P0.011

When the k_sleep is present, only the CS-pin toggles

When swapping out SPI4 with SPI1/SPI2/SPI3 everything works, if I use a k_busy_wait() instead of a k_sleep() it also works. And if any sort of debug features are enabled (like serial, debug, log etc) it also works.

To Reproduce
I've attached a very simple sample here so that it can be reproduced with a nRF5340DK (I used a 0.11.0 version)
spi_fail.txt <-- rename to spi_fail.patch
So all is needed is to apply the patch, run:
west build -b nrf5340dk_nrf5340_cpuapp
and
west flash

I'm testing this in zephyr hash ebfe9be, but I have also verified on latest master (e2068d1). If using latest master CONFIG_OBJECT_TRACING=n must be removed from prj.conf

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[koffes]

AFAIK this issue is still present. Please remove stale label.

[carlescufi]

This is valid, running this internally first.

[carlescufi]

A workaround PR will be posted soon by @anangl.

[anangl]

After #37632 has been merged, I can no longer reproduce this issue using main. Specifically, commit 2a199af seems to be preventing it. When I revert this commit, the issue appears again.
@alexsven or @koffes could you confirm this?

[carlescufi]

Closing this as per @anangl's last comment. Please reopen if this reappears.