K70 DMA Transfer to DDR2

[MTaylor]

I'm trying to use the DMA to transfer data from an ADC result register directly to the external DDR2 memory using CW 10.2, the bare metal source code, and the TWR-K70F120M board.

There is a PIT that triggers an ADC conversion which, when complete, triggers a DMA request to transfer the result to a destination.  I'm able to use the DMA to transfer the ADC data to areas in the internal memory, but if I try to set the DMA_TCDx_DADDR to the start of the external DDR2 RAM (0x70000000) , then the data doesn't get transferred.  

Specifically, the memory monitor reads the contents of all the memory near 0x70000000 as "0x42000023" - the same value everywhere!  In fact, all the  registers in the 'Registers'  tab read back as "0x42000023" after attempting such a transfer - although restarting the app, returns the registers to normal values.

Is the DMA supposed to be able to transfer anything to the external DDR2 memory?  I've tried using the CPU to move stuff there and that worked.  The memTest routines in the bare metal source code work fine in the DDR2 region.  What am I missing here?

Thanks in advance!

[MTaylor]

I'm using the K70 tower module and the PEOSJTAG option from CW.  I updated the PE firmware 2 months ago.  I don't really know any more than that.

[MTaylor]

The speed of the transfer is not a big issue for my setup (we're sampling at 200kS/s, so the DMA has 5us to finish the transter).  As such I haven't played with any cache settings.

It seems though, that there is a CW issue with reading the data back from the DDR2 region.  As I mentioned, the CW memory monitor will read back EVERYTHING as 0x42000023 when you try to make it read from a memory address inside the DDR2 range.  Maybe this is something to do with the debugger?  

Using printf() statements to view the memory shows that the correct values are being transferred to the right places in memory.  However, I find it a bit dissapointing to have to do this...

[konrada]

MTaylor, are you using a Segger J-Link? We are, and we had to upgrade the JLink.dll a couple of times until we could access DDR2 in the debugger. (Using 4.44d right now)

[konrada]

We're using DMA on a K70 (board of our own design), and DMA to external DDR2 memory did work for us, although it was so slow (and competed with code execution from external DDR2) that we went to internal memory instead for all DMA buffers.

Have you tried using the corresponding address in the 0x8xxx_xxxx range, which is write-through instead of write-back cached? Have you disabled/flushed the cache?

[ColoPaul]

Update.   We are now able to use DMA/DDR2/peripherals.  We were experiencing two problems.

With one module,

Problem 1 was related to speed - so with the buffer in DDR2 it wouldn't work regardless of cache enabled/disabled.

With a second module

Problem 2 was related to the cache.   The buffer in DDR2 would work with the cache disabled.   But we need the cache of course,  so the workaround was to use the 0x8XXXXXXX range for the buffer (kudos to Konrada for pointing this out); but beware - that range is by default "write-through"; and (at least for our case) needed to be changed to "non-cacheable".  

[ColoPaul]

We have repeatable issues with DMA/DDR2/KSPI and DMA/DDR2/USB. Basically, if the DMA transfer is between internal SRAM and a peripheral everything is great - if you instead use DDR2 (everything else exactly the same), the transfers don't work correctly. I have submitted this problem to "Alejandro" at "support@freescale.com" who replied (on 4/16/2012):

...I tested as well the DSPI driver as interrupt so it can work with the DMA of MQX running in DDR and it fails as well. On the other hand when it executes from internal flash it works. I will try to create a simple project but in bareboard so we can isolate the problem.

Apparently there is some issue with K70/DMA/DDR2. I would like to get some clear acknowledgement from Freescale and details regarding useable workarounds.

BTW - we have tried disabling the cache - no difference.