Stm32 SPI write/read large delay between bytes

[Huibean]

when porting a application from cubemx to zephyr, the spi sensor always not recognize the command sent from host, while in cubexmx is working, using the logic anlayize to record the data in SPI bus, the data is the same, but in zephyr there is about 2us betweent bytes, so I create a new baisc spi example project to test it and confirm this issue is not comming from other code, test is on stm32h743zi-nucleo without changes only, I have also test on a F411 board, the issue is the same, zephyr version is 3.6.0, SDK version 0.16.6
in .prj

CONFIG_SPI=y
CONFIG_SPI_STM32=y

test code

#include <zephyr/kernel.h>
#include <zephyr/device.h>
#include <zephyr/devicetree.h>
#include <zephyr/drivers/spi.h>

#define SPI_DEV DT_NODELABEL(spi1)  // Adjust this to your SPI device
#define BUF_SIZE 10

void main(void)
{
    const struct device *spi_dev = DEVICE_DT_GET(SPI_DEV);;
    if (!spi_dev) {
        printk("Could not find SPI device\n");
        return;
    }

    uint8_t tx_buf[BUF_SIZE] = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A};
    struct spi_buf tx = {
        .buf = tx_buf,
        .len = BUF_SIZE,  
    };
    struct spi_buf_set tx_bufs = {
        .buffers = &tx,
        .count = 1,
    };

    struct spi_config spi_cfg = {
        .frequency = 30000000, 
        .operation = SPI_WORD_SET(8) | SPI_TRANSFER_MSB,
        .slave = 0,
        .cs = NULL,
    };

    int ret = spi_write(spi_dev, &spi_cfg, &tx_bufs);
    if (ret != 0) {
        printk("SPI write failed: %d\n", ret);
    }
}

[erwango]

@ajarmouni-st ^^

[ajarmouni-st]

Hi @Huibean, in your STM32 Cube application , are you using SPI with/without DMA, with/without DMA/SPI IT?

[Huibean]

Without DMA and Interupt Abderrahmane ***@***.***>于2024年6月12日 周三17:07写道：

…

Hi @Huibean <https://github.com/Huibean>, in your STM32 Cube application , are you using SPI with/without DMA, with/without DMA/SPI IT? — Reply to this email directly, view it on GitHub <#73930 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACY7IIKBVCB2PC54EQJRT6DZHAFVHAVCNFSM6AAAAABI63GHMGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TONBZGE4TM> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[ndrs-pst]

@erwango Compared to STM32Cube, which fills the FIFO before enabling the interrupt, the current implementation in Zephyr fills the FIFO one frame at a time, leading to the 2 µs gap between ISR executions—please correct me if I misunderstood. 🤔

https://github.com/STMicroelectronics/stm32h7xx_hal_driver/blob/ceda3ceeca2ee77a76d2de2ee6b560ad87c90a48/Src/stm32h7xx_hal_spi.c#L1899-L1930

[ndrs-pst]

@flabou Guest you already notice my comment?

[flabou]

Sorry,
I participated in the discussion because I noticed the same behavior, but I am not really involved in the driver code.
I can just say that I see a delay on nucleo_f767zi. At 6MHz the delay is 2.83us between first byte and second byte and 2us between the other bytes.

[flabou]

I observed similar behaviour. Long delay between bytes when using SPI. It was also with STM32, but I don't know if this is specific to the STM32 devices.
I got some helpful feedback on the discord channel. In the end, I was able to not have the delay by enabling DMA for SPI.

I also tried with the Arduino IDE as a comparison, and while it was not without delay, the delay was only 300ns (instead of around 1-2 us in Zephyr). I think this deserves some attention, as SPI is pretty important peripheral.

[erwango]

This should theoretically be tackled by RTIO API implementation. See #46658

[tbursztyka]

Looking closer to spi_stm32_shift_fifo(), it does not seem to top-off the TX FIFO nor emptying the RX one. I am no stm32 spi controller specialist but the behavior in that case is quite generic. Can you try by changing line 368 to:

while (ll_func_rx_is_not_empty(spi)) {

and line 372 to:

while (ll_func_tx_is_not_full(spi)) {

[flabou]

My line numbers don't match yours, and you made me realize I am still on Zephyr 3.6.0. I am very sorry that I haven't tried upgrading to zephyr 3.7.0 first. I did a diff on the file, and I see there definitely has been some change since v3.6.0. I will do the upgrade and test. Very sorry about that, should have done it commenting.

[flabou]

@tbursztyka I updated to Zephyr 3.7.0, delay is still present. I changed the lines as you requested. Delay still there too.

Also interesting:

• Delay is longer between first byte and second byte than between all the remaining bytes (e.g., at 6 MHz, 2.83us vs 2us. Between the last edge of the previous byte and the first edge of the next byte, measured on SCK).

[tbursztyka]

Sounds bad, fact that there is a gap between each bytes means it is still tx/rx a byte at a time. Perhaps playing with fifo threshold could help.
Comment above #73930 (reply in thread) is also true.

@erwango anyone on your side that could look at it? Not that this is a major issue since when using DMA it will work fine.

[erwango]

Not atm. Plan on SPI is to implement RTIO API, it won't solve the issue but offers an alternative solution and we don't have means today to do both.

[JarmouniA]

[flabou]

I'm used to git, but not to collaborative project on github, how to I checkout the specific to test?

[flabou]

Sorry for long delay, I just tried the branch dev_stm32_spi_async_dma, commit c0049be1d and it also didn't remove the delay, nor did it make it smaller.

[flabou]

Sorry there is confusion, I don't have delay with DMA even in normal branch. The delay happens when DMA is disabled.

[KurtE]

Any updates on this?

Sorry, I don't really have a complete answer other than I can say that I have seen these same delays.
I am playing with Arduino GIGA STMH747 and my initial attempts of using SPI, the performance has been not optimal to say the least.

Note: I am using the Arduino setup for zephyr (ArduinoCore-zephyr), Currently I am experimenting with a sketch that reads in from a GC2145 camera and tries to display it on an ST7796 display (480x320)

I have not included all of the code here, but the main part that outs all of the pixels looks like:

    struct spi_buf tx_buf = { .buf = (void*)pcolors, .len = (size_t)(w * 2) };
    const struct spi_buf_set tx_buf_set = { .buffers = &tx_buf, .count = 1 };
    for (y = h; y > 0; y--) {
      tx_buf.buf = (void*)pcolors;
      spi_transceive(_spi_dev, &_config16, &tx_buf_set, nullptr);
      pcolors += image_width;
    }

The code was initialized to use SPI speed of 16mhz...
With the above code, it takes about 2 seconds to output one frame.
Now if the SPI bus was 100% utilized with no gaps between bytes and the like we might get up to maybe 8-10 frames per second.

Today I hacked up my ST77XX code to try to output it using DMA.
And replace the above code with call to spi_transceive_cb
The main code looks like:

void ST77XX_zephyr::writeRectCB(int16_t x, int16_t y, int16_t w, int16_t h,
                 const uint16_t *pcolors, void (*callback)(int result)){
  beginSPITransaction();
  setAddr(x, y, x + w - 1, y + h - 1);
  writecommand_cont(ST77XX_RAMWR);
  setDataMode();
  struct spi_buf tx_buf = { .buf = (void*)pcolors, .len = (size_t)(w * h * 2) };
  const struct spi_buf_set tx_buf_set = { .buffers = &tx_buf, .count = 1 };
  _write_rect_cb = callback;
  spi_transceive_cb(_spi_dev, &_config16, &tx_buf_set, nullptr, &spi_callback, (void*)this);

}


void ST77XX_zephyr::process_spi_callback(const struct device *dev, int result) {
  // end spi transaction
  UNUSED(dev);
  endSPITransaction();

  if (_write_rect_cb) (*_write_rect_cb)(result);
}

With using this instead with a callback, the time it takes to output 1 frame
went from about 2 seconds to about 1/3 of a second.

The gap between words (16 bits each) went from about 5.76us to about 900ns.

not sure if it would help, but the Sketch looks like:

#include <ST77XX_zephyr.h>
#include "camera.h"

Camera cam;
#include <SPI.h>
#include <ST77XX_zephyr.h>
#include <ST77XX_zephyr_font_Arial.h>


#define TFT_CS   10  // CS & DC can use pins 2, 6, 9, 10, 15, 20, 21, 22, 23
#define TFT_DC    8  //  but certain pairs must NOT be used: 2+10, 6+9, 20+23, 21+22
#define TFT_RST   9  // RST can use any pin

#define CAMERA_WIDTH 480 //320
#define CAMERA_HEIGHT 320 // 240
ST7796_zephyr tft = ST7796_zephyr(&SPI1, TFT_CS, TFT_DC, TFT_RST);

void fatal_error(const char *msg) {
  Serial.println(msg);
  pinMode(LED_BUILTIN, OUTPUT);
  while (1) {
    digitalWrite(LED_BUILTIN, HIGH);
    delay(100);
    digitalWrite(LED_BUILTIN, LOW);
    delay(100);
  }
}

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(115200);
  while (!Serial && millis() < 5000) {}
  tft.init(320, 480);
  Serial.println("call cam.begin");
  if (!cam.begin(CAMERA_WIDTH, CAMERA_HEIGHT, CAMERA_RGB565, true)) {
    fatal_error("Camera begin failed");
  }
  Serial.println("Camera started");
  cam.setVerticalFlip(false);
  cam.setHorizontalMirror(false);
}

volatile bool write_rect_complete = false;
void write_rect_complete_cb(int result) {
  UNUSED(result);
  write_rect_complete = true;

}

bool use_writeRectCB = true;

void loop() {
  // put your main code here, to run repeatedly:
  FrameBuffer fb;
  //Serial.print("Call grabFrame");
  bool frame_received = cam.grabFrame(fb);
  //Serial.println(frame_received? " true" : " false");
  if (frame_received) {
    digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
    uint32_t start_time = micros();
    if (use_writeRectCB) {
      write_rect_complete = false;
      tft.writeRectCB(0, 0, CAMERA_WIDTH, CAMERA_HEIGHT, (const uint16_t*)fb.getBuffer(), &write_rect_complete_cb);
      while (!write_rect_complete) delay(1);
    } else {
      tft.writeRect(0, 0, CAMERA_WIDTH, CAMERA_HEIGHT, (const uint16_t*)fb.getBuffer());
    }
    Serial.println(micros()-start_time);
    //tft.writeSubImageRectBytesReversed(0, 0, 320, 240, 0, 0, 320, 240, (const uint16_t*)fb.getBuffer());
    //tft.writeSubImageRect(0, 0, 320, 240, 0, 0, 320, 240, (const uint16_t*)fb.getBuffer());
    cam.releaseFrame(fb);
  }
  if (Serial.available()) {
    while (Serial.read() != -1) {}
    use_writeRectCB = !use_writeRectCB;
  }
}

When I first tried using the spi_transceive_cb, in order to make it work, I know I had to enable some stuff in the .conf file.

CONFIG_DMA=y
CONFIG_MEMC=y
CONFIG_SPI_ASYNC=y
CONFIG_SPI_STM32_INTERRUPT=y

I am not sure if I added the first two, but I know I needed the last 2 to make it work.

Hope that helps

[GeorgeCGV]

@Huibean, did you try enabling fifo-enable?