spi slave weird data on mid-high speeds ?!

[arhi]

I am having weird issue with STM32F767 (configured to run at 200mhz) that needs to be SPI slave .. I configured it with 0,1 (clock low, second edge), hardware cs.. when master sends data at 350kbps everything is ok, when master sends at higher speeds output is random (like bits are swallowed).

code is super simple just hal_spi_transmitreceive() in a loop sending 2 same bytes non stop

it behaves like hardware can't catch up and start sending data late and slower than the clock...

[TDK]

Consider what it's connected to, the limitations of that device, and the limitations of the connections.

Long lengths of wire will not support 200 MHz. Heck, even short lengths may struggle at those speeds.

Ensure pins are set to the highest frequency speed.

Consider putting a logic analyzer or oscilloscope on the pins to ensure signal integrity is sufficient.

[arhi]

I'm looking at the https://community.st.com/t5/stm32-mcus-products/slave-spi-on-stm32f4-receives-incorrect-data/m-p/601574#M225721 and it looks like similar issue ...

200MHz is the mcu clock, I'm running SPI much slower ... attm 333kbps works ok, 666 "mostly ok" but 1.2mhz and 2.3MHz are totally messed up ... there is ADUM isolator between MCU and the MASTER device, and wires are .. ratsnest attm... LA is what I'm looking at now and it showing me these wrong data SLAVE (mcu) is sending, I'll attach a scope to the lines to see what's going on with clock on both sides of the ADUM ... ADUM should be good up to 90MHz but...

[arhi]

This is making less and less sense ...

code is rather simple:

 

...
tx_data[0] = 0xf7;
tx_data[1] = 0x7f;
tx_data[2] = 0;
tx_data[3] = 0;
for(;;) HAL_SPI_TransmitReceive(&hspi1, tx_data, rx_data, 2, 100);

...
static void MX_SPI1_Init(void) { 
 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_2EDGE;
 hspi1.Init.NSS = SPI_NSS_HARD_INPUT;
 hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB;
 hspi1.Init.TIMode = SPI_TIMODE_DISABLE;
 hspi1.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
 hspi1.Init.CRCPolynomial = 7;
 hspi1.Init.CRCLength = SPI_CRC_LENGTH_DATASIZE;
 hspi1.Init.NSSPMode = SPI_NSS_PULSE_DISABLE;
 if (HAL_SPI_Init(&hspi1) != HAL_OK) { Error_Handler(); }
}

 

So I should see on MISO line 0xF77F non stop.

What I see is same "shape" as 0xF77F only looking at some random clock. here is from LA at two different speeds of the MASTER:

and the scope on the clock directly on MCU pin (slave mcu) looks ok, not super perfect but ok

 

[arhi]

also, connections are rather short, between adum isolator and mcu is maybe 10mm, then after adum I have 5-10cm of wires only... so I doubt it's the issue with wires but I'm open to suggestions banging head with this for days

[arhi]

sending F77F

looking at both 666khz and 1.2mhz I see FF77 .. so first nibble is ?!?!?! then I have ok F77 and then I'm missing a nibble .. like whole word is "nibble late" ?!

CS is properly going up/down as expected and SPI is configured to use HW CS (

hspi1.Init.NSS = SPI_NSS_HARD_INPUT;

 

[AScha.3]

my tip: 

- use a "better" pattern, like : 0xA5A5

+ i have slave spi (over 40cm CAT6 cable for spi + power ) running at 32Mbit ; (sender is a ESP8266)  :)

[arhi]

I tried first with 5555 then aaaa then a5a5 then 5a5a ... this was just to easily see 2 bits and where they are and I see width of the single bit is ok, it just looks like some phantom clock is happening somewhere... if I could somehow output on some gpio pulse every time spi slave sees a clock it would be interesting to see ... the pcb is "terrible ratsnest" but between mcu and adum there's under 10mm and after adum I have few cm so not enough length for issues, also I do not see anything weird or bad on the scope (400mhz bw) ... but even at 400khz I see same %@#$_()^&#U@ .. I used some M4 to play master and slave and it works with same odrive at few mhz no problem over same wires, and I made it master to this 676 and even at 400khz I see this weird data :(

[David Littell]

A logic analyzer trace starting at the SPI slave's reset negation might show something interesting.

[arhi]

not sure I understand "spi slave's reset negation" - can you elaborate?

[David Littell]

Connect the SPI Slave MCU's NRST to the logic analyzer (in addition to the SPI signals you already have) and set the logic analyzer to trigger at the rising edge of NRST.  Have the analyzer record for long enough to include your 2-byte test sequence.  Look for a condition in the trace where CS is asserted (low) and there are some (spurious?) clocks on SCK before your 2-byte test sequence.  Have the logic analyzer display its analog channel for CS and SCK in addition to the digital channels.

Also, can the isolator be temporarily removed from the circuit?

 

[TDK]

Really can't imagine this is a PCB/interference issue at 400 kHz if the chips are 10 mm apart.

You have some weird bounce happening on the clock. Initial edge is super sharp, but then it bounces back and goes slowly to the rail. Could be a miscalibrated scope.

Also think sending a better pattern would be useful. Perhaps 0x0102, and the inverse, and post it here.

 

[arhi]

I tried different patterns, all look like there is phantom clock happening... I'll do more imaging and will upload later today ... I'm attm writing the sw on the working board with different stm so I can finish the sw part before I come back to solving this mess :(

 

as for "can't imagine this is a PCB/interference issue at 400 kHz if the chips are 10 mm apart." ... it is hard to imagine how bad pcb can be... our post is in strike for few months so can't order anything so we made it in-house and changed whole bunch of things after the fact so now it looks... well ..

[TDK]

That looks awesome. I'm sure you guys had fun making it.

[David Littell]

Why did you not start with a Nucleo and just design a board to plug in?

[arhi]

getting anything these days is super hard but nucleo with 676 (Nucleo-144) is not available anywhere, lead time is in hundreds of weeks and looks like ST stopped making them altogether so .. we would but .. at least we would use nucleo-144 for development instead of these ugly things but we used our last nucleo-144 on our previous project where we had to use our nucleo boards as we could not purchase chips anywhere as they were out of stock ...

[AScha.3]

so why not:

..in 3 days you have it. :)

+ in 5 weeks..