[nRF52840 DK] SPI transaction interrupted by ISR ?

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

AnomalySmith — Fri, 14 Oct 2022 08:49:15 GMT

Finally, I managed to fix the issue by changing the driver implementation and using the lib :

#include <nrfx_spim.h>
// instead of
#include <drivers/spi.h>

Doing so permitted to also specify a Data Control pin that nrf_spim will handle in one transaction (CMD + DATA in one tx buffer).

This fixed the SPI sending sometimes the previous buffer data from the previous SPI tx call concatenated with the new data.

The second issue was that the data filled by LVGL wasn't correct (some text character was disappearing on some frames) was fixed by compiling the used font without subpixel rendering.

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

Kenneth — Sun, 09 Oct 2022 16:56:00 GMT

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

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

AnomalySmith — Fri, 07 Oct 2022 15:48:33 GMT

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

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

AnomalySmith — Fri, 07 Oct 2022 09:33:56 GMT

[quote userid="2111" url="~/f/nordic-q-a/92599/nrf52840-dk-spi-transaction-interrupted-by-isr/389717"]CONFIG_LV_DISP_DEF_REFR_PERIOD[/quote]

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)

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

Kenneth — Thu, 06 Oct 2022 20:56:05 GMT

Does reducing the display refresh rate help?

CONFIG_LV_DISP_DEF_REFR_PERIOD=50

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

hmolesworth — Thu, 06 Oct 2022 15:44:37 GMT

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.

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

AnomalySmith — Thu, 06 Oct 2022 10:00:36 GMT

I just tried adding 1ms delay between these lines and also next to spi_write_dt: without success.

For now, I only think of LVGL having something to do with this weird problem

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

Kenneth — Thu, 06 Oct 2022 09:36:12 GMT

[quote user="kme"]gpio_pin_set_dt(&config->dc_gpio, 1);
errno = spi_write_dt(&config->bus, &tx_bufs_cmd);
gpio_pin_set_dt(&config->dc_gpio, 0);[/quote]

If you (for debugging) just add some delay between these lines, can you see the same symptoms? I am just trying to understand (since SPI data is not altered during SPI transmission) what delay is causing the problem.

Kenneth

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

AnomalySmith — Thu, 06 Oct 2022 08:52:21 GMT

Thanks for your reply again, only the first thread is updating data as the second reads them and is responsible from SPI transaction (calling LVGL's related functions). Also, mutexes are used in order to guaranty the integrity of data while accessing them.

The buffer size is handled by the call (by LVGL lib) to the writes related functions through the SSD1333 driver (default display declared in overlay dts file) :

static inline int ssd1333_write_bus(const struct device *dev, BYTE cmd, BYTE *buf, size_t data_len) {
  // printk("[SSD1333] WRITE BUS\n");
  const struct ssd1333_config *config = dev->config;

  int errno;

  BYTE cmd_buf[] = {cmd};

  struct spi_buf tx_buf_cmd = {
    .buf = cmd_buf,
    .len = 1
  };

  struct spi_buf_set tx_bufs_cmd = {
    .buffers = &tx_buf_cmd,
    .count = 1
  };

  gpio_pin_set_dt(&config->dc_gpio, 1);
  errno = spi_write_dt(&config->bus, &tx_bufs_cmd);
  gpio_pin_set_dt(&config->dc_gpio, 0);

  if(!buf || data_len < 1) {
    return errno;
  }

  struct spi_buf tx_buf = {
    .buf = buf,
    .len = data_len
  };

  struct spi_buf_set tx_bufs = {
    .buffers = &tx_buf,
    .count = 1
  };

  errno = spi_write_dt(&config->bus, &tx_bufs);

  return errno;
}

int ssd1333_write(const struct device *dev, const uint16_t x, const uint16_t y,
        const struct display_buffer_descriptor *desc,
        const void *buf) {
  // printk("[SSD1333] WRITE\n");
  size_t buf_len;

  if(desc->pitch < desc->width) {
    LOG_ERR("Pitch is smaller than width");
    return -1;
  }

  buf_len = desc->buf_size; // / 8 ???
  if(buf == NULL || buf_len == 0U) {
    LOG_ERR("Display buffer is not available");
    return -1;
  }

  if(desc->pitch > desc->width) {
    LOG_ERR("Unsupported mode");
    return -1;
  }

  // if((y & 0x7) != 0U) {
  //   LOG_ERR("Unsupported origin y %u", y);
  //   return -1;
  // }

  /* Check we do not overflow x or y from buffer display_buffer_descriptor */
  struct display_capabilities capabilities;
  display_get_capabilities(dev, &capabilities);

  if((x + desc->width) > capabilities.x_resolution) {
    LOG_ERR("Unsupported origin x %u with buffer width setled to %u (screen overflow)", x, desc->width);
    return -1;
  }

  if((y + desc->height) > capabilities.y_resolution) {
    LOG_ERR("Unsupported origin y %u with buffer height setled to %u (screen overflow)", y, desc->height);
    return -1;
  }

  LOG_WRN("x %u, y %u, pitch %u, width %u, height %u, buf_len %u",
    x, y, desc->pitch, desc->width, desc->height, buf_len);

  BYTE x_range[] = {SSD1333_DATA_ADDR_RANGE_X[0] + x, SSD1333_DATA_ADDR_RANGE_X[0] + x +(desc->width - 1)};
  BYTE y_range[] = {SSD1333_DATA_ADDR_RANGE_Y[0] + y, SSD1333_DATA_ADDR_RANGE_Y[0] + y + (desc->height - 1)};

  // uint32_t total_rows = y2 - y1;
  // uint32_t total_cols = x2 - x1;

  if(ssd1333_write_bus(dev, SSD1333_CMD_SETCOLUMN, x_range, sizeof(x_range)) || ssd1333_write_bus(dev, SSD1333_CMD_SETROW, y_range, sizeof(y_range))) {
    LOG_ERR("Failed to write command");
    return -1;
  }

  ssd1333_write_bus(dev, SSD1333_CMD_WRITEINTORAM, (BYTE *)buf, buf_len);

  return 0;
}

[...]

static struct display_driver_api ssd1333_driver_api = {
  .blanking_on = ssd1333_blanking_on,
  .blanking_off = ssd1333_blanking_off,
  .write = ssd1333_write,
  .read = ssd1333_read,
  .get_framebuffer = ssd1333_get_framebuffer,
  .set_brightness = ssd1333_set_brightness,
  .set_contrast = ssd1333_set_contrast,
  .get_capabilities = ssd1333_get_capabilities,
  .set_pixel_format = ssd1333_set_pixel_format,
  .set_orientation = ssd1333_set_orientation
};

#define SSD1333_DEFINE(inst)                                                \
  static const struct ssd1333_config ssd1333_config_##inst = {              \
    .bus = SPI_DT_SPEC_INST_GET(                                            \
      inst, SPI_OP_MODE_MASTER | SPI_TRANSFER_MSB | SPI_WORD_SET(8), 0),    \
    .dc_gpio = GPIO_DT_SPEC_INST_GET(inst, data_ctrl_gpios),                \
    .reset_gpio = GPIO_DT_SPEC_INST_GET(inst, reset_gpios),                 \
    .width = DT_INST_PROP(inst, width),                                     \
    .height = DT_INST_PROP(inst, height),                                   \
  };                                                                        \
                                                                            \
  static struct ssd1333_data ssd1333_driver_data_##inst;                    \
                                                                            \
  DEVICE_DT_INST_DEFINE(inst,                                               \
                        ssd1333_init,                                       \
                        NULL,                                               \
                        &ssd1333_driver_data_##inst,                        \
                        &ssd1333_config_##inst,                             \
                        POST_KERNEL, CONFIG_DISPLAY_INIT_PRIORITY,          \
                        &ssd1333_driver_api);

DT_INST_FOREACH_STATUS_OKAY(SSD1333_DEFINE)

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

Kenneth — Thu, 06 Oct 2022 07:46:18 GMT

[quote user="AnomalySmith"]Then, another thread is fed from this same queue and does computation before another updates periodically the view/display. [/quote]

Is it possible that this thread is doing any manipulation or update of the ongoing SPI buffer used by the:

gpio_pin_set_dt(&config->dc_gpio, 1);
errno = spi_write_dt(&config->bus, &tx_bufs_cmd);
gpio_pin_set_dt(&config->dc_gpio, 0);

Maybe try to double buffer the SPI data before spi_write_dt()?

Kenneth

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

AnomalySmith — Thu, 06 Oct 2022 07:15:20 GMT

Kenneth I don't think so, when I probe the different channels signals are all clean. I also reduced the SPI clock frequency to see if it changes something but not really.

And yes, your understanding is right, the ISR is just putting a value in a message queue. Then, another thread is fed from this same queue and does computation before another updates periodically the view/display.

Removing the interrupt only get rid of the issue even having the trigger signal on.

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

AnomalySmith — Thu, 06 Oct 2022 07:08:07 GMT

hmolesworth Yes, my first driver implementation was using nrfx_spim.h and nrf_spim_* functions but now I would like to maximize the compatibility for other platforms using drivers/spi.h.

I don't think there is the same functionality in this lib, right ?

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

hmolesworth — Wed, 05 Oct 2022 22:19:36 GMT

Rather than using a gpio pin manually to switch between command/data perhaps use the SPIM DCX functionality which does this for you in hardware:

spi_config.dcx_pin = data_control_pin;

6.25.2 D/CX functionality
Some SPI slaves, for example display drivers, require an additional signal from the SPI master to distinguish between command and data bytes. For display drivers this line is often called D/CX. SPIM provides support for such a D/CX output line. The D/CX line is set low during transmission of command bytes and high during transmission of data bytes. The D/CX pin number is selected using PSELDCX on page 423 and the number of command bytes preceding the data bytes is configured using DCXCNT on page 424. It is not allowed to write to the DCXCNT on page 424 during an ongoing transmission

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

Kenneth — Wed, 05 Oct 2022 18:42:39 GMT

Are you sure you don't have any electrical problems, that you have poor grounding or similiar?

Do I understand it correctly that your ISR does not trigger any SPI transfer? In other words the ISR does not directly/indirectly affect the transfer of SPI (other than the potential delay it may cause).

Kenneth

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

AnomalySmith — Wed, 05 Oct 2022 12:47:45 GMT

I just probed on MOSI and, so far I can tell, it doesn't seem to be affected indeed.

And I don't have any of CONFIG_SPI_0_NRF_SPIM or CONFIG_SPI_0_NRF_SPI settled in the project. How to be sure EasyDMA is effectively used ?

Anyway I tried shutting down some non-critical applicative threads and it doesn't change anything, artifacts still there when heavy ISR calls.

EDIT:

I also noticed some SPI data may be interpreted as SPI command one (causing random behaviors like inverting the display color, etc.). Looking into the driver, the gpio for data_control pin is handled manually using gpio_pin_set_d before and after spi_write_dt for data command:

  gpio_pin_set_dt(&config->dc_gpio, 1);
  errno = spi_write_dt(&config->bus, &tx_bufs_cmd);
  gpio_pin_set_dt(&config->dc_gpio, 0);

May it cause issues if process is preempted over there?

RE: [nRF52840 DK] SPI transaction interrupted by ISR ?

Kenneth — Wed, 05 Oct 2022 12:12:21 GMT

Hello,

Have you been able to observe how the interrupts affects the SPI transfer on an logic analyzer?

I do not see any reason why a frequent pin interrupt should affect the SPI transfer, because once SPI transfer is started it will transfer continously the amount of byte in one chunk (through EasyDMA), unless you have disabled EasyDMA, and thereby using interrupt based SPI transfer. Maybe you can comment whether CONFIG_SPI_0_NRF_SPI or CONFIG_SPI_0_NRF_SPIM is used in your project?

Kenneth