Asynchronous transfer from EMIFA to DDR using EDMA3 skips data

David Luca

Hello,

We have an asynchronous device, a 16bit ADC connected to data lines and using RD and CS lines from EMIFA, conversion complete signal to GPIO that triggers EDMA event and we setup a transfer to DDR memory using EDMA3, it is supposed to transfer continuously 4 samples of 16bit of data. L1P cache is enabled, L1D disabled, and L2 is enabled and we are using SYS/BIOS to configure this module.

This setup works fine if I'm transferring into internal SRAM L1D or L2 , but whenever we try to use aligned DDR buffer, we can see that in a 4 samples transfer the 3rd 16bit data is not copied into the buffer or sometimes 1st and 2nd and so on. We are clearing the buffer with 0xFFFF and we can see data is not overwritten for a random number of this transfers. The SAM/DAM bits in the PaRAM option field are set to INCR, ACnt=2, BCnt=4, CCnt=sizeof(buffer), srcAddr=0x64000000(EMIFA). (corrected)

Basically the buffer looks like this:

sample1, sample2, sample3, sample4,

sample1, sample2, 0xffff, sample4,

sample1, sample2, sample3, sample4,

Any idea what's happening?

Thank you in advance,

David.

over 12 years ago

0 RandyP over 12 years ago

TI__Guru* 84110 points

David,

Which DSP are you using?

What are all 8 PARAM registers set to? The 8 32-bit hex values will be good.

You said "L2 is enabled". How much of L2 is Cache and how much is SRAM?

Turn off the MAR bits that apply to the DDR space to which you are writing and see if that affects your results.

The fact that it works for a destination in internal memory but not in external memory implies a cache problem, although the signature does not match what you would expect for a cache problem.

Just to add something to do after that, look at the DDR bus to see what the interface signals are doing, in particular what is being written to the DDR. And also look at what is being read on EMIFA and how well it matches the timing requirements of the DSP.

And change your initialization value to 0xbebe instead of 0xffff. Both init values of 0x0000 and 0xffff can hide data access problems; unlikely, but simple to deal with.

Regards,
RandyP

0 David Luca over 12 years ago in reply to RandyP

Expert 2795 points

Hi RandyP,

Indeed it was a L2 cache problem, testing with L2 disabled made the transfer working fine into DDR. I will try with the value you suggested. L2 is now enabled full 256k and I added Cache_inv calls after a buffer was filled in the interrupt handler when transfer is completed and just before reloading next buffer and the buffer values look fine. Timings on EMIFA seems fine as well, it matches the requirements for reading from ADC (24ns for a read cycle).

Thank you very much for your help,

David.

0 RandyP over 12 years ago in reply to David Luca

TI__Guru* 84110 points

David,

It may help you to try some tradeoffs with 50% L1D cache or some mix like that. L1D cache is very valuable and helpful, but it can also be very valuable and helpful as SRAM.

When you say L2 is now enabled full 256K, is that fully cache or fully SRAM?

Regards,
RandyP

0 David Luca over 12 years ago in reply to RandyP

Expert 2795 points

Hi RandyP,

Forgot to mention, we're using C6748. L2 is full cache at the moment, but we plan to use only 128K and rest SRAM and leave L1D as full cache and L3 is stack. No issues using 0xbebe or 0x55aa. The DMA was setup so that it reorders each sample into its own buffer, that's why printing from the affected buffer revealed the problem.

Best regards,

David.

Processors

Processors forum

Asynchronous transfer from EMIFA to DDR using EDMA3 skips data