STM32F103 SPI DMA slave mode sends first byte twice

[mattb3.14159]

I have an STM32F103 configured in slave mode using NSS for slave select and using DMA. I'm using 8 bit mode. When the master starts clocking the STM32F103 it always shifts out the first byte in the buffer twice. So rather than seeing 0xF0, 0xF1, 0xF2, 0xF3, I'm seeing 0xF0, 0xF0, 0xF1, 0xF2 shifted out and then I get the DMA transfer complete interupt.

If I call it in 16 bit mode, (and I change the DMA PSIZE and MSIZE to be 16 bits as well) and do a transfer of size 2 ( to get my four bytes) it works perfectly (even though the data is transmitted little endian but I expect that)

I've read a whole bunch on this today but not much turned up so I expect it is something I'm doing. I don't really want to use 16 bit transfers as I would have to massage the data so it's in big endian format when tranmitted which wouln't be acceptable.

I've also tried 8 bit mode but leaving PSIZE and MSIZE as 16 bits and it shifts out 0xF0, 0xF0, 0xF2, 0xF3.

Any ideas?

[mattb3.14159]

Sorry that wouldn't let me put the code in as it was too large so I put it in a file and when I came back the message had posted. Here's the code.

[waclawek.jan]

> I have an STM32F103

Blue pill (i.e. probably a counterfeit)?

JW

[mattb3.14159]

Nah it's a legit chip purchased through Arrow.

[waclawek.jan]

Which STM32F103? The 'F103 is the oldest STM32 and I am not sure there are many people out there still using it actively in new designs.

I don't see anything obviously wrong in the code.

Upon which timulus do you call the transmit snippet you posted (in "main")? Is the problem still the same with different values (wildly random)? And what about a different number of transferred data?

Observe the SPI bus using LA and post screenshots (including NSS).

Reduce the code to minimum but complete compilable example which still exhibits the problem (i.e. exclude potential impact of any other unrelated code).

JW

[mattb3.14159]

STM32F103ZGH6. The chips came from Arrow, though I'm looking at that date code and it looks like the 1st week of 06. Yikes. They were supplied to me in a tray from the company who I contract for and they bought them from Arrow.

I have a CPLD that has the SPI master on board. After I load up the buffer and call the TxferSPIBuff, I pull a GPIO low on the STM which tells the CPLD to start the transfer. It shifts some header bytes out on the LVDS (obv my transmission medium) and then when the CPLD needs the bytes from the STM it pulls NSS low and starts the clock.

The first image is the clock with yellow trace and the NSS with blue trace. I did have an issue with NSS when I was bringing it low (from the FPGA) too fast and I was sometimes missing the first bit. I extended the time from NSS going low to the first clock to a full byte and also after the last clock so those timings are good (according to the datasheet). The NSS timing is exacly the same for both 8bit and 16bit modes shown next.

The third image is 16bit mode with both PSIZE and MSIZE set to 1 and the DFF bit in the SPI CR1 also set to 1. I'm setting the transmission length to 2 in this case so I get my 4 bytes. The buffer contains 0xF0, 0xF1, 0xF2, 0xF3 so you can see I'm getting those in little endian format as expected.

The fourth image is both PSIZE and MSIZE set to 0 and also DFF set to 0. The transmit buffer again is 0xF0, 0xF1, 0xF2, 0xF3. I'm setting the data tranmission size to 4 bytes for this one.

I've had it up on the debugger all morning playing with the DMA and SPI registers and setting bits in different orders, trying all combinations of PSIZE, MSIZE and DFF and killing the SPI clock and re-enabling it before enabling SPI for every transmission (and tried DMA like this as well) but absolutely nothing will stop that first byte being sent twice in 8 bit mode. I've pretty much tried bit that

I'm going to have to leave it at the moment, I'm going to set it to 16bit mode and do the endian massage on the bytes. I have to test other things so I will get back to this in due course.

[mattb3.14159 · Accepted solution]

My crystals arrived so I stuck one in and clocked it up to 72MHz and it runs fine now. I completely forgot that they were missing from my order and I was running on the HSI 8MHz oscillator. Thanks for your help anyway, JW.

[waclawek.jan]

OK so it was a classical case of data underrun. Transfer complete is due to the fact that the last frame while not transmitted on wire due to master not issuing more clocks, was already buffered in the SPI buffer. This would be revealed at the next transfer's beginning.

Thanks for coming back with the solution. Please select your post as "Best" so that the thread is marked as solved.

JW