slave spi on stm32f4 receives incorrect data

[deep]

I have an jetson xavier driving STM32F407G-DISC1 on SPI1 default pins : PA4/5/6/7 .
The SPI_FLAG_RXNE flag behaviour is very strange, resulting in wrong values being received.
Config used:

/* SPI1 parameter configuration*/
hspi1.Instance =         SPI1;
hspi1.Init.Mode =        SPI_MODE_SLAVE;
hspi1.Init.Direction =   SPI_DIRECTION_2LINES;
hspi1.Init.DataSize =    SPI_DATASIZE_8BIT;
hspi1.Init.CLKPolarity = SPI_POLARITY_LOW;
hspi1.Init.CLKPhase =    SPI_PHASE_1EDGE;
hspi1.Init.NSS =         SPI_NSS_HARD_INPUT;
hspi1.Init.FirstBit =    SPI_FIRSTBIT_MSB;
hspi1.Init.TIMode =      SPI_TIMODE_DISABLE;

In these plots CH3 is connected to a gpio that tracks SPI_FLAG_RXNE, while CH4 is connected to !SPI_FLAG_BSY .
What I expect to see is SPI_FLAG_RXNE firing with the rising edge of SCK on the reception of the 8th bit like this:

 However with this SPI driver the SPI_FLAG_RXNE signal seems to look like this:

 

Result is wrong data received.  This happens independent of SCK speed.  Validated the STM32 slave inputs using a simple bitbang SPI slave, and data is received with no errors.

SPI_FLAG_RXNE and !SPI_FLAG_BSY were brought out to gpio with something like:

volatile uint8_t rxd = 0;
while(true) {
  uint32_t spiFlags = hspi->Instance->SR;
  bool is_free = ! (spiFlags & SPI_FLAG_BSY);
  bool is_rx_buffer_ready = (spiFlags & SPI_FLAG_RXNE);

  set_gpio_led(led_orange, is_free);
  set_gpio_led(led_green, is_rx_buffer_ready);

  if (is_rx_buffer_ready) {
    small_delay();
    rxd = hspi->Instance->DR;
  }
}

[deep]

Yes bit flips are in MOSI (Orin->stm32) direction.  I run an echo server on stm side with something like:

  uint8_t tx = 0xAA;
  uint8_t rx = 0xBB;
  while (true) {
    HAL_SPI_TransmitReceive(&hspi1, &tx, &rx, 1, HAL_MAX_DELAY);
    //printf("slave: tx=%02x rx=%02x\r\n", txd, rxd); // only at slow speeds
    tx = rx;
  }

The slave->master interface seems to work at much higher speeds than master->slave. In any case, the round trip [test value] master -> MOSI -> slave -> MISO -> master [compare value] is used to deduce errors. 

MEMS accelerometer is NOT enabled, and i also tried out hspi3 on different pins with same result--direct connect SPI with slave stm32 spi fails at all freq.  

[waclawek.jan]

> In any case, the round trip [test value] master -> MOSI -> slave -> MISO -> master [compare value] is used to deduce errors.

I wonder, how do you distinguish master->slave from slave->master errors in this arrangement.

One possible explanation may be byte shift due to Cube/HAL being slow to fill the slave's Tx buffer.

JW

[deep]

When I return a known pattern from slave back to master, I still get garbage:

uint8_t txd [] = {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0x FF};

 

Noise on SCK signal means data is corrupted in both directions, as single posedge clock transitions are counted as multiple...

termination smoothes out the curves, but limits max speed:

 

 

the s

 

the standalone buffer here is really a level shifter with all VDD connected to 3.3V and and all grounds shorted.  Just used as a proxy for what the SPI SCK input on stm32 might be getting after the first stage of IO.

[ONadr.1]

Are you really sure that the power supply is powerful enough and the decoupling capacitors are sufficient and correctly placed? I've seen exactly that kind of SPI wobble before, and that was the problem.