Skip to main content
rakesh GMN
rakesh GMN
Associate
June 21, 2018
Question

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

  • June 21, 2018
  • 3 replies
  • 2015 views
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. 

                

    This topic has been closed for replies.

    3 replies

    Tilen MAJERLE
    Tilen MAJERLE
    ST Employee
    June 21, 2018
    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
    rakesh GMNAuthor
    Associate
    June 22, 2018
    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.0690X0000060LKKQA2.png0690X0000060LNcQAM.png

    rakesh GMN
    rakesh GMNAuthor
    Associate
    June 26, 2018
    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.

    rakesh GMN
    rakesh GMNAuthor
    Associate
    June 27, 2018
    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.0690X0000060LUiQAM.png

    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
    David Littell
    Senior II
    June 27, 2018
    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). 

    rakesh GMN
    rakesh GMNAuthor
    Associate
    June 28, 2018
    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.

    Terms & ConditionsAccessibility statement