STM32 32-bit ARM Cortex MCUs(SPI transaction misbehavior)

[rakesh GMN]

Posted on June 21, 2018 at 13:55

STM32F427 SPI controller path bring up. I want to bring up SPI read write transaction, as I am performing SPI transaction for the first time on power on the transaction looks perfectly okay(Checking the timing waveforms of SCLK, and MOSI  pins at the receiver end).

                    But, as we do the next SPI transactions, observing irregular behavior with respect to number of SPI clocks driven by the master SPI controller in STM32. And also the data out from MOSI is not as expected. Please do the needful. 

[Tilen MAJERLE]

Posted on June 21, 2018 at 14:10

Hello,

to read/write from SPI, you need to (once initialized and enabled):

1. Set SPIx_DR register with your value
2. Wait for TXE flag
3. Wait for RXNE flag
4. Repeat point 1 if not yet finished
5. Wait for BUSY flag to go to 0 in case of no more data to send.

Best regards,

Tilen

[rakesh GMN]

Posted on June 22, 2018 at 14:15

Hello Tilen,

Adding more details for the query :

We have generated the software code from STMCube for System32 workbench. We are using this command to read/write to SPI :

>HAL_SPI_TransmitReceive(&hspi4, (uint8_t*)spiTxData, (uint8_t*) spiRxData, 2, 5000).>STM32 is spi master and an FPGA is SPI slave. For the first transaction, we are able to receive the data sent. But if I call the same function again the SPI clocks and data transmitted is not as expected.

PS:Attaching chipscope/signal tap images captured.

[rakesh GMN]

Posted on June 26, 2018 at 10:58

Hi Tilen,

Please assist us to debug the above issue of SPI. Any help will be appreciated. Thank you in advance.

[Tesla DeLorean]

Posted on June 26, 2018 at 15:04

>>But if I call the same function again the SPI clocks and data transmitted is not as expected.

Define 'expected'

Looks like you need to increase the sample rate on your scope, or drop the clock rate on the STM32. The lower graph suggest you have insufficient bandwidth.

[rakesh GMN]

Posted on June 27, 2018 at 09:13

Hi Clive,

Thanks for the reply.

By ''Expected'' I meant as ''the first SPI transaction'' that I am observing after power on.

If insufficient bandwidth is the reason causing the issue, then why not we are facing the same for the first transaction?!

Please retrieve back, with reasonable solution.

[David Littell]

Posted on June 27, 2018 at 15:08

It's not that insufficient chipscope bandwidth is the issue, it prevents seeing anything helpful.  There are hints of a scope bandwidth problem in your first trace but the second one isn't helpful at all because of the compressed time scale and the lack of bandwidth.

Have you tried isolating (disconnecting) the FPGA SPI signals to see what the second transaction looks like without the FPGA?  If the second transaction suddenly looks more reasonable you have problem in the FPGA.  Otherwise you have a STM32-side code problem (my personal suspicion). 

[Tesla DeLorean]

Posted on June 27, 2018 at 18:54

>>Please retrieve back, with reasonable solution.

Really?

The long trace doesn't contain enough detail to make any determination about what is happening, the bandwidth and compression of the trace eliminate ALL DETAIL that might be pertinent to determining if the STM32 is doing what it is supposed to be doing or not. My suspicion is that it is behaving identically in both cases, which rather torpedoes the 'working' vs 'not working' narrative.

>>If insufficient bandwidth is the reason causing the issue, then why not we are facing the same for the first transaction?!

You are facing it, you're just not understanding it, or seeing it, for whatever reason.

The displacement of the signals strongly suggests an inadequate sample rate. Without good, clean and effective measurements debugging this is going to be harder than necessary.

[rakesh GMN]

Posted on June 28, 2018 at 11:25

SPI signals are connected between a microcontroller and an FPGA on our custom board. We cannot isolate the SPI signals.

The STM32 code is generated from STMCube tool. FPGA code has been simulated with a test bench and the code works fine.

[Tesla DeLorean]

Posted on June 28, 2018 at 15:06

It could presumably be tested on different hardware where the code could be evaluated without the FPGA.

I'd start with improving the resolution of the plot so the clock could be seen more clearly.