AnsweredAssumed Answered

STM32-MAT/TARGET. Tons Of Bugs: SPI slave stops on each “sneeze”

Question asked by Dima Sagalov on Feb 26, 2018

Environment:

Windows10 (x64)

Matlab R2017a

STM32-MAT/TARGET-v4.4.2

STM32CubeMX-v4.24.0

STM32Cube MCU Package for STM32F0 Series -v1.9.0

STM32Cube MCU Package for STM32F3 Series -v1.9.0

SW4STM32-v2.4

TrueSTUDIO-v9.0.0

 

If the system uses at least one SPI Master, all SPI ports (Master and Slaves) work without stopping. Once started during initialization using the __HAL_SPI_ENABLE macros, they never stop again, because the __HAL_SPI_DISABLE macros is not used anywhere (see spi2_master_spi3_slave).

 

If you remove all SPI Master from the system, SPI Slave will stop for each sneeze. Once started during initialization using the __HAL_SPI_ENABLE macro, they stop after the first transaction, because __HAL_SPI_DISABLE macros everywhere (see spi3_slave).

The bypass path is to regularly restart the SPI Slave by writing the SPE bit to the SPI3_CR1 register (see spi3_slave_with_restart).

I do not know what considerations guided the developers! Perhaps they were the lightest! But from the user's point of view it looks like this: SPI Master + SPI Slave - everything works OK; remove SPI Master - SPI Slave is no longer started! Fantastic! To be honest, at first I sinned on the hardware implementation of NSS in Slave mode, and spent a lot of time to understand that this is not so!!

Along the way, I found an error in the operation of the REGISTER_Access block — every time when you open a Simulink file it replaces SPI3 with DMA. Additional information is inside the spi3_slave_with_restart.slx file.

Attachments

Outcomes