search

STMicroelectronics / STM32CubeF3

STM32Cube MCU Full Package for the STM32F3 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
Other
141 stars 54 forks source link

RXNE flag doesn't behave correctly while using HAL_SPI_Receive() in bidirectional mode #7

Closed Jaycobe96 closed 3 years ago

Jaycobe96 commented 3 years ago

Caution The Issues are strictly limited for the reporting of problem encountered with the software provided in this project. For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum.

Describe the set-up

Describe the bug RXNE in flag doesn't behave correctly while using HAL_SPI_Receive() in bidirectional master mode.

How To Reproduce

  1. Indicate the global behavior of your application project.

    HAL_SPI_Recieve() causes the SPI hardware to send twice as many clock periods.

  2. The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...).

    HAL_SPI_Receive()

  3. How we can reproduce the problem.

    See the screenshot for parameter settings of SPI

Screenshots Configuration of the SPI: Screenshot from 2021-02-08 13-01-17

Clock signal when RXNE is ignored (workaround) 8periods

Clock signal when RXNE is not ignored (issue) 16periods

ASELSTM commented 3 years ago

Hi @Jaycobe96,

This issue is already known. It has been spotted internally and our development team has already dealt with it. Unfortunately, it is a Hardware limitation.

This is due to a synchronization problem during SPI deactivation which is not done at the right time and that leads to the generation of another clock cycle.

The SPI deactivation information should normally be received between the third and the seventh clock stroke, the master will then take this information into consideration and will then stop the transmission at the end of the eight clock stroke.

The information, is actually received only at the 8th clock stroke, which is too late to allow the master to stop the transmission at the right moment. So, another clock cycle is generated.

Our development team has worked on a workaround in the HAL driver to deal with the issue. The reception function within the HAL takes into consideration the extra byte sent in an erroneous way. The FIFO is then flushed to keep only the useful information.

In order to rectify the issue of the extra clock cycle, we can suggest you a workaround so that only 8 clock trikes are generated. For that you can use a TIM which will compute the time taken by a frame to be sent and then to deactivate the SPI at the right moment.

Hope this would help you.

With regards.