STM32H7 NUCLEO-H723ZG SPI Master RXONLY mode - how to remove 10us SCK delay?

[GgaGgung]

Hello,

I am using an STM32H7 MCU with STM32CubeIDE to communicate with a BiSS-C encoder in SPI RXONLY Master mode.
My goal is to generate 64 SCK clocks every 10ms without delay.

However, I am observing the following issue:

Each time I call HAL_SPI_Receive(), SCK stays low for around 10 microseconds before the clock output starts.

This happens regardless of SPI speed.
At 1MHz SPI clock, the delay is around 10us.
At 2MHz SPI clock, the delay reduces to about 5us.
But there is always some delay before the first SCK pulse.

The same code and settings on an STM32F103 board do not show this delay.
I already tried RXONLY and FULLDUPLEX modes, manual NSS control, enabling and disabling NSS Pulse mode, but the result is the same.

SPI settings:

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_LOW;
hspi1.Init.CLKPhase = SPI_PHASE_1EDGE;
hspi1.Init.NSS = SPI_NSS_SOFT;
hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_128;
hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB;
hspi1.Init.TIMode = SPI_TIMODE_DISABLE;
hspi1.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
hspi1.Init.CRCPolynomial = 0x0;
hspi1.Init.NSSPMode = SPI_NSS_PULSE_DISABLE;
hspi1.Init.NSSPolarity = SPI_NSS_POLARITY_HIGH;
hspi1.Init.FifoThreshold = SPI_FIFO_THRESHOLD_01DATA;
hspi1.Init.TxCRCInitializationPattern = SPI_CRC_INITIALIZATION_ALL_ZERO_PATTERN;
hspi1.Init.RxCRCInitializationPattern = SPI_CRC_INITIALIZATION_ALL_ZERO_PATTERN;
hspi1.Init.MasterSSIdleness = SPI_MASTER_SS_IDLENESS_00CYCLE;
hspi1.Init.MasterInterDataIdleness = SPI_MASTER_INTERDATA_IDLENESS_00CYCLE;
hspi1.Init.MasterReceiverAutoSusp = SPI_MASTER_RX_AUTOSUSP_DISABLE;
hspi1.Init.MasterKeepIOState = SPI_MASTER_KEEP_IO_STATE_DISABLE;
hspi1.Init.IOSwap = SPI_IO_SWAP_DISABLE;

Question:
Is there any way to eliminate or reduce this initial SCK low time (~10us) before data transmission starts?

Thanks in advance for your help

---

Edited to apply source code formatting - please see How to insert source code for future reference.

[TDK]

If CLK polarity is low, why do you want it to be idle high? Setting CLK polarity high would be one way to do this.

What part number are you interfacing with?

[waclawek.jan]

Try using fullduplex instead of halfduplex mode, transmitting dummy bytes to MOSI which is not set at the GPIO level.

JW

[GgaGgung]

Thank you for the suggestion.
I tried setting the SPI to full-duplex mode and used HAL_SPI_TransmitReceive() with dummy bytes, as you recommended.

Unfortunately, there was no change at all.

Do you have any other ideas on how to remove or reduce this delay?

while (1)
  {
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
	//HAL_SPI_Receive(&hspi1,Encoder_Data,8,100);
	uint8_t tx_dummy[8] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};	
	HAL_SPI_TransmitReceive(&hspi1, tx_dummy, Encoder_Data, 8, 100);
	HAL_Delay(10); //msec

  }

[GgaGgung]

Thanks for your reply.

I don't necessarily want the idle state to be high.

What I want is for the SCK signal to start toggling immediately when I call `HAL_SPI_Receive()`.

But currently, there is about a 5~10µs delay where SCK remains low before any clock edges appear.

[GgaGgung]

When I use the same SPI settings on the STM32F103 NUCLEO-F103RB, the clock signal is generated without any delay, as shown in the screenshot below.
I don’t understand why this delay only happens on the H7 board.a

[waclawek.jan]

I don't use the'H7 and don't use Cube/HAL, but maybe that function enables/disables the SPI at the beginning/end. If it's so, maybe avoiding that could help, but that would require to experiment by directly using registers. 

JW

[TDK · Accepted solution]

I don't think the H7 can achieve what you want. What good is a floating clock pin? What are you interfacing with?

[GgaGgung]

Thank you for your reply.
I initially thought the pull-down could be configured via the board settings, but that wasn’t the case.
I didn’t realize the clock pin was floating — that never occurred to me. After connecting a pull-down resistor, the issue was resolved.
I’m not sure why the F103 board doesn’t have this problem.
Also, I tried using a pull-up resistor, but it didn’t work — only the pull-down works. It’s quite unusual.

[AScha.3]

Maybe setting " keep io state" enable should do it, what you expect.