• State Resolved
  • Replies 14 replies
  • Subscribers 31 subscribers
  • Views 305 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM62D-Q1: Regarding DMA on AM62D/A

O.H
Mastermind 7200 points

Part Number: AM62D-Q1
Other Parts Discussed in Thread: 66AK2G12

Hi experts,

We are currently verifying DMA transfers between L2 and DDR on a C7x application.

The application used for this verification is a bare-metal application based on FreeRTOS SDK version 12.00.00, specifically the dmautils_autoinc_1d2d3d and swasrc_multichannel_playback examples.

We have confirmed that the DRU works correctly when it is operated by itself. However, when McASP is running and we perform a DMA transfer using the DRU inside the McASP receive interrupt handler, the EFR can only be read as 0 even after executing __get_indexed(__EFR, 0). As a result, the application cannot trap the DRU transfer completion event registered in the CLEC.

We have the following questions:

  1. Although the TRM and C7X_SW include an overview of the DRU, is there any documentation that explains the DRU in more detail, including the differences from BCDMA/PKTDMA?

  2. Are there any known errata related to DRU operation, such as DRU execution not being guaranteed within an interrupt context?
    We checked both the device errata and the SDK errata, but could not find any applicable item.

  3. When using BCDMA for DMA transfers inside an interrupt routine, we could not achieve performance comparable to QDMA on the C66 core of the 66AK2G12. Therefore, we are considering using the DRU instead.
    Our understanding is that the DRU is a C7x-dedicated engine and is therefore capable of faster data transfers. Is this understanding correct, or is there any misunderstanding?

Best regards,
O.H

  • 0
    Mastermind 7200 points

    Hi experts,

    We also have the complete project set ready, which we will share with the assigned person via private chat.

    Best regards,
    O.H

  • 0 in reply to O.H
    TI__Genius 14200 points

    Hi O.H,

    O.H said:
    We also have the complete project set ready, which we will share with the assigned person via private chat.

    Appreciate this, but I think it might not be needed here. 

    O.H said:
    We have confirmed that the DRU works correctly when it is operated by itself. However, when McASP is running and we perform a DMA transfer using the DRU inside the McASP receive interrupt handler, the EFR can only be read as 0 even after executing __get_indexed(__EFR, 0). As a result, the application cannot trap the DRU transfer completion event registered in the CLEC.

    My best guess here is, that the CLEC event number that you are assigning to is also being utilised by MCASP/UDMA, so when the mcasp is running, it clears the interrupts before DRU can register it. Please try this: KERNEL_DPL_HWI_PAGE, and change the event number to something which is not being used by the application, for e.g. ECAP.

    Thanks,
    Shreyansh

  • 0 in reply to Shreyansh Anand
    Mastermind 7200 points

    Hello Shreyansh,

    Thank you for your reply. The following is feedback from the customer. We will ask the customer to confirm the CLEC event number just to be sure.

    =================
    After re-checking the behavior using the project file, the customer confirmed that the EFR register read operation, which had been reported as the issue, works correctly in that project.
    After comparing the differences between that project and the customer’s application project, they found that the timing of the first DRU execution was different.

    • Test project: inside the McASP receive callback
    • Customer application project: at the beginning of FxPlayback_main()

    When the functions executed with USE_DRU_DMA enabled are also placed at the beginning of FxPlayback_main(), the EFR read issue can be reproduced. However, while organizing the test project this time, the customer unintentionally introduced this difference. We apologize for the confusion.

    We have two additional questions.

    Q4:
    In addition to the request in Q1, could you please provide any documentation related to the DRU in general, if available?
    It appears that there may be some restrictions related to the timing until the first DRU TR is issued. Therefore, the customer would like to understand not only the differences between DRU and BCDMA/PKTDMA, but also the general behavior and usage guidelines of the DRU.

    Q5:
    In the project, only a specific function, dma_test_dru_index8_float(), does not perform the data transfer correctly.
    With BCDMA, the corresponding function, dma_test_bcdma_index8_float(), performs the data transfer as expected.

    Are there any restrictions for DRU, such as being able to transfer data only to or from contiguous memory regions?
    =================

    Please note that dma_test_dru_index8_float() and dma_test_bcdma_index8_float() are customer-created wrapper functions. Inside these functions, the APIs used by the SDK driver are called. We will send these functions via private chat.

    Best regards,
    O.H

  • 0 in reply to O.H
    TI__Genius 14200 points

    Hi O.H,
    Thanks for sending the project. I have typically seen issues with CLEC configuration resulting in DRU not working proprely. Let me study your example and try to run it to understand the issue.



    Thanks,
    Shreyansh

  • 0 in reply to Shreyansh Anand
    Mastermind 7200 points

    Hi Shreyansh,

    Sorry for rush you, Is threre any update? Any information you can provide about the situation would be greatly appreciated.

    Best regards,
    O.H

  • 0 in reply to O.H
    TI__Genius 14200 points

    Hi O.H,

    I was not able to run the project you had shared due to missing no rtps library. Could you share that as well? Meantime, I was reviewing the code, but haven't zeroed in on anything yet. I will update you by tomorrow based on my review.

    Thanks,

    Shreyansh

  • 0 in reply to Shreyansh Anand
    Mastermind 7200 points

    Hi Shreyansh,

    Thank you for your reply. I send full project via private chat. Please let me know if any information is missing.

    Best regards,
    O.H

  • 0 in reply to O.H
    TI__Genius 14200 points

    Hi O.H,


    While I am still trying to debug the application,I realised I have not answered all of your questions.

    O.H said:
    Although the TRM and C7X_SW include an overview of the DRU, is there any documentation that explains the DRU in more detail, including the differences from BCDMA/PKTDMA?

    Unfortunately, apart from TRM and the software, there aren't any other documentation available at the moment for DRU. I will check internally though if there exists anything else.

    O.H said:
    Are there any known errata related to DRU operation, such as DRU execution not being guaranteed within an interrupt context?
    We checked both the device errata and the SDK errata, but could not find any applicable item.

    There is no known errata related to DRU that I am aware of.

    O.H said:
    When using BCDMA for DMA transfers inside an interrupt routine, we could not achieve performance comparable to QDMA on the C66 core of the 66AK2G12. Therefore, we are considering using the DRU instead.
    Our understanding is that the DRU is a C7x-dedicated engine and is therefore capable of faster data transfers. Is this understanding correct, or is there any misunderstanding?

    Your understanding is correct regarding DRU being a C7x dedicated engine for faster data transfer. However, doing a transfer inside ISR is generally not recommended, considering DRU/DMA transfers are a blocking call, and such there is no benchmark available.

    O.H said:

    In the project, only a specific function, dma_test_dru_index8_float(), does not perform the data transfer correctly.
    With BCDMA, the corresponding function, dma_test_bcdma_index8_float(), performs the data transfer as expected.

    Are there any restrictions for DRU, such as being able to transfer data only to or from contiguous memory regions?

    Not really, the TRs can be configured for non contiguous memory regions as well. I am still reviewing the application. Please correct me if I am wrong, but this is the only existing issue here, right?

    Thanks,
    Shreyansh

  • 0 in reply to Shreyansh Anand
    Mastermind 7200 points

    Hi Shreyansh,

    Sorry for late reply, and thank you for your supports.

    Shreyansh Anand said:
    Unfortunately, apart from TRM and the software, there aren't any other documentation available at the moment for DRU. I will check internally though if there exists anything else.

    We await further information.

    Shreyansh Anand said:
    There is no known errata related to DRU that I am aware of.
    Shreyansh Anand said:
    Your understanding is correct regarding DRU being a C7x dedicated engine for faster data transfer. However, doing a transfer inside ISR is generally not recommended, considering DRU/DMA transfers are a blocking call, and such there is no benchmark available.

    I understood.

    Shreyansh Anand said:
    Not really, the TRs can be configured for non contiguous memory regions as well. I am still reviewing the application. Please correct me if I am wrong, but this is the only existing issue here, right?

    Yes, This is the only issue at the moment. I will share any additional information we find.

    Best regards,
    O.H

  • 0 in reply to O.H
    Mastermind 7200 points

    Hi Shreyansh,

    Sorry for rush you, Is threre any update? Any information you can provide about the situation would be greatly appreciated.

    Best regards,
    O.H

  • 0 in reply to O.H
    TI__Genius 14200 points

    Hi O.H,
    Unfortunately no. I am still ramping up on DRU, so it is taking a bit more time. I will update you in couple of days, once I understand the issue.

    Thanks,
    Shreyansh

  • +1 in reply to Shreyansh Anand
    Mastermind 7200 points

    Hi Shreyansh,

    Sorry for the delayed response.
    The customer has provided the following additional information and stated that, although the reason is unclear, the issue has been resolved.
    It would be helpful if you could share any insights regarding the underlying cause addressed by the solution, or any concerns you might have about the solution itself.
    ===================================

    Shreyansh Anand said:
    Your understanding is correct regarding DRU being a C7x dedicated engine for faster data transfer. However, doing a transfer inside ISR is generally not recommended, considering DRU/DMA transfers are a blocking call, and such there is no benchmark available.

    As you mentioned, the DRU-related code in the SDK uses blocking calls. However, in our application, we plan to modify the SDK by splitting the TR issuance and event completion wait processes into separate operations, allowing application processing and DRU transfers to run in parallel while executing within the interrupt routine.

    O.H said:
    Q5:
    In the project, only a specific function, , does not perform the data transfer correctly.
    With BCDMA, the corresponding function, , performs the data transfer as expected.    dma_test_dru_index8_float()dma_test_bcdma_index8_float()

    Regarding DRU transfers to non-contiguous memory regions, the issue appears to be resolved when making the following change. In both the original and modified implementations, the condition described in TRM Section 11.1.3.3.5.16, namely:

    "The value of DICNT0 x DICNT1 x DICNT2 x DICNT3 must equal ICNT0 x ICNT1 x ICNT2 x ICNT3."

    was not violated. However, we have not been able to determine why this change results in different behavior.

    Modification made: File: dma_dru_wrap_SetupXferProp_index8() (test_dma_dru_wrapper.c), Changed the values of "pTransferDimIn->sicntXX" to be identical to "pTransferDimIn->dicntXX" (where XX = 0–3).

    ===================================
    Best regards,
    O.H

  • 0 in reply to O.H
    TI__Genius 14200 points

    Hi O.H,

    Sorry, I got pulled into another high priority escalation and was not able to spend time on this issue. Glad to know that issue has been resolved. 

    O.H said:
    As you mentioned, the DRU-related code in the SDK uses blocking calls. However, in our application, we plan to modify the SDK by splitting the TR issuance and event completion wait processes into separate operations, allowing application processing and DRU transfers to run in parallel while executing within the interrupt routine.

    Where do you call the event completion wait function? Does it still happen inside the ISR?

    O.H said:
    Modification made: File: dma_dru_wrap_SetupXferProp_index8() (test_dma_dru_wrapper.c), Changed the values of "pTransferDimIn->sicntXX" to be identical to "pTransferDimIn->dicntXX" (where XX = 0–3).

    Regarding this, there is no restriction for non contiguous transfer as long as the calculations for the dimensions doesnt violate the actual memory access operations. For example, with incorrect dimension, you could be jumping to an unexpected memory location.

    Thanks,
    Shreyansh

  • 0 in reply to Shreyansh Anand
    Mastermind 7200 points

    Hi Shreyansh,

    Based on your feedback, it should have been moved out of the ISR. I will convey the concerns you raised to the client, and if the issue recurs, I will create a new thread.

    Thnak you for your kind suppports!!

    Best regards,
    O.H