Using STM32F103RBT6 chip (Specifcally Olimex STM32- H103 Board), Keil u5. Communicating with AS5311 magnetic sensor

SPI peripheral is setup in master mode uni-directional rx only. CPHA = 1 and CPOL = 1. The clock pin is set as alternate function push pull. initialisation of SPI is below:

  hspi1.Instance = SPI1;
  hspi1.Init.Mode = SPI_MODE_MASTER;
  hspi1.Init.Direction = SPI_DIRECTION_2LINES_RXONLY;
  hspi1.Init.DataSize = SPI_DATASIZE_8BIT;
  hspi1.Init.CLKPolarity = SPI_POLARITY_HIGH;
  hspi1.Init.CLKPhase = SPI_PHASE_2EDGE;
  hspi1.Init.NSS = SPI_NSS_SOFT;
  hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_256;
  hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB;
  hspi1.Init.TIMode = SPI_TIMODE_DISABLED;
  hspi1.Init.CRCPolynomial = 10;

I then enter a loop with the following code simply on a constant receive mode

while (1)
  HAL_SPI_Receive(&hspi1, (uint8_t *)Rx_Buffer, 3, HAL_MAX_DELAY);

I've checked the polarity and phase in the perihperhal viewer and can see the registers are set as 1 for both CPOL and CPHA. However when using a saleae logic analyser i can see that after transfer of data the clock does not idle high. SALEAE Capture of SPI data

In terms of hardware the clock is directly connected with no pull up/down resistors.

Any ideas why the clock wont idle high?

  • \$\begingroup\$ Looks like it will idle at high when enabled. \$\endgroup\$
    – Eugene Sh.
    Aug 23, 2017 at 16:01
  • \$\begingroup\$ @EugeneSh. when it comes out of the HAL_SPI_Recieve function, the SPI is disabled? \$\endgroup\$
    – Pop24
    Aug 23, 2017 at 16:11
  • \$\begingroup\$ I am talking about the bottom signal which seem to make difference (not sure, though as not enough of it is shown) \$\endgroup\$
    – Eugene Sh.
    Aug 23, 2017 at 16:16
  • \$\begingroup\$ @EugeneSh. the signals all continue as shown at the end of the traces i.e. clock low, Enable low and MISO low. until the delay finishes and a new recieve is enabled \$\endgroup\$
    – Pop24
    Aug 23, 2017 at 16:20
  • 2
    \$\begingroup\$ Hmm, I think I had the same issue, the pin seems to go into high impedance mode after the peripheral finished the transaction. I enabled the pull-up on the pin. Maybe some further investigation will find a better fix, but I had to move on. \$\endgroup\$
    – Arsenal
    Aug 23, 2017 at 18:12

3 Answers 3


I was running into a similar issue and after days of research and debugging, I noticed a trend that everyone who was having this issue configured their SPI as RX only. When I changed my SPI to TX RX mode the issue was magically solved. I'm not sure what could cause this, but it seems like a bug on ST's end, either as part of the HAL library, or as part of the device itself. Either way, now I just have an unused MOSI pin configured, but the SCK idle problem has been solved. Hope this helps save someone some time and headache!


Pin goes to floating state (high impedance, hi-Z) after N clock pulses. Issue solved by configuring clock pin to internal pull-up.


I had the same problem. My solution was to send (trasmit) dummy byte (without CS) right after configuring the SPI interface.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.