STM32H743 SPI transmit with DMA not working

[Scott Gravenhorst]

I am working with a Nucleo-H743ZI on a Makefile C project using STM32CubeMX generated project code (Fiirmware version V1.3.0) to troubleshoot a problem with SPI transmit using DMA.

The project uses SPI1 to transmit to SPI2 on the same board at 25 megabits per second using 4 inch wires for both data and SCLK. The wiring has been proven by running a test in polling mode sending 32 bit random numbers and comparing. The polling works, so the wiring is good.

The end project needs DMA, so I've re-written the code to support DMA. The DMA hardware setup was performed in CubeMX. SPI1 is the DMA transmitter.

The project prints (to virtual com port) messages showing SPI status as it goes long. Once the first DMA operation is started, the program reports that a transmission is ongoing and never ends. If I scope MOSI from SPI1, there is no signal. (There is a signal, however, when the same test is done with polling).

After several days of web search and research, I am here.

I updated STM32CubeMX to Version 5.0.1 STM32CubeMX V1.0. Firmware is V1.3.0

I read that the linker script produced does not not provide a section for the D2 RAM domain, so I searched and found code to do that. I use an __attribute__ to force the TX buffer into D2 domain RAM section. This was verified both by looking at the .map file and by printing the value of the pointer to TXbuf which is 0x30000000. I found the two board example project and saw the cache maintenance statement for transmit and added that to my code. I've also tried turning data cache off altogether. DMA1 stream 0 is used for SPI1 while SPI2 remains in receive polling mode. I've also compared my SPI and DMA setup with the two board project and find no difference.

I found this FAQ:

https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices

and this:

https://community.st.com/s/question/0D50X00009XkX4ZSAV/solved-stm32h7-spi-does-not-seem-to-work-with-dma

and this:

https://community.st.com/s/question/0D50X00009q2XcxSAE/is-there-a-possible-bug-in-function-halspitransmitdma-stm32cubefwh7v

I see solutions relating to Keil, TrueStudio, etc., but nothing for Makefile projects.

The third link shows that there exists a typo in the HAL_SPI_Transmit_DMA() function that improperly uses hdmarx instead of hdmatx handle. This has been corrected, but regardless of what I've tried, the SPI transmit operation never completes and no data ever appears in the SPI2 receive buffer.

So at this point, I have verified the wiring and RAM location of the transmit DMA buffer. I've turned cache off, though I believe this would have more to do with corrupt data rather than no transmit data. I've also tried the 256 baud clock divider to no avail.

I would greatly appreciate clues, pointers, suggestions, etc.

[ST User]

Yes, I would think so.

I believe I modified my example a bit to actually send the data I wanted to send instead of using their default transmit data, but once I configured it for the pins I was using I was able to see SCLK and MOSI data on an oscilloscope.

[Scott Gravenhorst]

Which pins did you use? Since you've made it work, I'd like to try that.

[ST User]

SPI1 set up with

SCLK: PB3 (CN12 pin 31)

MOSI: PD7 (CN11 pin 45)

Note those connections are on the morpho connectors on the sides.

[Scott Gravenhorst]

Thank you very much. I'll try that now and post back when I know.

[Scott Gravenhorst]

I have just finished testing both DMA and polling with both the default pins and the ones you've specified. In both cases, I see a clock burst from polling and no clock burst from DMA. I am stumped.

[Wowa]

I also encountered this problem - not being able to see any MOSI signal running SPI_FullDuplex_ComDMA example in Master mode. In fact, it's very embarassing! Using framework v.1.8.0. Scott, did you manage to get your project working?

[Scott Gravenhorst]

I did indeed get it working. Once thing to check is the data size for the DMA controller. My SPI transfer was 24 bits and the DMA data sizes (both periph and mem). The CubeMX default for SPI controllers is byte, so it didn't work. I also believe NSS may have been a problem as well as SPI SCLK polarity. Both of those settings depend on what the SPI channel is talking to. This process can be tedious because of the way the documentation is laid out. One thing I do with new projects is I start with what I would call a hello-world project with all of the peripherals set up and controlled by test code that can show if it's working. Once I'm happy with that, I build it into the application I want.

I've stayed with v.1.4.0. I would think v.1.8.0 would be better.