Using the SPI interface on STM32 devices

This tutorial shows how to use the SPI interface of the STM32 devices using the STM32CubeMX HAL API. We will configure the SPI in several different modes, show how they affect the generated signal and setup the double-buffered mode to demonstrate continuous uninterrupted mode.

We will use an STM32F4Discovery board to demonstrate the SPI and a Nucleo-F411RE board with Analyzer2Go to capture and analyze the generated SPI signals.

Before you begin, install Visual Studio and VisualGDB:

  1. Start Visual Studio and open the VisualGDB Embedded Project Wizard:01-newprj
  2. Proceed with the default settings on the first page:02-binary
  3. On the next page select your STM32 device. In this tutorial we will use the STM32F4Discovery board that uses the STM32F407VG chip, however the techniques described here will work for other chips as well:03-device
  4. Select the default “LEDBlink” example and click “Next”:04-blink
  5. Finally specify your debugging settings. For most STM32 devices programmable via ST-Link we recommend using OpenOCD. Connect your board to the computer and click ‘Detect’ to automatically detect your ST-Link interface:05-debug
  6. Click “Finish” to generate the basic project and ensure it builds. Now we will modify the project to send a basic message over the STM32 SPI interface. First of all, locate the datasheet for your STM32 device and find the pins that can be used for SPI. For STM32F407VG we will use pins PA4-PA7 with SPI1 (note tha alternate function number that is AF5 in this case):aftable
  7. Replace the contents of the main .cpp file with the following code:
  8. Add the code that will initialize the SPI peripheral to the GenerateTestSPISignal() function:
  9. If we begin using the SPI peripheral right after calling HAL_SPI_Init(), the peripheral will appear working from the program’s point of view, but the SPI signals will not be actually be visible on the chip pins. To fix this, we need to explicitly switch pins PA5-PA7 to the SPI mode. We will leave the PA4 pin to be a generic GPIO pin to demonstrate how to control the NSS signal manually:

    Note that the GPIO_AF5_SPI1 corresponds to the alternate function number (AF5) for SPI1 from the Alternate Function table in the datasheet.
  10. Finally add the following code that will repeatedly transmit the “Hello, World” string over the SPI:

    Note that we manually control the NSS signal by setting the PA4 pin value to 0 before the transmission and setting it back 1 after the transmission.
  11. Build the project and ensure that is succeeds without any errors:06-build
  12. Set a breakpoint on the first call to HAL_GPIO_WritePin() and start debugging. Ensure that the breakpoint hits:07-step
  13. Now we will use a logic analyzer to observe the SPI signals produced by the board. In this tutorial will use Analyzer2Go and the ST NUCLEO-F411RE board to capture and analyze the signals. If you don’t have the Nucleo-F411RE board, you can use any of the other boards supported by Analyzer2Go or an external logic analyzer. First start Analyzer2Go, connect the board you want to use as a logic analyzer and select it in the list:08-selboard
  14. Then connect the relevant SPI signals (MOSI, SCLK and NSS) to the inputs of the logic analyzer board that are shown in the Analyzer2Go window. Do not forget to connect the ground between the 2 boards:2boards
  15. Finally click on the connected signals in the Analyzer2Go window to immediately see the live SPI signal:09-signalObserve the repeated pattern: the NSS signal goes from 1 to 0 (indicating the start of a transmission), then the SCK and MOSI signals quickly change the values and the NSS gets back to 1.
  16. Click in the “Trigger” column of the NSS signal so that the data frame gets aligned to the falling edge (start of transmission). Then double-click on any of the solid blocks in the SCK or MOSI signals to zoom in to see the actual signal:  10-spiObserve the typical SPI signal waveform: the SCK clock generates monotonous clock pulses during the transmission and the MOSI signal (Master Output Slave Input) transmits the data one bit at a time.
  17. Add labels to the SCK and MOSI signals by clicking on “Click to add description”, then open the Protocol Analyzers tab, add and connect the SPI protocol analyzer:11-decodedObserve how the “Hello, World” message got decoded.
  18. Now we will look how exactly the message is coded when using different SPI modes. Select the ‘H’ character and click on the Notes bar to add a note:12-hnote
  19. Then switch the MOSI signal view from SPI to Raw to see the exact bits that correspond to the ‘H’ byte:13-raw
  20. Each of the 8 clock cycles transfers exactly 1 bit of the 8-byte character (MOSI will be low if the bit value is ‘0’ and high if the bit value is ‘1’). To visualize this, select the SCK clock cycles corresponding to the ‘H’ character and click ‘Set this signal as the primary clock’: 14-signals
  21. Analyzer2Go will automatically print the value of MOSI in each clock cycle. As we are transferring the least significant bit first, 00010010 corresponds to 0b01001000 that is equal to 0x48 or the ASCII code for the capital ‘H’ character:15-value
  22. Note that when the MOSI signal needs to change, it changes exactly at the falling clock edge of SCK. It ensures that the signal will have enough time (1/2 cycle) to stabilize by the time the receiving SPI device actually samples it:16-edge
  23. To change this behavior, set the CLKPolarity field of the SPI initialization structure to SPI_POLARITY_LOW instead:
  24. Observe how the MOSI value now changes on the rising edge of SCLK:17-reversedThe correct value to use depends on the specifications of the device you want to interface over SPI. If it samples the MOSI output on rising edges, configure the SPI peripheral to change its value on falling edges. Otherwise set it to change at rising clock edges.
  25. Another important parameter is the clock phase. It affects the state of the SCK signal when no transmission is active. Note that toggling the clock phase also changes the active edge:
    CLKPolarity CLKPhase MOSI changes on SCK value when inactive

    Set CLKPhase to SPI_PHASE_1EDGE and observe how the signals change:

  26. Now we will show how to configure the SPI peripheral to automatically control the NSS signal. Normally the slave SPI devices will ignore any SPI communication that takes place when their NSS input is inactive (set to 1). This allows sharing the same MOSI, MISO and SCK signals between several slave devices and using the NSS signals (1 for each device) to select which device should be responding to each communication. So far we have been controlling NSS manually using the HAL_GPIO_WritePin() function, however the STM32 SPI peripheral allows generating the NSS signal automatically. Change the initialization code accordingly:

    Finally remove the calls to HAL_GPIO_WritePin().
  27. Run the code and observe the new signals. Note how NSS stays low during and between the transmissions:19-hardnss
  28. The only way to override this behavior while still using the hardware NSS mode is to disable the SPI peripheral after each transmission:
  29. Run the updated code and confirm that the NSS signal reappears:20-hardcs2
  30. We will now step through the HAL_SPI_DeInit() function to see at which point the NSS goes from 0 to 1. Stop your code at a breakpoint and click the “Record” button in the Analyzer2Go to begin recording the signal values continuously, then step into and through HAL_SPI_DeInit():21-contin
  31. The NSS signal will go from 0 to 1 once the __HAL_SPI_DISABLE(hspi) line gets executed:22-deinit
  32. Use the “Preprocess selected lines” command to see that it actually clears the bit #6 (SPE) in the SPI_CR register:23-prepro
  33. The STM32 SPI peripheral also supports a special TI mode. Try switching it on by modifying the startup code as follows:

    Note how the NCS signal now stays at 1 during once cycle before the transmission and then gets back to 0 (the bit order is also switched to MSB-first): 24-timode
  34. Now we will show how to use the STM32 SPI to efficiently transfer large amounts of data (e.g. a stream of values to a digital-to-analog converter). First we will try the simplest approach: generate a block of values, then simply transmit it via HAL_SPI_Transmit():

    FillNextFrame() will fill the transfer buffer with 32-bit values starting from (FrameNumber * 0x100) to (FrameNumber * 0x100 + 0xFF). This allows telling the frame and the position within the frame from the value. E.g. 0x002501 means value #01 (starting from #00) in frame 0x25.
  35. Run the updated code. As FillNextFrame() and HAL_SPI_Transmit() cannot run at the same time, you will see gaps between the values corresponding to different frames: 25-gap
  36. To eliminate the gaps, we will configure the SPI to use DMA (direct memory access) with double-buffering. It will automatically transfer the first half of the buffer while your code will be filling the second half and vice versa, resulting in a 100% uninterrupted transmission. First locate the DMA channel and stream that is connected to the SPI1 TX channel:dmarq
  37. Then replace the code after the last call to HAL_GPIO_Init() by the code initializing and starting the DMA:
  38. Then add the following code before the GenerateTestSPISignal() function:
  39. By using HAL_SPI_Transmit_DMA() instead of HAL_SPI_Transmit() we tell the SPI peripheral to start transmitting s_TransferBuffer using the background direct memory access mechanism and immediately return control. When the first half of the buffer is transmitted, the DMA will raise an interrupt resulting in a call to HAL_SPI_TxHalfCpltCallback() that will generate the first half of the next frame while the current frame is still being transferred. When the entire buffer is transferred, HAL_SPI_TxCpltCallback() will get called and will generate the second half of the frame (while the DMA is already sending the first half of it). This results in 100% uninterrupted transmission without any gaps:26-nogap
  40. You can visualize the transfer timings by replacing the empty loop at the end of GenerateTestSPISignal() with the loop toggling the NSS signal (don’t forget to configure PA4 as GPIO_MODE_OUTPUT_PP):
  41. Run the updated code. Observe how the NSS signal value stops changing for a short time (while one of the CpltCallback functions is running), but the SPI transmission runs uninterrupted:27-intgap
  42. You can set a breakpoint in one of the CpltCallback functions and use the Call Stack window to see the chain of functions involved in handling the interrupt:isr