SPI using DMA not outputting data on MOSI line on the STM32L552E-EV Evaluation board.

[HaLed]

Hi everyone,

I can not get SPI using the DMA to work. The MOSI line stays zero all the time. The result is the same using my own and also the example code provided with the firmware package for the MCU (STM32CubeL5\Projects\NUCLEO-L552ZE-Q\Examples\SPI\SPI_FullDuplex_ComDMA_Master).

On the other hand, if I use a busy transfer (HAL_SPI_Transmit(&hspi1, aTxBuffer, BUFFERSIZE, 100);) the MOSI line outputs data as expected, which makes me believe that on the SPI, GPIO side things are working fine.

I guess there must be some configuration that I am overlooking. Still, it surprises me that the example is not working.

Any ideas?

[waclawek.jan]

If you are sure GPIO is set correctly, read out and check/post content of SPI and relevant DMA/DMAMUX registers.

JW

[HaLed]

Any advice? I am a little stuck, as the example code provided by ST does not work either. Maybe someone has the possibility to try running the mentioned example on the STM32L552E-EV Evaluation board.

Thanks a lot!!

[HaLed]

Thanks for your answer!

These are the register values after running MX_DMA_Init() and MX_SPI1_Init() functions but before running HAL_SPI_TransmitReceive_DMA([...]):

[FBL]

Hello @HaLed​,

I was wondering why using HAL_SPI_Receive() and HAL_SPI_Transmit() which receives/transmits an amount of data in blocking mode.? I think you would be better use functions with non-blocking mode (for DMA) such as HAL_SPI_Receive_DMA(), HAL_SPI_Transmit_DMA() and HAL_SPI_TransmitReceive_DMA.

Would you precise your hardware setup two STM32L552E-EV boards or one eval board as master and the NUCLEO-L552ZE-Q board as a slave?

[HaLed]

Hello,

thanks a lot for your answer! Sorry, I guess I described my problem somehow confusing. What I meant to say is that the function HAL_SPI_Transmit_DMA() do not work (data clocked out on MOSI line is always zero), whereas HAL_SPI_Transmit() does work correctly.

[HaLed · Accepted solution]

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

[FBL]

That's good, thanks for sharing @HaLed​.

Would you please close the question by selecting your response as the best answer.