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

i23 · ‎2015-10-23

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

waclawek.jan · ‎2015-10-23

Posted on October 23, 2015 at 23:05

I must say first, that I have nil experience with 'F7.

You've put NSS into tags, but did not mention it in the text... please elaborate. Try to set it to soft and inactive.

Also, what are the CR1 and CR2 settings you've mentioned, and how exactly are the GPIO set? Does changing the GPIO ''speed'' settings (mainly of SCK) change anything? Does changing the mode (CPOL/CPHA) have any influence on things?

JW

re.wolff9 · ‎2015-10-24

Posted on October 24, 2015 at 14:53

Based on the suggestion above, if the SPI module thinks NSS is not active, it might not consider recieved data as valid. So, check ''software slave select'' and if disabled, is the NSS of SPI1 configured as output? Maybe the module simply reads the pin instead of the output that ''doesn't go anywhere'' if the NSS pin is not correctly configured.....

i23 · ‎2015-10-24

Posted on October 24, 2015 at 21:25

Hey,

GPIOA Pins are configured as alternative function, AF5_SPI2 (using the HAL driver, register values seem right). Setting them to the alternative function should, as far as I understand, imply configuring them as inputs and outputs accordingly.

I've thought an electrical short might prevent the NSS from being asserted and force invalidate the transmission, but the logic analyzer shows a correct pulse. SSM (software slave select) is disabled, SSI, as far as register view shows, is always set.

@JW

GPIOAs are set to AF5_SPI2 function (as cube generated). I'll post the contents of CR1 and 2 and attempt the things you've suggested monday. I'd be surprised to have anything wrong with them as SPI2 and SPI4 are configured in exactly the same way and do work properly..

re.wolff9 · ‎2015-10-24

Posted on October 24, 2015 at 22:50

Agreed, something weird is going on. So either there is a silcon bug that you're the first to run into, or there is some difference between SPI1 and the others. You've verified the registers, but maybe the problem is somewhere else. Example: I spent a lot of time debugging why USB wouldn't work on STM32F042F while it worked on my STM32F072R board.... Turns out to get USB to work on the '42, you need a bit in SYSCFG to be set. By the time I got that far, I had already, like you, compared all the registers in the USB module....

waclawek.jan · ‎2015-10-25

Posted on October 25, 2015 at 18:26

> I've thought an electrical short might prevent the NSS from being asserted and force invalidate the transmission, but the logic analyzer shows a correct pulse.

Ah, so you have turned it to output and pulsing? Then it's not likely it's the culprit.

And what are exactly the symptoms? What happens if you don't play with DMA, only read it in a simple loop?

JW

i23 · ‎2015-10-26

Posted on October 26, 2015 at 10:03

Yep, it's on output.

I've added a

screenshot as an attachement. ad_configure happens after HAL_SPI_Init has run but before the DMA inits have. It uses ad_transmit_once(), visible on top of the sourcecode to transmit synchronously. The breakpoint on HAL_Delay is triggered: you can see the register values on the right. (SPI1 DR is not read by the register view to avoid clearing). For SPI2 and SPI4 the RXNE is set at this point, but not for SPI1.

________________

Attachments :

spi1_problem.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0hW&d=%2Fa%2F0X0000000bcc%2FGfmuyace1AJNAgLyJnp8u6zkUVJlnMrenU63HeRpMF0&asPdf=false

waclawek.jan · ‎2015-10-26

Posted on October 26, 2015 at 11:35

If DMA is running, it reads the DR thus clears RXNE even if you ''stop'' execution through breakpoint or single-step.

Stop/don't start DMA and observe SPI.

JW

i23 · ‎2015-10-26

Posted on October 26, 2015 at 13:23

DMA is not enabled(nor even initialized) at the point of the test I've shown in the previous post.

waclawek.jan · ‎2015-10-26

Posted on October 26, 2015 at 14:34

Did you consider the Rx FIFO? Is there any change if you set SPI1->CR2.FRXTH?

I repeat I have no experience with 'F7 nor the newer SPIs with FIFO in other STM32 models.

JW