Possible SPI DMA bug in STM32K743IIK

Can you please post the problem it in terms of the relevant RCC and SPI and DMA registers content, possibly as read out while the problem persists?

JW

PS Oh, H7, so also DMAMUX

well, I could gather all the register values if really needed (if so in what format? hex dumps? named vars?)

but critical things are:

• TXDMA setup as MINC, MEM->PERIPH, 8 bit
• RXDMA setup as MINC, PERIPH->MEM, 8 bit
• SPI setup as 8 bit transfers (DSIZE 7), DMA enabled, any SPI mode, no CRC, software CS, any MBR, no FIFO, MASTER, full-duplex, no swapping, SPI Motorola, no MIDI, no MSSI
• DMAMUX setup doesn't seem to matter. Happens with different channels. Happens with both DMA1 and DMA2. I haven't tried it with MDMA.
• Saleae trace to confirm correct bytes are really on the wire
• if I use polled SPI transfers the problem doesn't happen

This is code that runs great on two other boards with different HSEs, and also runs great if D2PRE2 is DIV1. When I run with the 8 or 24MHz HSE I use the same clock tree, but change DIVM1, DIVM2 and DIVM3 to keep the rest of the clock tree the same. The change of making D2PRE2 go from DIV2 to DIV2 just changes the peripheral clock for APB2 from 96MHz to 48MHz.

oh also, happens with AXI SRAM, SRAM1, SRAM2, SRAM3 and SRAM4. DCache is enabled. Appropriate flush and invalidate ops are used. Register values for SPI and DMA all confirmed with debugger at initiation of transfer.

> well, I could gather all the register values if really needed

I personally am not going to jump on this as I'm not interested in the 'H7 at the moment; but providing *complete* information increases chances that somebody will be willing to look at it.

For example you hint that this is clock tree dependent, but you don't give definitive information on how this is set (don't expect everybody uses CubeMX and/or is willing to guess what other unpublished code might impact the clocks settings).

You also said that "DMAMUX setup doesn't seem to matter" but how do you know? For me this looks like two DMA transfers per one trigger from SPI, and it's DMAMUX which processes triggers from peripherals and forwards them to DMA(s).

> (if so in what format? hex dumps? named vars?)

Any, provided the info is complete; but if you can make it decoded to names, it makes life easier.

JW

PS. If you "manually" read two bytes out of SPI upon each incoming byte, is the second read byte 0x00?

One more question: the DMA's NDTR indicates what, the number of bytes arrived on SPI, or the (twice as much) number of bytes stored in RAM?

JW

@JW, your question made me realise I'd explained the issue rather badly. I explained it a bit better in the (long) ChibiOS forum thread, but my description above is quite misleading.

Using the example of a SPI slave device that will return bytes of 0xaa 0xbb 0xcc 0xdd etc etc, then the following happens:

• if you read 3 bytes you get 0x00 0xaa 0x00 in memory after the transfer is finished
• if you read 6 bytes you get 0x00 0xaa 0x00 0xbb 0x00 0xcc
• if you do the read without DMA then you get 0xaa 0xbb 0xcc for a 3 byte transfer as expected
• if you set D2PRE2 to 1 then transfer with DMA you get 0xaa 0xbb 0xcc for a 3 byte transfer as expected

Also note that in all these examples it is full-duplex SPI against a device that has a register based access method. So when I say "read 3 bytes" it actually does a 4 byte SPI transfer where the first byte is the register number in the SPI slave. This is important as it means that DMA rx engine is actually being given 4 bytes to feed into memory, specifically 0x00 0xaa 0xbb 0xcc, and the actual bytes that appear in memory when doing a 6 byte read (which is a 7 byte transfer) is 0x00 0x00 0xaa 0x00 0xbb 0x00 0xcc. The DMA engine and the SPI peripheral have no way of knowing the register read conventions of the SPI slave device.

So the SPI with DMA transfer is injecting extra 0x00 bytes into the transfer after each correct byte, and then stops the transfer when the total number of bytes requested is reached.

My apologies for the lousy explanation in the original posting.