TI E2E Community
Digital Signal Processors (DSP)
OMAP-L13x, AM1x and C674x Processors Forum
Data transfer through EMIF with EDMA for OMAP L138
I would like to transfer buffer data out to the EMIF by EDMA for the OMAP L138, and the transmission is controlled by ARM side under Linux OS. In order to simplify the testing, buffer size is set to 24bytes, AB-synchronization is used. The PaRAM settings are as follow:
acnt = 2
bcnt = 4
ccnt = 3
src bidx = 2
src cidx = 8
dst bidx = 2
dst cidx = 8
PaRam data is as follow:
src addr: c1e41000
dst addr: 60000000
When the destination address is set to internal memory, the above task is simply the memory copy and everything is working fine. But when the destination address is set to the EMIF address (0x60000000), I found the following issues (with the help of the Logic Analyzer):
1) There are only 4 write cycles (bcnt) on the EMIF bus, and the count for 3rn dimension (ccnt) has same effect as 1 no matter how I change it. (The CS2 lasts for 4 write cycles only).
2) The EMIF address bus is incremented but per every 2 write cycles.
For above 1st issue: I found that there were 3 times manually triggers but only the first trigger had the effect on the EMIF bus, while the other 2 triggers received the transmission completion interrupt, but nothing on the EMIF bus.
For the 2nd issue, the bus can be incremented per write cycle when the destination B index is 4, but the transmission is not optimized then.
Is there something wrong in the above settings?
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.
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?
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"
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
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 ?
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 should be connected to the A 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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.