66AK2H14: EDMA and DDR3A interface

Hi,

I can't see your attached picture. >>>>>>>>(Also note that note only the DMA stopped but it becomes impossible to CCS to recover access to the component)>>>>

• Do you mean that you loss the JTAG and can't connect to the K2H anymore? what is the error message? 
• What core (A15, DSP) you run the test?
• How big is your DDR3A memory? In case it is bigger than 2GB, do you use MPAX to map the 36-bit physical address to logical address?  
• Will CPU read and write the full DDR3A range always pass?
• When using EDMA, do you see a fixed failure pattern? E.g, some memory region or some byte lane always has error? Or it is random?
• Several cases:
  • 1.2G CPU, 1200MT/s DDR, with external 250MHz clock, failure, is the same clock source input to sys clock and ddr3a? 
  • 1.2G CPU, 1000MT/s DDR, external ???? MHz clock, working
  • 1.2G CPU, 1200MT/s DDR, with external 100MHz clock, working,  is the same clock source input to sys clock and ddr3a? 

Regards, Eric

Hi Eric,

The picture was a snapshot of the C routine waiting for end of DMA once lanched

In response to your questions :

1) as explained in my original post, only DSP CORE_0 is running

2) XMC is initialized as per the GEL file :

3) external DDR3A is 4GB

4) when in the stuck waiting state, it is still possible to halt the process, execute step-by-step disassembly (actually pooling the IPR register), watch internal register, and so. But as soon as we try to open a DDR3 memory view window, CCS access to that core0 fails. Yes we loose JTAG access to the K2H. It is the same if we manually change the Bxx internal register so that to end the waiting loop and go back to the main() pgm (stll in step-by-step disassembly) : CCS loose access to CORE0 upon the first encountered CPU access to external DDR3.

But since we have modified (hardware) our board to input 100MHz instead of 250MHZ I can not reproduce the phenomenon and give you back the corresponding CCS red message. (at least it was not related to power failure detection,

4) as explained earlier , when in the stuck configuration it is no more possible to get any view of the DDR3 (by CCS itself, or by executing CPU access in step-by-step disassembly mode) content without "crashing" CCS

5) in every scenario, both external DDR3_CLK input and SYSCLK (actually ALT_CORE_CLOCK input is used)  input are from the same source through an CDCLVP1212 fanout buffer)

6)  your question about my secondary setup "????" was corresponding to an external input of 250MHz, targeting an output DDR clock of 500 MHz

Last information : K2H revision is 3.1

Regards,

Bruno

Hi,

A quick question on your run_dma() code, you used the channel 2, and I saw you ESR = 0x1 << 2; Question is why you pull the IPR bit 0 instead of bit 2 for  completion? In the OPT register there is a TCC field, do you use TCC = 0 instead of 2 in your channel setup? I want to confirm that you pull the right bit for EDMA completion. 

It looked that the EDMA transfer never finish. And when you access the DDR3A, the DSP core hang. Some questions:

• If you access EMIF config 0x2101_0000 region, hang or still accessible?
• What is the EDMA source and destination? You read DDR or write DDR or both? 
• Do you see any error in EDMA ERRSTAT and ERRDET registers?
• Use CPU for DDR3A test work or not?

Regards, Eric

Hi Eric,

- I confirm that we use DMA channel 2, PARAM SET 2, TCC=0, and Queue 0

- EDMA source is L2, destination is DDR3 for write access.

- EDMA source is DDR3, and destination is L2 for read access.

- we do both EDMA write, and EDMA reads

- attempting CPU access to DDR3A when in DMA stuck situation results in stopping any access to the device through JTAG.

- Unfortunately as I told you, I can not redo the same setup and therefore not able to tell you about ERRSTAT, and ERRDET.

I just can add that this week  we validated the DDR3 interface , running at 800 MHz during 24 hours, which give us some confidence into external hardware.

With best regards,

Bruno