SPI half duplex slave transmit, data shifted / loses sync when using CLK Phase 2

[DavidAlfa]

MCU: STM32F411CEU6

IDE: Cube IDE v1.6.1

Init code (Only CLKPhase changes between tests, 1=Leading edge, 2 =Trailing edge):

static void MX_SPI1_Init(void){
 hspi1.Instance = SPI1;
  hspi1.Init.Mode = SPI_MODE_SLAVE;
  hspi1.Init.Direction = SPI_DIRECTION_1LINE;
  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.FirstBit = SPI_FIRSTBIT_MSB;
  hspi1.Init.TIMode = SPI_TIMODE_DISABLE;
  hspi1.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
  hspi1.Init.CRCPolynomial = 10;
  if (HAL_SPI_Init(&hspi1) != HAL_OK)
  {
    Error_Handler();
  }
}

Test:

volatile uint8_t msg[20]={ 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 };
 
void main(void){
// HAL Init, etc ...
	
  if(HAL_SPI_Transmit(&hspi1, msg, 12, HAL_MAX_DELAY) != HAL_OK){
	  asm("nop");		// Stop here if not ok (Always OK)
  }
  while(1);  
}

After starting HAL_SPI_Transmit, I send train of pulses.

The slave sends only 1s for easier detection.

CLKPhase = 1: Works ok. Also works with both clock polarities.

CLKPhase = 2: The data shifts and loses sync. Happens with both clock polarities.

I thought I was being too fast.

So I tried adding 1mS delay between clocks (Byte - delay - Byte - delay ...) but the result was the same.

Might this be related?

https://github.com/ARMmbed/mbed-os/issues/10589

Althought I checked the HAL code and it seems correct.

 

[DavidAlfa]

I updated the message, It's not sending random garbage, it's the data that shifts and loses sync.

[waclawek.jan]

Hi David,

> Might this be related?

> https://github.com/ARMmbed/mbed-os/issues/10589

You mean https://github.com/ARMmbed/mbed-os/issues/10589 ? That appears to talk about a shift of one bit for the whole transaction, not for each byte in it. But you can try to pulse SSI high/low before the transaction; it should mitigate this particular issue.

Can you please read out and post content of SPI registers.

Thanks,

JW

[DavidAlfa]

Yeah, I read them out a lot of times, both were exact the same at any given moment, only CR1 bit 0 ( CPHA, Clock phase) changed.

I think it might be a noise problem.

The SPI signal is not crazy high (1.7MHz), and the logic anaylizer sees everything ok, but I shortened a bit the wires and started working in both modes.

Or it might be a lucky shot, I'm still testing, will update later.

[waclawek.jan]

Can you please read out and post content of SPI registers.

 [EDIT] No need if the problem is in the wires, see below [/EDIT]

JW

[waclawek.jan]

> The SPI signal is not crazy high (1.7MHz), and the logic anaylizer sees everything ok, but I shortened a bit the wires and started working in both modes.

Oh. Wires? Tell us more. Post photo.

It's not the SPI clock rate, but the edges slew rate, which are important. Use terminators (series resistors in the order of few tens of ohms), and if you can change the slew rate, decrease it (e.g. if master is STM32, use a slower GPIO_OSPEEDR rate).

If you use wires/cable, make sure they are as short as possible, 10cm is a reasonable length, anything beyond that needs more care. Make sure every signal has its own return (ground), if you use flat cable, make sure each other wire is ground; otherwise twist the signal with its own return.

JW

[DavidAlfa]

WQell, the culprit was the logic analyzer! Wires were not loo long, about 10cm.

But also they were plugged into a breadboard, that's asking for trouble at high frequencies.

The SPI worked well until I plugged the analyzer wires.

My problem was always at answering, (transmitting back).

Since I removed the analyzer everything is working.

I guess capacitance was too high or it caused ringing / signal reflection.

I don't have DSO right now, so I couldn't check the signal integrity.

Huh, try to see those things with the analogic one! :face_with_tears_of_joy: 

The strange thing is that it always worked with clock phase 1.

That totally misleaded me!