cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F7: SPI1 does not assert RXNE or RXDMA-request with the same settings SPI2 and SPI4 do.

i23
Associate II
Posted on October 23, 2015 at 17:42

Hello,

I've got an STM32F746 here and I want to use SPI1, SPI2 and SPI4 in parallel with DMA. For each, one DMA channel pushes data into DR by a timer request, and another listens for a SPI_RX and forwards to memory. However, exactly the same code works flawlessly with SPI2 and SPI4 but fails to trigger RX DMA on SPI1.

To investigate further, I've send some test data via each SPI using the following code (having DMA stream not yet enabled):

    while (!(hdl->pSpi->SR & SPI_SR_TXE)); //wait for the transmit buffer to become empty

    hdl->pSpi->DR = data;

where hdl->pSpi points to the SPI_TypeDef under test. On a breakpoint shortly after the send I hald and use RegisterView to investigate, having only CR1, CR2 and SR enabled (to avoid Register viewer clearing the DR by reading it). It turns out that for SPI2 and SPI4 RXNE in SR gets asserted (which I would expect in the duplex SPI setting), but not for SPI1. CRC, BIDIMODE etc are disabled, MSTR is set,  and CR1 and CR2 are exactly the same for all SPIs!

Logic analyzer also shows that SPI1 sends the data correctly, as SPI2 and 4 do, with the correct MOSI, CLK and NSS pulses. It just would not consider any data received after that! It would also not trigger any error interrupt.

GPIO seems properly configured to PA4-PA7 with alternative function AF5 selected. PA4 and PA5 are not 5V-tolerant, but the MISO does not exceed 3.3V either.

Is there any possible GPIO misconfiguration or electrical failure mode that would lead an SPI into leaving RXEN reset after a transfer? I'm starting to consider a faulty chip, but it would be a very unlikely fault...

#spi #dma #stmm32f7 #nss
11 REPLIES 11
i23
Associate II
Posted on October 27, 2015 at 18:18

Just noticed the register view doesnt show the upper bits of SR. Weird.

Some progress here: if I (in GPIO config) move SCK from PA5 to PB3, RXNE gets asserted! Any ideas what could be wrong with PA5? 

PS The chip is so new, I don't think anyone has real experience with the F7 😉 But thank you so much for trying!

i23
Associate II
Posted on December 02, 2015 at 16:42

Considering the avoidance of PA5 has fixed the issue and noone seems to be aware of an official documentation on that, wouldn't it be something for the errata?