Posted on February 26, 2018 at 04:11Environment:
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.
#stm32-mat/target-matlab #simulink
