STM32L462RE - SPI slave duplicated first word

[MRosc.1]

 Hi,

I am porting a project from STM32F103RE to STM32L462RE.

I have an issue with the SPI slave.

My problem is that in the data I send back to the master always has the first word duplicated.

I found out that more people have a similar issue:

https://community.st.com/s/question/0D53W00001ROcGvSAL/stm32l476-spi-slave-mode-with-dma-repeated-first-character

https://community.st.com/s/question/0D50X0000C3CIjdSQG/stm32l4-dma-with-spi-in-slave-mode-doubles-the-first-byte-loaded-into-dma

The code works fine on F103 but duplicated the first word when I ran it on L462.

The STM32 is a SPI salve uses DMA cpol and cpha are 0 Spi click is around 11Mhz.

I reset the SPI before every read/write operation.

The master is embeded linux with the same settings.

Here is a snip of the spi lines with a logic analizer.

F103:

L462: 

Any idea what the issue could be and how could I fix it?

[TDK]

Hard to say without showing any code. The SPI will clock out the same data if it's not fed new data, perhaps it's not initialized correctly at the time the master wants data.

Would recommend flipping pins at specific points in the code to understand where it's at relative to the master clock.

[waclawek.jan]

> I reset the SPI

Like here?

https://community.st.com/s/question/0D53W000013LSffSAG/clear-spi-tx-fifo

JW

[MRosc.1]

It seems that there is a fix that could work.

There is a problem with the idle state and phase of the SPI clock.

The following settings worked:

1. STM32L462 which is a salve I have CPOL and CPHA set to 0 (clock is 0 when idle and the first clock transition is used for capturing)
2. Linux Embedded which is the master: CPOL and CPHA set to 1 (mode is 3 / clock is 1 when idle and the second clock transition is used for capturing)

This seems a bit odd, since the same master (linux embeded) whith no changes could read data from F103 with mode 0 (cpol=cpha=0) which is the expected behaviour.

But we can say that this is a potential fix.

[MRosc.1]

After a more detailed investigation it seems the reason for this issue was the fact that the time between slave enable and the output of the clock signal was too short for STM32L462.

The linux master ran the clock 30ns after the ss pin was set to low.

After changing this time to 60ns everything looks better.