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.

RTOS/AM4378: EDMA usage in HSR-PRP-DAN

Part Number: AM4378

Tool/software: TI-RTOS

Hi,

I use:
pdk_am437x_1_0_6
edma3_lld_2_12_03_27
PRU-ICSS-HSR-PRP-DAN_01.00.02.00

Here are some questions:

1.) PRP-ICSS-HSR-PRP-DAN use edma. It also create edma handler. To use edma I need handler. I found function EDMA3_DRV_getInstHandle() but i don't know what phyCtrllerInstId (EDMA3 Controller Instance Id (Hardware instance id, starting from 0) and regionId ( Shadow Region id for which the previously opened driver's instance handle is required) are?!

2.) I would like to use edma with my custom tasks at the same time as PRP application but here is trick:
I want to setup edma channel with ARM to copy data from PRU RAM to DDR, but PRU must trigger transfer when data will be ready on his side.
I'm concern how this should work because for accessing EDMA, LLD pending semaphore is needed and i don't know how to realize this with PRU.
Any idea how to approach?

Best Regards, Mare

  • The RTOS team have been notified. They will respond here.
  • If I undertand correcty driver, for triggering semaphore is not used? or is?
    Overall... is this approach forbidden (using edma with ARM and PRU)?
  • Hi Mare,

    1) Instead of using the lower level EDMA3_DRV_getInstHandle( ), you can get a EDMA handler from edma3init( ) which calls EDMA3_DRV_open( ) underneath. You can look into the PRSDK UART example as a EDMA3 use case / reference. More details about EDMA3 drier is here - processors.wiki.ti.com/.../Programming_the_EDMA3_using_the_Low-Level_Driver_(LLD)

    2) Can you please elaborate your custom tasks? The packets received by PRU are queued in OCMC and the callback function RedRxPktGet( ) copies the packets from OCMC memory to DDR. Do you plan to update the memory 'copy' with EDMA?

    Regards,
    Garrett
  • Hi Garrett!

    I'm glad that you answer on my topic.


    1.) If I call edma3init() I get "EDMA3_DRV_E_OBJ_NOT_DELETED". I think this is because TimeSync_edmaConfig() init EDMA before my task . So how to get pointer on opened EDMA handler?

    2.) For better understanding of issue let me explain how system should look like.

    ARM code:
    - PRP driver
    - TimeSync
    - TCP
    - ...
    - :::
    - My custom tasks for HW(communication with PRU-ICSS0)
    - My custom tasks for calculating data from PRU-ICSS0 and sending it over TCP/UDP...

    PRU-ICSS1:
    -TI bin. code for PRP  (Use L3 and PRU RAM)

    PRU-ICSS0:
    - My custom code: Get samples from external sensors and send data to ARM.


    I think you miss understood. I didn't plan to modify PRP driver or PRU-ICSS1 code...

    For now I made "my HW tasks" and PRU-ICSS0 code. In general it work, but is too slow.
    Now PRU (ICSS0) copy data on L3 and ARM copy form L3 to DDR... but too many data and ARM is too slow with copying. If I wand PRU to copy data directly to DDR, latency is to big and PRU miss events for real time operations. So idea is to use EDMA to copy data rom PRU RAM to DDR.

    Goal is: ARM setup EDMA (src,dst,len), PRU trigger transfer chunks of data when data are ready in src. array (from sensors).. When X number of samples is captured PRU trigger ARM to use data in DDR.

    So Garrett.... Here is my question:
    As you can see from picture, PRU need access to EDMA, My tasks need access to EDMA and also TimeSync tasks use EDMA (part od PRP code packet).
    What is most elegant approach for "multi" processor EDMA use? How I can "pend" semaphore with PRU? Do I need check semaphore with PRU if I want just start partial transfers on chanell (setup is made buy ARM)?


    Regards, Mare

  • Hi Mare,

    1) edma3init() is called in TimeSync_edmaConfig(), thus the EDMA handler is the same timeSyncHandle->edmaConfig->gEdmaHandle even though you try to setup a second EDMA channel for data copy. "edma3init should be called once and the handler should be used by both the threads to request the channels with their own callback functions." see the thread - e2e.ti.com/.../126883.

    2) OK, now I understand your use case. I think you should be able to achieve this by manually trigger the EDMA transfer from PRU by writing to the event set register, see TRM 10.3.4.1.2 Manually Triggered Transfer Request, and EDMA3_DRV_TrigMode in EDMA3_DRV_enableTransfer() API.

    Regards,
    Garrett