STM32L4 - DMA with SPI in slave mode doubles the first byte loaded into DMA

sergey239955 · ‎2020-01-30

We are migrating from STM32F103 to STM32L4. The code architecture is the same, as the product basically is the same. We just upgrade the micro.

We have an SPI that is configured in slave mode, and a device that supplies clock to the SPI. DMA is used to feed the SPI with data. What we do is we first init SPI, then we init and load DMA with data, then we enable DMA request and a few milliseconds later we enable the clock source. Everything is very basic and works absolutely fine on STM32F103.

We found that the STM32L4 with practically the same code (save for specifics of peripheral configuration) doubles the very first byte loaded into DMA. Say, if you load a string of 5 bytes 0x1, 0x2, 0x3,0x4 and 0x5, the SPI will output 0x1, 0x1, 0x2, 3, 4, and 5. Whatever the first byte is, it will be doubled (we suspect by SPI) because the DMA count is correct. Meaning that the DMA will stop after 5 bytes, while the SPI will output 6 bytes.

Anyone saw anything similar to it? We are positive that it is not our bug. It is almost impossible to do even if we wanted to. And the same code works fine in STM32F103.

sergey239955 · ‎2020-02-03

Thank you JW for asking all right questions, and other guys for spending your time helping out.

I am sure the idle clock polarity is what causes SPI to behave this way. I kinda feel stupid for assuming too much. Too much emphasis was made on the fact that it is migration from a working project. Too much time spent looking at the code and not probing the lines.

Cheers!

sergey239955 · ‎2020-02-03

Yes, it is solved. Thanks!

sergey239955 · ‎2020-02-04

Hi JW,

it doesn't seem that SPI takes the configuration which sets the high level of idle clock

SPI_InitStrToFromRadio.ClockPolarity = LL_USART_POLARITY_HIGH;

There is no data on the SPI output. The moment I configure it for the (default) SPI_InitStrToFromRadio.ClockPolarity = LL_USART_POLARITY_LOW,

I see the data (albeit with that double first byte issue). Did you hear anything from ST about this issue?

sergey239955 · ‎2020-02-04

Sorry, never mind. Accidentally used the USART define instead of SPI

MRosc.1 · ‎2022-03-29

I am having a similar issue.

Do you remember what the problem was?

sergey239955 · ‎2022-03-29

There was a problem with the idle state of the SPI clock. It didn’t correspond to the SPI settings. Waclawek.jan pointed it out.

waclawek.jan · ‎2022-03-29

Thanks for the reply. I did not remember this...

JW