Unexpected DMA transfer when DMA request is enabled for SPI1 TX

[gpontis]

K60 / IAR

I am tying to use DMA to transfer a large block of 8b data through the SPI interface. My code is mostly working except for one fatal flaw. That is that I get an unexpected transfer as soon as the DMA request is enabled. At the time that this happens, the DMA has already been set up with CITER, BITER, a source pointer, attributes, and so on. In my case the attributes call for 8 b source and 8 b destination. After the unexpected transfer occurs, I see that CITER has decremented by 4 bytes ! Typically I am making transfer much larger than that, and the remainder of the transfer does not occur until the SPI module is re-enabled by clearing the EOQ flag.

My original code started the transfer by writing the SPI1_RSER to set TFFF_RE, but exactly the same happens if I leave that set and then write the DMA_ERQ.

The transfer of 4 bytes seems completely incorrect given that DMA_TCD4_ATTR = 0. As an additional test I tried pointing the source address to known data, but that data does not appear to be used. The upper 16 bits, which are written to the command field of the TX FIFO, are all 0. This fact makes it difficult to work around the problem.

Has anyone else seen this, or have a suggestion where to look ?

George

[mjbcswitzerland]

Hi

I think that it is normal that DMA transfers take place if the SPI in enabled and the DMA is configured. The SPI has a 4 deep Tx FIFO and so it wants to fill this up, meaning that it will immediately request transfers.

You can verify this by writing 4 entries to the SPI to fill up its Tx FIFO before enabling transmission. Then when the DMA is enabled there will be no request pending - the SPI will of course send the 4 entries when enabled and then also immediately request more data as soon as the first one is sent.

To avoid it you could keep DMA disabled until the SPI is to be filled or you could disable the source request at the SPI or in the DMA mux.

Regards

Mark

[gpontis]

Hi Mark,

I tried many iterations on how to enable DMA or the request but was not able to find any version that avoided the spurious transfer. Eventually I came to the conclusion that there is something about the DMA controller that caused it and probably is not documented. Note that the spurious transfer was for 4 bytes, even though my code had already configured DMA for single byte transfers.

I glanced at the MQX driver and see that there is a full DMA implementation using SPI. But by that time I had done a non-DMA workaround and got the project back on track. I intend to revisit this as the secret to making it work must be in that code.

George

[dougmann]

George/Mark,

I have found the same behavior for the SPI1RX. It is good to see that I am not crazy.

[dougmann]

Nevermind. My issue was due to setting the START bit in the CSR register. This was triggering a software request and causing a spurious transfer. This is documented in the init section of the HW Ref manual.

[Kan_Li]

Hi George,

which device are you using？ I will help to check here if there is example available for your reference.

Thanks for your patience!!

B.R

Kan

[gpontis]

Hello Kan-Li and Ping,

Thank you for such a quick response. Eventually this will run on a MK60DN512ZVLL10. For now I am testing on the demo board TWK-K60D100M. The SPI1 pins that I am using have the same configuration for both processors.

I can't upload the whole project but I am attaching the file with the spi code. To clarify the operation, this code sends the first byte with a 32b write to the SPI FIFO. The purpose of this is to configure the control word for the chip select and other parameters. Then the bulk transfer is done by the DMA. Finally the last byte is transferred with another 32b write which deasserts the chip select.

George

[Kan_Li]

Hi George,

I just quickly reviewed your code, and found the driver is for some RTOS, is it MQX? Actually the current MQX is 4.0.2, in which Kinetis SPI driver was updated to use the eDMA driver. Please kindly help to clarify.

Thanks and Best Regards,

Kan

[gpontis]

I only used a semaphore to lock the resource, but it is MQX 4.0.2. Thank you for pointing out that 4.0.2 SPI driver supports DMA. I will try it

[jeremyzhou]

Hi George,

Could you upload your project in the thread? It's convenient to debug and fingure out the problem if I have your project.

I'm looking forward to your reply.

Best regards,

Ping