• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1633 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.

Processor SDK RTOS for AM355x: Status of DMA-enabled drivers

BrianBrianBrian
Expert 1085 points

(Processor SDK RTOS for AM355x v2)

Looking in pdk_am335x_1_0_0\packages\ti\drv I see:

  • McASP: nothing exists at all
  • MMCSD: there is an interrupt-based driver and an incomplete DMA-based driver (the MMCSDDMA_soc.c implementation is missing for am335x).
  • UART: there is an interrupt-based driver and an incomplete DMA-based driver (the UART_soc_dma.c implementation is missing for am335x).
  • SPI: there is only an interrupt-based driver.

Are we going to get DMA-enabled drivers for MMCSD, UART, McSPI and McASP on the am335x?  If so, when?

  • 0
    TI__Guru**** 393215 points
    Hi,

    I will ask the RTOS team to comment.
  • 0 in reply to Biser Gatchev-XID
    TI__Genius 9065 points

    Hello Brian,

    Yes, we have plans to add DMA support for MMCSD, UART, McSPI and McASP on AM335x in the coming months.

     

    Meanwhile, for MMCSD and UART, DMA support is demonstrated for AM57x PDK which could be used as reference if you need it now.

     

    Processor SDK RTOS for AM57x is available here:

    http://www.ti.com/tool/processor-sdk-am57x

     

    PDK example can be found here:

    C:\ti\pdk_am57xx_1_0_0\packages\ti\drv\uart

    C:\ti\pdk_am57xx_1_0_0\packages\ti\drv\mmcsd

    best regards,

    David Zhou

  • 0 in reply to dzhou
    Expert 1085 points
    Thank you, David. I'm going through the example now. However, it's not clear what EDMA3 platform the MMCSD_FatfsConsole_idkAM571x_DMA_armExampleProject is linking against in this line from mmcsddma_idk.cfg:

    var Edma = xdc.loadPackage ("ti.sdo.edma3.drv.sample");

    I know to look in edma3_lld_02_12_01_22/packages/ti/sdo/edma3/drv/sample/package.xs to see the mapping between the device name and the platform directory used to link against but I don't see any AM57xx devices listed.
  • 0 in reply to BrianBrianBrian
    Expert 1085 points

    Also, is there a reason why the configuration of the EDMA3 driver in the AM35xx EDMA3 bio6 porting sample:

              {
            /* Resources owned by Region 0 */
            /* ownPaRAMSets */
            /* 31     0     63    32     95    64     127   96 */
            {0x00000000u, 0x00000000u, 0xFFFFFFFFu, 0xFFFFFFFFu,
            /* 159  128     191  160     223  192     255  224 */
             0xFFFFFFFFu, 0xFFFFFFFFu, 0xFFFFFFFFu, 0xFFFFFFFFu,
            /* 287  256     319  288     351  320     383  352 */
             0x00000000u, 0x00000000u, 0x00000000u, 0x00000000u,
            /* 415  384     447  416     479  448     511  480 */
             0x00000000u, 0x00000000u, 0x00000000u, 0x00000000u,},

            /* ownDmaChannels */
            /* 31     0     63    32 */
            {0x00303000u, 0x00C0003Fu},

            /* ownQdmaChannels */
            /* 31     0 */
            {0x000000FFu},

            /* ownTccs */
            /* 31     0     63    32 */
            {0x00303000u, 0x00C0003Fu},

            /* Resources reserved by Region 0 */
            /* resvdPaRAMSets */
            /* 31     0     63    32     95    64     127   96 */
            {0xFFFFFFFFu, 0xFFFFFFFFu, 0x00000000u, 0x00000000u,
            /* 159  128     191  160     223  192     255  224 */
             0x00000000u, 0x00000000u, 0x00000000u, 0x00000000u,
            /* 287  256     319  288     351  320     383  352 */
             0x00000000u, 0x00000000u, 0x00000000u, 0x00000000u,
            /* 415  384     447  416     479  448     511  480 */
             0x00000000u, 0x00000000u, 0x00000000u, 0x00000000u,},

            /* resvdDmaChannels */
            /* 31                                         0  63                                                  32 */
            {DMA_CHANNEL_TO_EVENT_MAPPING_0, DMA_CHANNEL_TO_EVENT_MAPPING_1},

            /* resvdQdmaChannels */
            /* 31     0 */
            {0x00000000u},

            /* resvdTccs */
            /* 31                                         0  63                                                  32 */
            {DMA_CHANNEL_TO_EVENT_MAPPING_0, DMA_CHANNEL_TO_EVENT_MAPPING_1},
          },

    (refer to c:/ti/edma3_lld_02_12_01_22/packages/ti/sdo/edma3/drv/sample/src/platforms/sample_am335x_cfg.c)

    has all the peripheral mapped DMA channels as NOT owned by the driver?  Stepping through the EDMA3 RM allocResource() code, clearly implies that if you want to allocate a channel it must be at least owned by the driver.

    (this file is from the Processor SDK RTOS for AM35xx)

  • 0 in reply to BrianBrianBrian
    TI__Mastermind 30365 points
    BrianBrianBrian,

    We are looking at your specific questions and will get back to you.

    Lali
  • 0 in reply to BrianBrianBrian
    TI__Mastermind 30365 points
    Brian,

    Regarding your question on the platform names specified in package.xs, "Vayu" is the AM57x platform.

    Lali
  • 0 in reply to BrianBrianBrian
    TI__Mastermind 30365 points

    Brian,

    Please take a look at this wiki http://processors.wiki.ti.com/index.php/AM335x_EDMA_Driver's_Guide especially "How to reserve different EDMA3 resources"

    The sample code provides guidance on reserving resources that are already assigned to other masters, hence the reason why some of the channels aren't owned by the driver.

    Lali

  • 0 in reply to dzhou
    Expert 1085 points

    David and Lali,

    I'm going through the MMCSDDMA_v1.c driver source in pdk_am57xx_1_0_0. It seems to me that although there is some code in the MMCSDDMA_v1_transfer function that sets up a PaRAM set, this code never gets executed because DMA is hard-coded to be disabled on line 1689:

    cmdObj.enableDma = 0;

    Also, the interrupt handler MMCSDDMA_v1_hwiFxn just seems to be the same as the non-DMA version and still uses the CPU to copy data from the controller to RAM. Is this actually a complete working example of using DMA with MMCSD?

  • 0 in reply to BrianBrianBrian
    TI__Mastermind 30365 points
    BrianBrianBrian,

    We are working on getting MMCSD support into a future release, so what you have encountered would not be a complete MMCSD example.

    Lali
  • 0 in reply to Lalindra Jayatilleke
    Expert 1085 points

    So what's going on here?  Your colleague, Mr. Zhou, told me (just a few posts up from here) to look here for a complete DMA example for tha AM57xx and use that as a reference to implementing the AM335x driver:

    Hello Brian,
Yes, we have plans to add DMA support for MMCSD, UART, McSPI and McASP on AM335x in the coming months.
 
Meanwhile, for MMCSD and UART, DMA support is demonstrated for AM57x PDK which could be used as reference if you need it now.
 
Processor SDK RTOS for AM57x is available here:
www.ti.com/.../processor-sdk-am57x
 
PDK example can be found here:
C:\ti\pdk_am57xx_1_0_0\packages\ti\drv\uart
C:\ti\pdk_am57xx_1_0_0\packages\ti\drv\mmcsd
best regards,
David Zhou

    I've been wasting a lot of time following suggestions based on these responses and debugging all of this incomplete code in the SDK.  Texas Instruments please put your heart into it and don't just shrug us off with the first answer that will demotivate your users just enough to stop bothering you with questions.  Please don't forget that some of us are putting our heart and soul into your products.

  • 0 in reply to BrianBrianBrian
    TI__Mastermind 30365 points

    BrianBrianBrian,

    My apologies for the mixed responses here. I think the variations of questions between AM335x and AM57x has been a bit confusing, since some functionality is supported on AM57x and some planned for AM335x.

    My last response above "We are working on getting MMCSD support into a future release, so what you have encountered would not be a complete MMCSD example." was for AM335x and you were clearly asking if the am57x was a complete working example. My mistake. In order to dig into your specific concerns, I tried the example provided in the AM57x PDK. Here's the feedback I can provide:

    - I executed the .bat file located at C:\ti\pdk_am57xx_1_0_0\packages and generate the "myExampleProjects" folder. This script generated a project that is MMCSD with DMA and located at C:\ti\pdk_am57xx_1_0_0\packages\MyExampleProjects\MMCSD_evmAM572x_DMA_armTestProject.

    - I tried out this project and it is an example that does a quick read and write to the SD card on the AM57x GPEVM and put the result on the console as seen in the screenshot below.

    - When the above example is run, MMCSDDMA_v1_write() and MMCSDDMA_v1_hwiFxn() get called inside MMCSDDMA_v1.c. I was able to step through the code and end up at these locations.

    - Now the problem is that there is a line cmdObj.enableDma = 0 in MMCSDDMA_v1.c; which seems to indicate that DMA is disabled for this example. When going through the code, it seems that indeed DMA is not being used. So you are correct on that the example doesn't seem to use DMA.

    - I will be reporting this to the development team for review/correction.

    We appreciate your patience and the time you have taken to entertain TI products.

    Lali

  • 0 in reply to Lalindra Jayatilleke
    Expert 1085 points
    Thank you , Lali.

    And just to be complete, it is not just a matter of changing cmdObj.enableDma=1 in order to have the example use DMA. The code that sets up the PaRAM set is completely wrong (incorrect values) and the interrupt handler (hwiFxn) is not DMA-aware. The example has clearly been released in a half-finished state.
  • 0 in reply to BrianBrianBrian
    TI__Mastermind 30365 points

    Noted, and thanks again for the feedback.

    Lali