STM32 32-bit ARM Cortex MCUs(SPI transaction misbehavior)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-06-21 4:55 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-06-21 5:10 AM
Hello,
to read/write from SPI, you need to (once initialized and enabled):
- Set SPIx_DR register with your value
- Wait for TXE flag
- Wait for RXNE flag
- Repeat point 1 if not yet finished
- Wait for BUSY flag to go to 0 in case of no more data to send.
Best regards,
Tilen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-06-22 5:15 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-06-26 3:58 AM
Hi Tilen,
Please assist us to debug the above issue of SPI. Any help will be appreciated. Thank you in advance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-06-26 8:04 AM
>>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.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-06-27 12:13 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-06-27 8:08 AM
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-06-27 11:54 AM
>>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.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-06-28 4:25 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-06-28 8:06 AM
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.
Up vote any posts that you find helpful, it shows what's working..
