eDMA Error when combining eDMA DSPI Driver and USB CDC in one project (Kinetis K64F, KSDK 1.1.0)

[kora]

I'm working on a project where I'm reading data from an ADC (ADS129x) using SPI and transferring this data to a host PC via a virtual COM port. The project is based on the Kinetis SDK 1.1.0 (DSPI Master & eDMA library and Kinetis USB Stack with CDC Virtual COM demo) and implemented on a custom PCB with a K64F12.

I was using the interrupt based DSPI driver until now and things were working fine. In order to improve the possible throughput I switched to the eDMA version of the SPI driver, and the change went smoothly. Communication over SPI is working as expected and stable over long time periods.

The problems arises as soon as USB enters the picture. Any form of data transmission over the USB Bus (even the USB enumeration process is sometime enough) will cause a sporadic DMA Error. The error always happens on the DMA channel which is used by the DSPI driver as a "Source buffer to intermediate command/data" and shows itself by causing an DMA_Error_IRQn interrupt from which the error interrupt handler of the eDMA library cannot recover.

Any suggestions what could be the cause for this incompatibility between DSPI and USB, or how to obtain more details on the cause for the eDMA Error?

[mjbcswitzerland]

Hi Konke

Check the eDMA error register since it indicates both the source of the error and the reason for it.

Check also the DMA pointers because you will probaby see an offending address there (compare with typical values to when it is operating normally)

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[kora]

thank you for your fast reply

The error is an NBYTES/CITER Configuration Error:

The last recorded error was a configuration error detected in the TCDn_NBYTES or TCDn_CITER

fields.

• TCDn_NBYTES is not a multiple of TCDn_ATTR[SSIZE] and TCDn_ATTR[DSIZE], or

• TCDn_CITER[CITER] is equal to zero, or

• TCDn_CITER[ELINK] is not equal to TCDn_BITER[ELINK]

and it happens in one of the DMA channels of the DSPI driver, which is the part that I do not understand, as the USB functionality shouldn't affect the contents of the TCD control register of another channel

[mjbcswitzerland]

Hi Konke

Maybe there is code in the USB part that is using a DMA channel to perform memory->memory transfers and colliding with the DMA channel used by the DSPI?

What happens when you disable DMA at the DSPI? Can you then see that DMA is still being configured?

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[kora · Accepted solution]

Well I was aware that the USB module is using DMA to transfer data SOC internally and independent from the driver.

e.g. p1288 in the K64F Reference Manual States:

"When a USB token on an enabled endpoint is received, USBFS uses its integrated DMA

controller to interrogate the BDT. USBFS reads the corresponding endpoint BD entry to

determine whether it owns the BD and corresponding buffer in system memory."

I had assumed that this interferes with with the channels used for SPI communication but didn't put the parts together. Turns out it is the initialization order of the modules. In my case I initialized the USBOTG module first and the eDMA and DSPI (Kintis SDK Driver based) module afterwards. This leads to conflicts because the USB module will make assumptions about the configuration of the DMA module which will no longer hold true after the initialization eDMA module and leads to interference in because it tries to use channels that are used by the DSPI module.

So the problem can be fixed by enabling and configuring the eDMA module before initializing the USBOTG module. In this way the USBOTG module recognizes that the eDMA controller is used for other purposes as well and doesn't cause interference

Thank you very much for your input - you definitely pointed me in the right direction!