2019-12-05 03:51 AM
I was trapped when switching chip code to STM32F303, my SPI always send more unexpected 6 zero bits before my data. diagram below shows the detail.
The problem occurs when you enable SPI while SCK is high. My SPI works in CHPA and slave mode, I haven't test other mode for detail.
Please notice that if you are trying to do it. If someone had faced this problem, help me explain the reason, thanks.
2019-12-05 04:06 AM
Are you using hardware nss?
In my application, an fpga sends 16 bytes every 40uS to an f750 using circular dma reception. I was worried about the dma possibly starting out of sync, so i poll for nss active then inactive before finally enabling the spi at the end of spi init routine. Works great. Don't know about transmitting data in slave mode, my app is half duplex.
2019-12-05 04:23 AM
No, it's a software nss, I solved the problem with the similar way to yours, that's switch SCK pin's alternative mode to analog mode, then do enable, reconfigure to alternative mode after SPI enabled, I will try your way for comparsion, thank you.
2019-12-05 04:27 AM
Yes, i forgot to mention that i start with the nss pin as regular gpio and switch to the alternate function (hardware nss) also at the end of the spi init.
2019-12-05 04:43 AM
It maybe the same issue i got 2 years ago with stm32l4 which has the same spi with fifo.
In short, dma cyclic means that in slave mode, the tx fifo is always full. Nss is not affecting the fifo which won t be reset and you should see the pending 4 bytes ready to transmit.
Peripheral enable and disable wont flush the fifo. A sw reset of the peripheral and reinit of dma is needed. To be rugged, you will need exti on nss rising edge. If nss if alternate function, HAL won t offer the option of Exti on alternate... While the hw works fine. Some faith on the ref man and some hack needed here. My guess....
2019-12-05 04:56 AM
If you don't use hal, it's easy to switch back and forth between an exti interrupt and an alternate function on a port pin. In my system, the com port rx is idle low, which is incorrect so i switch back and forth between an exti rising edge interrupt to disable the exti and enable the comm port and then on the reception of the final framing character it will switch back to the exti and disable the comm port.
2019-12-05 05:04 AM
The basic problem we wanna solve is same: the fifo flushing problem. I'm heading to flush the receive fifo if any transmition is stoped illegally, there will be the residual incomplete data in fifo.
Every time I use RCC to reset SPI for flushing the fifo, needs a SPI reinit to do, then gets lots of problems to need solved, make me go nuts.
2019-12-05 05:44 AM
Actually you are getting there. At least reset spi and resync the dma at nss rise edge. And let enough time for the slave to be ready for next nss fall edge. You don t need to touch the gpios and you don t need to change exti. Exti is independent of gpio. It would have been better if the spi could flush its fifo when nss is high....
2019-12-05 05:46 AM
It works with hal with a minor exti hack.