cancel
Showing results for 
Search instead for 
Did you mean: 

STM32N6: Expected DMA/SPI Performance

Jeija
Associate

Hi,

I am working on an application for the STM32N6 (using zephyr) that streams data from four SPI interfaces (SPI1, SPI2, SPI3 and SPI6) via Ethernet (UDP). I am using full-duplex SPI transfers and GPDMA1.

Everything works fine up to SPI clock frequencies of 22MHz on all four SPI interfaces. However, as soon as I increase the SPI clock to beyond 25MHz, I start getting DMA transfer errors and erroneous data in my buffers. Obviously, 22MHz full-duplex on four SPI interfaces is already quite fast, but if possible, I would like to go beyond that.

I know that Ethernet is not the bottleneck here, since this happens even if I do not stream all data over Ethernet.

I was just wondering: Is this performance expected, e.g., due to the high load on the memory bus? What measured could I take to increase performance further?

Thanks for your help!

1 ACCEPTED SOLUTION

Accepted Solutions
TDK
Super User

The DMA bandwidth is not specified as it would be incredibly hard to calculate. Best way is to increase speed til it breaks to see what is achievable. Clock speeds and bus widths are specified and you can use those to guide your expectations.

> What measured could I take to increase performance further?

Enabling the FIFO and burst transfers will help quite a bit. The bus takes a hit due to overhead whenever the priority shifts from one stream to another. This reduces the number of times that happens.

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

1 REPLY 1
TDK
Super User

The DMA bandwidth is not specified as it would be incredibly hard to calculate. Best way is to increase speed til it breaks to see what is achievable. Clock speeds and bus widths are specified and you can use those to guide your expectations.

> What measured could I take to increase performance further?

Enabling the FIFO and burst transfers will help quite a bit. The bus takes a hit due to overhead whenever the priority shifts from one stream to another. This reduces the number of times that happens.

If you feel a post has answered your question, please click "Accept as Solution".