STM32F4xx HAL SPI Driver V1.4.4

Singh.Harjit · ‎2016-02-19

Posted on February 20, 2016 at 07:18

This release has the following note and I haven't been able to figure out why there is this limitation and am hoping some here can help.

Add note to the max frequencies reached in all modes.
Add note about Master Receive mode restrictions :
- Master Receive mode restriction:
  
        (♯) In Master unidirectional receive-only mode (MSTR =1, BIDIMODE=0, RXONLY=0) or
            bidirectional receive mode (MSTR=1, BIDIMODE=1, BIDIOE=0), to ensure that the SPI
            does not initiate a new transfer the following procedure has to be respected:
            (♯♯) HAL_SPI_DeInit()
            (♯♯) HAL_SPI_Init()

The stm32f4x_hal_spi.c file has the following:

[..]

Master Receive mode restriction:

(♯) In Master unidirectional receive-only mode (MSTR =1, BIDIMODE=0, RXONLY=0) or

bidirectional receive mode (MSTR=1, BIDIMODE=1, BIDIOE=0), to ensure that the SPI

does not initiate a new transfer the following procedure has to be respected:

(♯♯) HAL_SPI_DeInit()

(♯♯) HAL_SPI_Init()

[..]

Using the HAL it is not possible to reach all supported SPI frequency with the differents SPI Modes,

the following table resume the max SPI frequency reached with data size 8bits/16bits,

according to frequency used on APBx Peripheral Clock (fPCLK) used by the SPI instance :

DataSize = SPI_DATASIZE_8BIT:

+----------------------------------------------------------------------------------------------+

| Process | Tranfert mode |---------------------|----------------------|----------------------|

|==============================================================================================|

| T | Polling | Fpclk/2 | Fpclk/2 | NA | NA | NA | NA |

| X |----------------|----------|----------|-----------|----------|-----------|----------|

| / | Interrupt | Fpclk/4 | Fpclk/8 | NA | NA | NA | NA |

| R |----------------|----------|----------|-----------|----------|-----------|----------|

| X | DMA | Fpclk/2 | Fpclk/2 | NA | NA | NA | NA |

|=========|================|==========|==========|===========|==========|===========|==========|

| |----------------|----------|----------|-----------|----------|-----------|----------|

| X |----------------|----------|----------|-----------|----------|-----------|----------|

|=========|================|==========|==========|===========|==========|===========|==========|

| |----------------|----------|----------|-----------|----------|-----------|----------|

| X |----------------|----------|----------|-----------|----------|-----------|----------|

| | DMA | Fpclk/2 | Fpclk/2 | NA | NA | Fpclk/2 | Fpclk/128|

+----------------------------------------------------------------------------------------------+

#bidirection #spi #one-wire #spi

Amel NASRI · ‎2016-02-24

Posted on February 24, 2016 at 13:44

Hi HarjitS,

The limitations you mentioned were added on the last F4 SPI driver version while tehy were available on the drivers of other products since a time. SO it was done just to be aligned.

Then the content is based on some limitations that you may find in datasheet or reference manual and were summarized in this table.

-Mayla-

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Singh.Harjit · ‎2016-02-27

Posted on February 27, 2016 at 17:38

Thank you for pointing out that this was always the behavior.

Turns out that it is actually a limitation of the HW and HAL SPI driver/architecture. Once you turn on the SPI port in receive mode, it *continuously* does transfers. The HAL SPI driver overhead is so high that it is not fast enough to keep up with the incoming data.

I wish the ST SPI designers had implemented a transfer count for single wire mode and that coupled with DMA would have taken care of this problem.