Forums

Did you verify if the write is happening into DDR as expected ? If you are checking from ARM you will need to invalidate the cache in the destination region to check if EDMA has written correctly.

Hello,

Thank you for the respond.

I haven’t checked the DDR but I have checked the EMIF data bus and the data are as expected.

The initialized 24 bytes EDMA buffer data are:

0x0, 0x1, 0x2 …… 0x16, 0x17.

The EMIF data bus output are:

0x0100, 0x0302, 0x0504, 0x0706

When I set the bcnt = 12 and ccnt =1, I can see all the 24 bytes data on EMIF data bus as expected. Hence, I believe the DDR should be correct.

More finding: if the EDMA changed to the A-Synchronization mode, event missing will occur and only one write cycle can be seen on the EMIF bus.

My analysis is that:

- Since the memory copy is correct (when the destination address is set to the internal memory address), the EDMA PaRAM should be correct and functioning

- When the destination address is set to EMIF, CS2 can be detected and data are expected except that the data transmission is stopped in the half way. EDMA on the EMIF start to function also.

I lose the direction and really don’t know where the possible error in the above EDMA settings is?

Best Regards

xutong

Xu,

Its very important to make sure that you are not making a wrong observation with the Logic Analyzer. So its best that you first verify the DDR to see if the data has been written correctly, before you debug any further.

>> if the EDMA changed to the A-Synchronization mode, event missing will occur and only one write cycle can be seen on the EMIF bus.

Can you please clarify what you mean by " event missing will occur and only one write cycle can be seen on the EMIF bus"

Hello,

Thanks for the guide.

- DDR verification

My understanding is that, the PaRAM and EDMA buffer data are located inside the SDRAM and they are the all to be verified. Please correct me if there is anything wrong and my checking steps as follow:

Kernel edma_read_slot() is used to read back the PaRAM data, and it has been done in my first post to show the PaRAM setting data.

Kernel dam_alloc_coherent() is used to reserve the continues memory as the buffer inside the SDRAM. This buffer value is set to 0x0, 0x01, 0x02, …… 0x17 as stated in my previous post, and it is read back before and after the dma transmission. The buffer values are correct and constant.

Are there any more things need to be checked or my checking method is wrong?

-         For A-Synchronization event missing issue

PaRAM opt is set to 0x80300000 while remain the rest PaRAM data.

Kernel edma_alloc_channel() is used to set up the dma ISR, and the ch_status = -1 indicate that the dma EMR register for the used dma channel is set. But there is no this issue for the AB-Synchronization.

-         Test observation

You are right that it is very important to have the correct test observation with the test instrument, and we have to make sure the output performance can meet the required observation or requirement verified by the test equipment.

Could you please let me know whether you have find or suspect any wrong test observation from above test description?

My Logic Analyzer setting is as follow:

CS2 falling edge is set to the triggering signal and monitoring signals are WR, Data bus and address.

This should be the very simple test setup as only my test application uses the EMIFA bus CS2, and I really got the expected data output when the EDMA PaRAM ccnt  = 1, and I used this setup to verify the EMIF timing setup before.

In order to prove my test observation, I created one 16bits buffer and used the while loop to output the buffer data to the EMIF data bus with address increment but without using the DMA, I got the expected data output on the data bus also, but more importantly, I got the exactly same EMIF address bus issue as using the EDMA, that is “The EMIF address bus is incremented but per every 2 write cycles”.

For more debugging, I found that, for data output to EMIF virtual address 0xc3000000 and 0xc3000002, there is no changing on the EMIF address bus! The EMIF address bus will increment for 1 for the 0xc3000003 and 0xc3000004, which causes the above EMIF address issue.

I changed my focus on the EMIF from EDMA and checking the EMIF setting now. Honest speaking, from the moment I got the same EMIF address issue by using 2 different mechanisms, I stated to doubt the EMIF hardware core. Could the TI hardware experts help to check this issue also?

Thanks and Best Regards

xutong

XU,

The PARAM settings are not written into DDR(but into some other memory which you can consider as EDMA registers).

Have you verified the output buffer location after the DMA was triggered and completed. Does it contain correct output values ?

Hello,

Thanks for the reply.

I did check the output buffer before and after the DMA transfer via EMIF. As stated in my last post, its contains are correct and constant. As the normal user for the EDMA, I can follow the datasheet to configure and check the PaRAM and output buffer only.

For the EMIF address issue, I have found the solution when I did the EMIF bus testing. My test observation is correct but I have the wrong understanding before. As for the correct hardware design for the EMIF bus, EM_A[0] should be connected to the A[1] of the 16bits Asyn memory, and it should be changed per 2 write cycles.

The issue is focusing back on the EMIF bus EDMA 3D transmission now: the EDMA 2D transmission is ok but fails on 3D. According the datasheet, the maximum value for the bcnt <=65535, but my application may need to output more values and the 3D transmission has to be used. I am not sure whether this requirement is too greedy, but this is the user requirement unless I can found the valid reason to change it.

Best Regards