K64 SPI using DMA

JHinkle — Tue, 25 Oct 2016 00:40:52 GMT

I've had SPI with interrupts working for some time.

I wanted to look into using DMA so the cpu can continue working while the SPI is being serviced.

Is there any way to provide the 16 data + 16 bit command word to the SPI via DMA without doubling the buffer size by including the SPI cmd info in the data stream?

It seems to be of questionable use. Use DMA and take up twice the amount of ram to hold the data (16 bits of data + 16 bits of CMD) or service the SPI via an interrupt where the IRQ service provides the CMD and the ram buffer just holds data.

Any comments are welcomed.

Joe

UPDATE: - July 2017

I finally got it working - here's what I did.

I had resigned myself that DMA was not usable in my application (K64 needed to transfer 8k of data to a KL17 every 25 msec at a SPI baud of 12 mhz). I was using interrupts and all was well but I was not using the cpu efficiently.

July 2017, I re-approached the issue again.

Reading Earl Goodrich's comment below and reading the suggested documentation suggested that SOME Kinetis micros would allow their SPI to be processed with DMA - having DMA only update the 16bit data portion of the SPI PUSHR register thereby maintaining the 16bit control word first written to kick off the SPI transfer. The current K64 manual has wording that suggests that it would work.

I got DMA working by having DMA move 32bit words (my 16bit data + 16bit control) - works well but changed my ram requirements from 8k to 16k which was unacceptable.

I tried for hours to have DMA only update the SPI data but the DMA SPI update would always set the control word to zero.

The issue is that the K64 SPI requires 32 bits of data for each transfer (8/16 data + 16 control). The control word contains which chip select is to be utilized. The KL17 SPI is in slave mode and requires the chip select to operate -- but using DMA on the K64 resulted in the chip select being active for the first transfer (kicked off by software and DMA doing the remainder) -- once DMA took over, the chip select died (SPI control word set to zero).

So here is how to get the K64 working with DMA -- transferring 8 or 16 bit data packets.

DON'T use the SPI chip select on the master (K64 SPI)!!!!!!!

When setting up the cpu's port definitions, instead of having the SPI's chip select pins MUX'd to SPI - set them to general purpose OUTPUT I/O.

Manually control the SPI's chip select in software. I drive the chip select pin low before starting the SPI DMA transfer and set the chip select pin hi in the DMA's interrupt code upon DMA completion.

Very clean - works well - and no additional memory required.

Just thought I'd share.

Joe

Re: K64 SPI using DMA

egoodii — Wed, 26 Oct 2016 21:36:56 GMT

I have done the 'doubled up buffer' approach on K60 to refresh a monochrome OLED display, and in that case from a 'fixed allocation buffer' specifically so I could use bit-banding to draw pixels.

You will find that SOME (like K80?) of the Kinetis SPI documentation specifically list a (new???) mode whereby a lower- 8/16-bit write will 'repeat the last' upper-16 bits, and in THOSE devices you should be able to 'start the first' manually with the command bits you need, and let DMA run the rest as pure 8or16. See also:

K80 SPI DMA master mode

Re: K64 SPI using DMA

JHinkle — Mon, 24 Jul 2017 13:58:32 GMT

See Update in my original post.

Joe

topic Re: K64 SPI using DMA in Kinetis Microcontrollers

K64 SPI using DMA

Re: K64 SPI using DMA

Re: K64 SPI using DMA