AnsweredAssumed Answered

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

Question asked by EvilMav on Oct 23, 2015
Latest reply on Dec 2, 2015 by EvilMav
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...