SPI Timeout waiting for transfer complete

[Moe1992]

Hi everyone,

I am evaluating the nRF54L15DK. Currently I'm trying to get SPI to work. For testing, I got an OLED Module with 4-wire SPI and an SSD1351 driver.

I wrote a small program to test SPI communication. The program fills the whole RAM of the OLED with one color and switches between different colors every few seconds. I will attach the project to this thread.

The problem I'm facing is twofold:

1. When running the program as attached, the OLED display is updated correctly but via UART I receive multiple error messages saying <err> spi_nrfx_spim: Timeout waiting for transfer complete with each display update routine.
2. In this "working" instance I have set CONFIG_LOG_MODE_IMMEDIATE=y
   If I comment out this line, no logs are ever received and transfer of the SPI buffer ends after a few bytes (~100). This is seen by the OLED only changing the first few pixels on the first line.

What is the proper way to make logging possible while not receiving the timeout errors from SPI?

Other forum entries suggest that the GPIOs I am using for SPI are already used by something else, but I think I disabled the relevant peripherals with:

&uart30 {
	status = "disabled";
};

Thank you and BR,

Moritz

SPI_timeout.7z

[Moe1992]

Well I seem to have found a solution, but I'm curious if someone could explain why this works exactly:

1. Do not include CONFIG_LOG_MODE_IMMEDIATE=y in the prj.conf.
2. Submitting the SPI calls to a work item gets rid of the timeout errors. Why?
3. But then I won't receive log messages. This is resolved by having k_msleep(10); instead of k_yield(); in the main while loop.

Thanks

[Kenneth]

Hi, I havent had  a chance to look into this yet, will do later this week.

Kenneth

[Kenneth]

Hello,

Likely you should be using CONFIG_LOG_MODE_DEFERRED=y instead of CONFIG_LOG_MODE_IMMEDIATE=y. Because when you use immediate it will indirectly increase the timing of the spi transfer, and the time the spi should execute is calculated run-time based on the speed and length. 

For logging check out: https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-3-printing-messages-to-console-and-logging/ 

Kenneth

[Moe1992]

Thank you. In my own reply I have layed out a solution which uses the deferred mode. Could you elaborate on why my solution works? Is it best practice to submit the SPI calls to the system workqueue?