STM32L0 SPI and CS HAL Speed

[bwefers]

Hi there!

First time on the community, but have been programming with STM32s for some time now. I am currently facing a speed challenge using the HAL_SPI_Transmit() function. In order to toggle the CS line, I have always done something along the lines of:

HAL_GPIO_WritePin(GPIOA, GPIO_PIN_15, 0);
HAL_SPI_Transmit(&hspi1, bufSPI, 2, 200);
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_15, 1);

This has never given me any issues and always executed in a reasonable time frame. I recently migrated a project from STM32L152 to the STM32L071. Based on the datasheets, I understand there could be a roughly 30% speed decrease even with both running their system clocks at 32 MHz. However, this seems to have translated into a very large overhead on my SPI transactions (a lot more than 30%). What I am looking to see is if there is either a way to get the SPI driver to handle my CS line for me, or somehow reduce the overhead associated with a call to the HAL (I am not afraid to modify or bypass the HAL function if that would help). Below are some timing details.

The following are based on some bare bones firmware generated on CubeMX with a 32 MHz system clock and a SPI baud rate of 8 Mbit sending 16 bits of data (which by itself would take 2 us).

L1 total CS down time: 8.1 us
L0 total CS down time: 17.2 us

Timing split (CS down, data start, data end, CS up):
L1: 0, 4, 6, 8.1 us
L0: 0, 6.1, 8.1, 17.2 us

The peripheral requires the CS line to be toggled every 4 bytes, and I am sending each peripheral 12 bytes at a time (which I have to break into 3 calls to HAL_SPI_Transmit in order to toggle the CS), so if there is a way to consolidate the transactions so I only encounter the overhead once per peripheral that might be a good start.

Any ideas are very much appreciated, and let me know if there are more measurements or scope traces that would help. Thanks!

[TDK · Accepted solution]

HAL_GPIO_WritePin doesn't have much overhead. Your overhead is coming primarily from HAL_SPI_Transmit.

If speed is an issue, but you can still perform transactions in blocking mode, use the SPI peripheral register access directly. It's not terribly complicated, the RM has explicit instructions on how to handle this.

You can also compile in Release mode, if you're not already, which has higher optimizations and will run a bit faster.

There's no way to get the SPI peripheral to control the CS exactly like you want. There are more exotic solutions with timers and DMA to control these lines if you can change the hardware.

[bwefers]

Thanks for the quick reply!

I compiled in release mode which shaved off a whopping 1.8 us (at least it's something I guess). I will look into setting the SPI peripheral registers directly. When you say the RM has instructions on this, what do you mean by RM? Are there some links you could share to point me in the right direction?

[TDK]

RM is short for Reference Manual. I should have typed it out. It will describe all the registers and is the primary resource for how the chip works.

https://www.st.com/resource/en/reference_manual/rm0377-ultralowpower-stm32l0x1-advanced-armbased-32bit-mcus-stmicroelectronics.pdf