[nRF52840 DK] SPI transaction interrupted by ISR ?

[AnomalySmith]

Hi,

I've got a display driven over SPI at 8MHz by the lib LVGL in a dedicated Zephyr thread and an ISR configured on one gpio pin that triggers a short routine registering the rising edge of the signal (basically incrementing a var).

 

The used Zephyr SPI write method is from <drivers/spi.h> :

static inline int spi_write_dt(const struct spi_dt_spec *spec, const struct spi_buf_set *tx_bufs);

When the ISR is highly solicited (i.e. lots of pulses on gpio pin -> >1k/s ), I've noticed the display starts to show artifacts that isn't cleared if the drawn area position isn't dynamic.

I'm assuming it comes from the case where the ISR is called in the middle of the display SPI update transaction and some SPI data is shifted out during this time as the SCK still continues from hardware.

 

Is there a way to make sure the SPI transaction doesn't "freeze" in this kind of configuration ?

Thanks for your time !

[hmolesworth]

I assume you are using SPIM with DMA (ENABLE=7), and not SPI without DMA (ENABLE=1)  as the latter would make no sense for a display. If the driver doesn't support DCX you can add it after the initialisation; it is a hardware feature that can be  independent of the Nordic driver (in SPIM DMA mode):

APP_ERROR_CHECK(nrf_drv_spi_init(&spi, &spi_config, spi_event_handler, NULL));

// Set pin to an output first then set DCX registers

NRF_SPIM0->PSELDCX=pin; // Pin select for DCX signal

NRF_SPIM0->DCXCNT = 1; // This register specifies the number of command bytes preceding the
                       // data bytes. The PSEL.DCX line will be low during transmission of
                       // command bytes and high during transmission of data bytes. Value 0xF
                       // indicates that all bytes are command bytes.

[Kenneth]

Does reducing the display refresh rate help?

CONFIG_LV_DISP_DEF_REFR_PERIOD=50

[AnomalySmith]

Kenneth said:

CONFIG_LV_DISP_DEF_REFR_PERIOD

I already tried to play with this conf and unfortunately, no.

Doubling the buffer doesn't give much result but now since only one thread is modifying data and accessing to the display buffer (LVGL), it would be surprising otherwise.

I modified the driver to process only calls with exact specified matched coordinates and box size (known in advance) so I can observe only one portion of the screen that is updated by LVGL (i.e. one SPI display write RAM transaction). Results: I can also see artifacts inside the area between some frames.

But also still more disturbing: when left on long run, an artifact may appear on the outside left portion of the constrained drawn box (that shouldn't be drawn at all)

[AnomalySmith]

Some news: I managed to look deeper into the SPI transaction by probing the outputs and also on the display driver and found that seems to be two problems:

1. Input driver buffer on ssd1333_write is already containing what I call "artifacts" (like parts of text disappearing on some frames, from LVGL?) but again, this only occurs when ISR callback called multiple times ( >1k calls per second)

2. At some point, in the long run under these conditions, an artifact is drawn outside of the instructed area in the screen: I've noticed by probing the SPI transaction that the command to set the draw column cursor (0x15h) appears to be also in the first byte of the data part that comes right after the command (as shown in driver code earlier) and the rest of data is right shifted (end of data seems to be dropped, limited by original buffer size).

I'll try to change the driver write logic but this seems really strange...

[Kenneth]

I don't have any further suggestions sorry, but I am very interested in getting to know the root source of your problems once you find it.

Kenneth