• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 148 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.

AM2434: DMA between R5F and PRU

Marshall Folkman
Prodigy 30 points
Part Number: AM2434

Tool/software:

I am trying to perform a block copy DMA benchmark test on the AM2434 using the udma_sw_trigger example project. The example performs a transfer to and from the R5 internal memory to it's shared memory. However, I need to benchmark the performance of a transfer between the PRU shared memory to the R5 internal memory. I believe the shared memory region of the PRU starts at 0x30010000.

Question 1: Do I need to enable the PRU to run in order to access this memory or can I simply define a new memory region and append it to the linker script?

Question 2: What is the easiest way to make this change to the udma_sw_trigger example project?

Question 3: If a PRU core needs to be setup (per question 1), then what is the easiest way to do this? Do I set it up in the example.syscfg file?

Any other tips on this would be appreciated.

Thank you!

  • 0
    TI__Expert 7385 points

    Hi Marshall,

    Yes, AM243x has 2 identical PRU ICSSG slices (ICSSG0 and ICSSG1). ICSSG0 shared RAM memory (64KB) starts at 0x30010000, you can know more about the different PRU memories from the "PRU_ICSSG Global Memory Map" section in the TRM.

    R5F can directly access the PRU shared memory. Can you try direct read/write to the PRU shared RAM from R5F and let me know if you face any issues.

    Regards,

    Nitika

  • 0 in reply to Nitika Verma
    Prodigy 30 points

    Nitika,

    I agree that the R5F has no problem accessing memory from the PRU's RAM (0x3001.0000 - Data 64 KB RAM2 (shared), page 3289 of TRM) and I have proven this to myself. The issue is getting DMA to do it from the R5. Specifically, BCDMA. The use case here is that we have a PRU generating and writing data here, but we need the R5 to move this data, which it can do but it can't keep up with the PRU when done directly. So I'm doing this DMA benchmark test to show what kind of a performance improvement we can make using DMA.

    At first I thought my issues had something to do with the linker script or data alignment, but diving in deeper I'm pretty sure it has something to do with permissions. Specifically, the DMA (when triggered from the R5) can't access the PRU's RAM.

    Any idea on how to fix this?

    ** More details on what I'm seeing in my test **
    Again, I'm leveraging the AM2434 udma_sw_trigger example project. I updated the source buffer gUdmaTestSrcBuf with a pointer to the PRU's Data RAM2 (0x3001.0000). In debug mode I get within the App_udmaTriggerInit function to the first call of Udma_eventRegister.


    retVal = Udma_eventRegister(drvHandle, gCh0TrEventHandle, &gCh0TrEventPrms);
    DebugP_assert(UDMA_SOK == retVal);

    Which returns -1 into retVal. Drilling down this rabbit hole, I see that the issue happens here:

    App_udmaTriggerInit -> Udma_eventRegister -> Udma_eventConfig (line 172 of udma_event.c) -> Sciclient_rmIrqSet (line 1052 of udma_event.c)

  • 0 in reply to Marshall Folkman
    TI__Expert 7385 points

    Hi Marshall,

    Thank you for the information. 

    I am forwarding your thread to our DMA expert for more comments on this, allow them some time to get back to you.

    Regards,

    Nitika

  • +1 in reply to Nitika Verma
    TI__Mastermind 46916 points

    Hello Marshall,

    If the permission problems, then the R5F core may enter into exceptio or not move data from the source buffer to the destination PRU buffer.

    Can you please share the example code to look at your changes ?

    Regards,

    Anil.