Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hi Lars,

The tcDspQDMA class handles all of the setup for the dma, so you don't need the HWI_eventMap() call. That may be your only mistake. Try your code without that.

Dave

Hi Dave,
Thanks for the reply.
I tried that - still the same problem.

My sense is that this has something to do with how DMA gets configured. The comments in the DspQDMA.cpp code mention (in a comment)
"// EDMA3 features specific to your device (e.g. found in bios_edma3_drv_sample_C6455_cfg.c)"
so I (very naively) picked the corresponding file for the L138 as my configuration file.

It would be helpful to me if anyone could shed some light on the configuration files and libraries needed to make DMA work on the MityDSP-L138.
Thanks,
Lars

I assume you are not actually using any .c files from the EDMA code? If so, get rid of those. All you need from the EDMA installation is the library files. Specifically, make sure you have this in your Search Path (under project Build Options | Linker in CCS3.3 -- not sure exactly where in CCS 4 or 5):

$(L138_2013-05-15)/sw/3rdparty/edma3lld_01_11_00_03/packages/ti/sdo/edma3

and make sure you have the following in your Incl. Libraries (under project Build Options | Linker):

drv/lib/Release/edma3_drv_bios.lib;drv/sample/lib/c6748/Release/edma3_drv_bios_sample.lib;rm/lib/c6748/Release/edma3_rm_bios.lib

These should pull in the necessary code for the L138.

Dave

Thanks Dave,
That was a lot of useful information!
I did indeed pull in some off the mark libraries during link time.
So I cleaned up my project, making sure to use the EDMA3 libraries from from the MDK instead of the copy installed on my PC.
Everything builds nicely again, but I still get an error message from Linux: davinci_mmc davinci_mmc.0: DMA write error.
(A couple of minutes later there are a host of Linux error messages about timeouts and hung tasks.)

I am going to continue working on resolving this - I noticed that there are some differences between the C6748 and L138 configs and will see if anything comes out of that.

My suspicion is that if I build a Linux kernel without MMC support, everything will work fine.

Thanks for your help -
Lars

Hi Lars,

I am currently working on a project that uses the QDMA class to move data between the FPGA and memory, and it has the MMC support compiled in, so I don't think that is it. You can try it, but I'd be surprised.

You could also try another hardware interrupt. I'm using interrupt 8 in my application and that's working fine. Maybe try that instead of 7?

Dave

Dave,
I have confirmed that if I run Linux off the built in flash disk (and disable MMC support) I can do DMA transfers on the DSP without causing any issues with Linux.
There definitely seems to be a conflict between how Linux allocates DMA hardware and how it is done on the DSP.
At some point I will take the time to figure that out. If someone has ideas, I am all ears.

Thanks,
Lars

Hi Dave,
I have done a full matrix of experiments, interrupt 7 or 8, with and without MMC in the kernel, and booting off the internal flash or MMC.
Both interrupt 7 and 8 give the same results.
My test program works fine with MMC support included in the kernel.
However, it looks like there is trouble brewing as soon as you access the SD card:
If I boot off the internal flash with MMC enabled, my little test program works fine. But, if I later mount the file system on the SD card, i will get error messages and a system crash.

If I boot the same kernel off the SD card, I immediately run into trouble when I run my code in the DSP.
As far as I can tell, everything points to a conflict between Linux and DSP/Bios in the way they share the EDMA hardware.

Lars

I will have to give that some thought. It was my understanding that the two processor each had use of a different part of the DMA engine, and so they shouldn't conflict. I wonder if somewhere along the way that rule has changed. I'll look around and see what I can find out.

Dave

Dave,
I think I found the problem.
When comparing the board definition file for the da850 evm (board-da850-evm.c) and the mityomapl138 (board-mityomapl138.c), I realized that the latter file did not reserve any dma resources. (It simply calls da850_register_edma(NULL).) The code in board-da850-evm.c, on the other hand, does reserve EMDA resources on both channels. (Which makes sense since some peripherals seem to be tied to certain channels in hardware.)

With nothing much to lose, I transplanted the definitions from the da850 evm code into the mitydsp code, built a kernel and tried it out.

With that change, I no longer get the error messages from Linux when I run my test program.

Lars

Hi Lars,

This is interesting... I did not think that the linux code was using the Quick DMA PaRAMS. I know you had to do this if you were planning to use dedicated PaRAMs for peripheral blocks, but not for the Quick DMAs. Sorry that that was not pointed out.

-Mike

I too am having a lot of trouble implementing EDMA on the DSP using LLD. But I don't understand Lars' last post. As far as I can see, looking at the files in ../arch/arm/mach-davinci, the call to da850_register_edma() is not meant to have a parameter - the function is defined in 'devices-da8xx.c' and uses definitions for reserved channels and slots that are defined in that same file. So it seems to me that MityDSP core does reserve channels/slots for DSP EDMA...

Now to my problem: I have tried to get the simple example: Example 4 from the 'tto_lld_6455' set of examples - available from this link:
https://gforge.ti.com/gf/project/lld_examples/frs/

from TI working on the industrial I/O board (modifying the tcf file to use the critical link platform, picking the right libraries, etc). The example couldn't be much simpler - I have even changed it to a manual start, but I cannot get past the first transfer interrupt and nothing ever gets transferred. I'm not having any apparent problems with linux - running the program using either controller 0 or 1 does not seem to affect linux, but with controller 0 I get at least one transfer complete interrupt, but with controller 1 I get no interrupts at all. In the example, intermediate transfer interrupts are enabled, so there should be 32 interrupts for a successful transfer.

I have recently been working on a project where we ran into conflicts between QDMA's on the DSP side and MMC use on the ARM side. After much wandering around in the source code, it appears that the ARM code doing DMA for the MMC is using PaRAM resources that the DSP is also using for QDMA's. To resolve this, I now initialize the EDMA drivers on the DSP side to indicate that the DSP doesn't own the DMA channels associated with MMC, and, similarly, that it doesn't own the bottom half of the PaRAM resources. This forces the QDMA's to use high-numbered PaRAMs, which keep it well away from any likely usage by the MMC. After making this change, our system is now working very reliably.

Here's the change I made in the QDMA source code:

initCfg.drvInstInitConfig->ownPaRAMSets[0] = 0x0FFFFFFFu;
    initCfg.drvInstInitConfig->ownPaRAMSets[1] = 0x00000000u;
    initCfg.drvInstInitConfig->ownDmaChannels[0] = 0x0FFFFFFFu;

I added these lines just prior to the EDMA3_DRV_open() call.

Dave