Performance Issues with SPI Data Collection Using HAL and DMA on STEVAL-PROTEUS1 Board

[sai_sankar_rao_R]

Hi all,

I am currently working with the STEVAL-PROTEUS1 Board, which incorporates the STM32WB5MMG module and the IIS3DWB high-bandwidth accelerometer sensor, interfaced via SPI_1.

According to the IIS3DWB sensor datasheet, it supports a clock frequency of up to 10MHz and an Output Data Rate (ODR) of 26667Hz (37 microseconds).

My objective is to collect sensor data at an ODR of 26667Hz.

Here are the steps I have taken so far:

1. Configured the core to 20MHz.
2. Configured SPI_1 to 10MHz.
3. Configured the sensor to generate an ODR interrupt, which is successfully triggering every 37 microseconds.

The issue arises when collecting data (6 bytes) from the sensor, which is taking 125 microseconds using HAL functions in blocking mode. Ideally, this should not be the case. I have also tried using non-blocking mode (DMA), but it is taking more time (175 microseconds).

Could anyone help me understand if the HAL function is supposed to take 125 microseconds, and why DMA is taking more time than the blocking mode? Or if there might be an issue with my implementation?

observations:

Timing table in microseconds
No of bytes receiving	Blocking mode	DMA
1	90	169
2	95	169
3	103	169
4	110	169
5	117	171
6	124	171
15	184	171
20	215	171

Please help me figure out if the behavior of DMA is expected or if I am doing something wrong. As far as I know, DMA is intended for fast transfer of bulk data in less time without using core resources.

Note: The M4 core is running at 20MHz and the M0 core at 10MHz.

Thank you in advance for your assistance!

[TDK]

Results seem reasonable.

For short transfers and high data rates, blocking mode can be faster than DMA. Particularly since interrupts are not involved. DMA mode calls a lot of interrupts and code takes time to complete and has more setup.

At a SPI clock rate of 10 MHz and a core clock rate of 20 MHz, you only have 16 ticks between bytes. That's not a lot. HAL is going to need more than that to keep up with the rate.

Probably will have to write your own code here. Interrupts at 27 kHz with a clock rate of only 20 MHz is doable, but will require some efficient programming. You should also consider non-interrupt based methods of reading out data using something like timers hooked up to SPI to generate the necessary clocks in response to an edge.