• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 98 subscribers
  • Views 1595 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DMA Address Translation for TI8168 DSP for L1/L2 RAM

RV
Expert 2030 points

I am using DMAN3 for DMA operations. Per this post from EDMA driver team, address translation should be done by application (DMAN3) if host processor memory map differs from EDMA controller map, which is the case in Netra. See here for more details.

How should I do this address translation, so that ACPY3 works properly with c674x DSP internal L1/L2 RAM memory?

Which settings change will help this address translation?

Passing in manually adjusted pointers to ACPY3 does not work.

 

Thanks

 

RV

  • 0
    TI__Expert 7415 points

    RV, I'm trying to find out more, but just to clarify:-

    ACPY3 on it own simply uses the addresses that are passed to it. You configure DMAN3 with some heap addresses, that are then used to allocate internal memory for use by DMAN3 and ACPY3. You configure DSKT2 with some heaps, that are then used to allocate memory buffers (internal and/or external) for the algorithms. ACPY3 uses the DMA base address (also configured for DMAN3) to perform DMA transfers to/from the buffer addresses provided. 

    We are trying to figure out where/which component should do this translation, and also why we haven't yet faced this issue. 

  • 0 in reply to Gunjan
    Expert 2030 points

    Thanks for looking into this.

    My use case is ARM+DSP and I am using :

    • codec-engine_3_21_00_13_eng
    • framework-components_3_21_00_17_eng 

    included in this EzSDK release.

    Just to clarify, DMA transfers involving [both src,dst are in DDR3 ] addresses in DDR3 works without hitch.

    Any DMA that goes to INT_HEAP (L2)  is basically a phantom transfer. No crashes but also no transfers. Something is off with DSP/EDMA Shared System MMU (DEMMU) configuration when it comes to DMA tranfers to/from L2/L1 RAM

    Using memcpy for DDR3 to IRAM transfer works flawlessly

    RV

     

     

  • 0 in reply to RV
    Expert 2030 points

    More specifically C674x sees memory thus:

    Where as EDMA controller(also other bus master's) L3 memory map is:


    Question is who does the address translation involving DSP L1/L2 RAM addresses as EDMA LLD does not do this automatically?


    RV

  • 0 in reply to RV
    Expert 2030 points

    Any updates?

    Can anyone from TI confirm if they are seeing same issues with c674x DMA transfers not working when it is from/to DSP IRAM to/from DDR3 for Netra and Centaurus?

    This is with:

    • codec-engine_3_21_00_13_eng
    • framework-components_3_21_00_17_eng

    in EZSDK 5_01_01_80.

    When will this be fixed?

    RV

  • 0 in reply to RV
    TI__Expert 7415 points

    RV,

    We have confirmed the issue with addresses that are in internal memory, and are actively working to figure out the solution. I have gotten simple DMA (not using Framework Components) to work by simply offsetting internal buffer addresses by 0x3000 0000 when programming the DMA. However with FC, I am working to  figure out how to solve this issue. 

    Will update this thread as soon as we have figured this one out.

    Thanks,

    Gunjan.

  • 0 in reply to Gunjan
    TI__Expert 7415 points

    RV,

    Any chance you can migrate from DMAN3 to RMAN/ECPY for your DMA needs ? My experiments with ECPY based DMA transfers to/from internal memory were successful, once the src/dst internal memory addresses were offset by 0x3000 0000. The DMA transfer was successful.

    I am still investigating the issue on ACPY3, but was wondering if you'd like to migrate to ECPY for now. I can point you to examples that demonstrate DMA using these new libraries.

    Thanks,

    Gunjan.

     

  • 0 in reply to Gunjan
    TI__Expert 7415 points

    RV,

    We have identified the real issue and have a workaround for it that can be used when running an app that uses DMAN3/ACPY3. Here are the steps involved:-

    - Add the following line to your DMAN3 configuration:-    

    DMAN3.queuePri = [2,2]; //This changes the default queue priorities for DMA from 3,7 which seem to be causing the issue.

    - At the place in your code where your program ACPY3, if your src/dst buffers are in internal memory (address of the form 0x108? ????/0x10F?  ???? or 0x008? ????/0x00F? ????), add appropriate offset to change them to the form 0x40F? ???? or 0x408? ???? before you call ACPY3_configure calls.

    - Rebuild your application.

    -Reset your board and re-run it  

    Let me know what your results are.

    Thanks,

    Gunjan.

  • 0 in reply to Gunjan
    Expert 2030 points

    I'll let you know next week.

    Thanks again.

    RV

  • 0 in reply to RV
    Expert 2030 points

    Followed your suggestions. DMA to/from IRAM is working with ACPY3. 

    I still have to manually offset the IRAM addresses by 0x3000 0000.

    Hopefully that will be fixed in upcoming releases.

     

    Thanks Gunjan !!

     

    RV

     

     

  • 0 in reply to RV
    TI__Expert 7415 points

    In the FC 3.21 official release, the MEMUTILS_getPhysAddress api can be used from inside your application or codec to get the "right" address for internal memory buffers, that can be used to program the DMA.

    This API is portable, so the same API should work on multiple devices that may  have a different conversion mechanism. 

    The examples have been updated to now call this API and then using the returned address to program the DMA. Do take a look at it when it comes out.

     

    Thanks,

    Gunjan.