cancel
Showing results for 
Search instead for 
Did you mean: 

Can not get SPI_FullDuplex_ComDMA_Master Example in STM32Cube MCU Package for STM32L5 series working on STM32L552E-EV Evaluation board.

HaLed
Associate II

I am stuck trying to get the STM32L552E-EV evaluation board running with SPI using the DMA. Neither the mentioned example (STM32CubeL5\Projects\NUCLEO-L552ZE-Q\Examples\SPI\SPI_FullDuplex_ComDMA_Master) nor the code created via the wizard, nor my own code work. I end up always with the same problem of the SPI clock running and also the HAL_SPI_TxRxCpltCallback function getting called, but the MOSI line staying low (see figure). At the same time, transmits triggered via the HAL_SPI_Transmit function are clocked in just fine.

I posted a question to the same topic before, but I guess the title was not descriptive enough, and I did not mange to draw further attention to it. (https://community.st.com/s/question/0D53W00001uaQ9aSAE/spi-using-dma-not-outputting-data-on-mosi-line-on-the-stm32l552eev-evaluation-board)

It would be great if someone (maybe at ST) could try to run the example on the mentioned evaluation board and check if it is working fine. At the same time, I am open for any advice!!

Thanks a lot in advance 🙂

0693W00000WHjL1QAL.png 

1 ACCEPTED SOLUTION

Accepted Solutions
HaLed
Associate II

In the meantime, I managed to find out what the problem was. The microcontroller on the evaluation board had the Trust Zone Enable (TZEN) option bit set. This led to the SRAM being partially secure. As the SPI TX buffer variable was allocated in the secure area of the SRAM, reading its value from a non-secure application was returning zeros instead of the actually stored value.

Everything is working fine now after disabling the trust zone on the microcontroller like explained here:

https://wiki.stmicroelectronics.cn/stm32mcu/wiki/Security:How_to_disable_TrustZone_in_STM32L5xx_devices_during_development_phase#What_is_TrustZone-C2-AE-3F

View solution in original post

1 REPLY 1
HaLed
Associate II

In the meantime, I managed to find out what the problem was. The microcontroller on the evaluation board had the Trust Zone Enable (TZEN) option bit set. This led to the SRAM being partially secure. As the SPI TX buffer variable was allocated in the secure area of the SRAM, reading its value from a non-secure application was returning zeros instead of the actually stored value.

Everything is working fine now after disabling the trust zone on the microcontroller like explained here:

https://wiki.stmicroelectronics.cn/stm32mcu/wiki/Security:How_to_disable_TrustZone_in_STM32L5xx_devices_during_development_phase#What_is_TrustZone-C2-AE-3F