[nRF52840 DK] SPI transaction interrupted by ISR ?

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 !
Parents
  • 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...

Reply
  • 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...

Children
No Data
Related