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.

TDA4VE-Q1: Lost DMA Transpose capabilites when moving from TDA4VM to TDA4VE

Part Number: TDA4VE-Q1
Other Parts Discussed in Thread: TDA4VM, TDA4VL

Hi, 

We were developing until now with TDA4VM and are now moving to TDA4VE. We're still using the RTOS SDK. Specifically, for DMA, we're using vision_apps/utils/udma/app_udma_utils.h. 

We've added two functions to appUdmaUtils to be able to trigger a Transpose transaction. It works perfectly on TDA4VM, but the same code doesn't work on TDA4VE. To be noted that all other DMA functionality works as before. 

Are there some difference of usage between TDA4VM and TDA4VE that might not be reflected in appUdmaUtils? 

 

The code we added are these three functions:

  • appUdmaTrpdSetTransposeND(): Copy-paste of appUdmaTrpdSetND(), but we also set 
    pTr->fmtflags |= CSL_FMK(UDMAP_TR_FMTFLAGS_DFMT, CSL_UDMAP_TR_FMTFLAGS_DFMT_TRANSPOSE);
  • appUdmaTransposeNDInit(): Copy-paste of appUdmaCopyNDInit(), but we call appUdmaTrpdSetTransposeND() instead of appUdmaTrpdSetND()
  • appUdmaCopyNDIsFinished(): To be able to do some polling on the channel instead of blocking on it.

#if defined(__C7100__) || defined(__C7120__) || defined(__C7504__)

int32_t appUdmaCopyNDIsFinished(
    app_udma_ch_handle_t ch_handle)
{
    int32_t     retVal = UDMA_SOK;

    if ((uint32_t)TRUE == ((app_udma_ch_obj_t *)ch_handle)->create_prms.use_dru)
    {
        uint64_t wait_word = ((app_udma_ch_obj_t *)ch_handle)->wait_word;
            
        if ((__get_indexed(__EFR,0) & wait_word ) == wait_word )
        {
            __set_indexed(__EFCLR,0, wait_word);
        }
        else
        {
            retVal = UDMA_EFAIL;
        }
    }
    else
    {
        Udma_EventPrms *eventPrms = &((app_udma_ch_obj_t *)ch_handle)->tr_event_obj.eventPrms;

        if(CSL_REG64_RD(eventPrms->intrStatusReg) & eventPrms->intrMask)
        {
            /* Clear interrupt */
            CSL_REG64_WR(eventPrms->intrClearReg, eventPrms->intrMask);
            /* Work-around for K3_OPEN_SI-213 */
            /* We need to ensure that status clear is written to IA
                before re-submitting on the same channel */
#if defined (_TMS320C6X)
            _mfence();
            _mfence();
#endif
        }
        else
        {
            retVal = UDMA_EFAIL;
        }
    }

    return (retVal);
}
#endif

Right now, the code gets stuck in an infinite loop while polling appUdmaCopyNDIsFinished(). To be noted that we have a lot of other code calling this function and they all work, except for transpose mode. 

What's missing?

  • Hi ,

    I am checking with the team if this flag CSL_UDMAP_TR_FMTFLAGS_DFMT_TRANSPOSE is supported & validated on TDA4VL device. I will get back to you as soon as i get the answer from team. 

    Regards,

    Brijesh

  • Hi ,

    I checked with the team, and according to team, there should be any issue here. If this feature is working on TDA4VM, it should work as it is. Are you using DRU channels on both the platforms? If yes, there should not be any difference. There is a capability register in the DRU, can you please readback and confirm that it does support transpose functionality?

    But as such, this has not been validated by the team.  

    Regards,

    Brijesh

  • Hi Brijesh, could you give me a one-liner for reading the capability register?

    We are using DRU channel 0.

  • Hi FredC_LT,

    I meant below register. Can you please read the value of this register and share its value? 

    Regards,

    Brijesh

  • Hi Brijesh,

    I managed to get a print, but I get zeros in all fields of the capabilities.

    [C7x_1 ] 930306.245492 s: VX_ZONE_WARNING: CSL_DruCapabilities:
    [C7x_1 ] trTypeSupported = 0x0000000000000000
    [C7x_1 ] staticSupported = 0x0000000000000000
    [C7x_1 ] eolSupported = 0x0000000000000000
    [C7x_1 ] localTriggerSupported = 0x0000000000000000
    [C7x_1 ] globalTriggerSupported = 0x0000000000000000
    [C7x_1 ] amode = 0x0000000000000000
    [C7x_1 ] elType = 0x0000000000000000
    [C7x_1 ] dfmt = 0x0000000000000000
    [C7x_1 ] sectr = 0x0000000000000000

    Please validate that my code to read the capabilities is correct:

    
        CSL_DruCapabilities cap = {0};
        int32_t druret = CSL_druGetCapabilities(((struct Udma_DrvObj*)tivxPlatformGetDmaObj())->utcInfo[0].druRegs, &cap);
        if (CSL_PASS != druret)
        {
            VX_PRINT(VX_ZONE_ERROR, "CSL_druGetCapabilities failed with %d\n", druret);
        }
        else
        {
            VX_PRINT(VX_ZONE_WARNING,
                        "CSL_DruCapabilities:\n"
                        "\ttrTypeSupported = 0x%016lx\n"
                        "\tstaticSupported = 0x%016lx\n"
                        "\teolSupported = 0x%016lx\n"
                        "\tlocalTriggerSupported = 0x%016lx\n"
                        "\tglobalTriggerSupported = 0x%016lx\n"
                        "\tamode = 0x%016lx\n"
                        "\telType = 0x%016lx\n"
                        "\tdfmt = 0x%016lx\n"
                        "\tsectr = 0x%016lx\n",
                        cap.trTypeSupported,
                        cap.staticSupported,
                        cap.eolSupported,
                        cap.localTriggerSupported,
                        cap.globalTriggerSupported,
                        cap.amode,
                        cap.elType,
                        cap.dfmt,
                        cap.sectr);
        }

  • Hi FredC_LT,

    Are you sure that this register address is correct? Because capability register should not be set to 0. There must be some bits set in this register to indicate the capabilities of DRU.

    Regards,

    Brijesh 

  • I'm using tivxPlatformGetDmaObj() which returns &gAppUdmaDrvObj, which is initialized in appUdmaInit(), which is called in appInit().

    Flow seems fine to me, but there's clearly something wrong there.

    I'm not sure if the address is correct. I'm not familiar with this part of the chip. I'm looking for guidance on how to properly read the register.

  • Hi,

    From the MMR specs, i see that this register is available at the offest 0x6D000008, so can you please check at this offset, either using CCS or from Linux prompt? 

    Regards,

    Brijesh

  • The board crashes when I enter

    devmem2 0x6D000008

    or

    devmem2 0x6D000008 l

  • Hi ,

    Reading the DRU capability on EVM, i see it is set to 0x000188D9000D0F20, which mean DFMT is set to 0x1 and which mean it supports at max constant copy and does not support transpose functionality. 

    Regards,

    Brijesh

  • Thank you, Brijesh. Is this a fixed hardware limitation or could it be supported in a future SDK release?

  • Also, is this difference documented somewhere?

  • Hi ,

    It seems it is HW limitation, not possible to fix it in SDK/SW.

    Regards,

    Brijesh

  • Is this documented somewhere?

  • Hi ,

    May not be explicitly. let me confirm with the HW team. 

    Regards,

    Brijesh

  • Hi ,

    Meanwhile, can you also please read the DRU capability register on your setup using CCS from C7x and share its value? Please note that this is a 64bit register. 

    Regards,

    Brijesh

  • As posted before, I was not able to read the capabilities register

    Reading from the C7X:

    I managed to get a print, but I get zeros in all fields of the capabilities.

    [C7x_1 ] 930306.245492 s: VX_ZONE_WARNING: CSL_DruCapabilities:
    [C7x_1 ] trTypeSupported = 0x0000000000000000
    [C7x_1 ] staticSupported = 0x0000000000000000
    [C7x_1 ] eolSupported = 0x0000000000000000
    [C7x_1 ] localTriggerSupported = 0x0000000000000000
    [C7x_1 ] globalTriggerSupported = 0x0000000000000000
    [C7x_1 ] amode = 0x0000000000000000
    [C7x_1 ] elType = 0x0000000000000000
    [C7x_1 ] dfmt = 0x0000000000000000
    [C7x_1 ] sectr = 0x0000000000000000

    Reading from Linux

    The board crashes when I enter

    devmem2 0x6D000008

    or

    devmem2 0x6D000008 l

    I don't have CCS setup neither.

  • Hi,

    Can you please check if tivxPlatformGetDmaObj())->utcInfo[0].druRegs is correct? also can you try printing value tivxPlatformGetDmaObj())->utcInfo[0].druRegs.DRU_CAPABILITIES directly? I am doubting if this points to correct offset. Because i can see this register from CCS memory browser. 

    Regards,

    Brijesh

  • Hi,

    Indeed, it seems that tivxPlatformGetDmaObj() is not properly initialized:

    [C7x_1 ] 789867.175814 s: VX_ZONE_WARNING:[PrintCaps:37] tivxPlatformGetDmaObj()->utcInfo[0]:
    [C7x_1 ] &tivxPlatformGetDmaObj()->utcInfo[0].druRegs=0x31150000
    [C7x_1 ] tivxPlatformGetDmaObj()->utcInfo[0].numQueue=818937856
    [C7x_1 ] tivxPlatformGetDmaObj()->utcInfo[0].numCh=0


    [C7x_1 ] 789867.175867 s: VX_ZONE_WARNING:[PrintCaps:44] tivxPlatformGetDmaObj()->utcInfo[0].druRegs->DRURegs:
    [C7x_1 ] tivxPlatformGetDmaObj()->utcInfo[0].druRegs->DRURegs.DRU_PID=0x404e5a5a02
    [C7x_1 ] tivxPlatformGetDmaObj()->utcInfo[0].druRegs->DRURegs.DRU_CAPABILITIES=0x0


    [C7x_1 ] 789867.175908 s: VX_ZONE_WARNING:[PrintCaps:54] CSL_druGetCapabilities succeeded!
    [C7x_1 ] 789867.175948 s: VX_ZONE_WARNING:[PrintCaps:74] CSL_DruCapabilities:
    [C7x_1 ] trTypeSupported = 0x0000000000000000
    [C7x_1 ] staticSupported = 0x0000000000000000
    [C7x_1 ] eolSupported = 0x0000000000000000
    [C7x_1 ] localTriggerSupported = 0x0000000000000000
    [C7x_1 ] globalTriggerSupported = 0x0000000000000000
    [C7x_1 ] amode = 0x0000000000000000
    [C7x_1 ] elType = 0x0000000000000000
    [C7x_1 ] dfmt = 0x0000000000000000
    [C7x_1 ] sectr = 0x0000000000000000

  • I was able to read directly the address with:

    uint64_t* drubase = (uint64_t*) CSL_COMPUTE_CLUSTER0_MMR_DRU0_MMR_CFG_DRU_BASE;
    uint64_t pid = drubase[0];
    uint64_t caps = drubase[1];
    VX_PRINT(VX_ZONE_WARNING, "DRU PID (raw) = 0x%lx, CAPS = 0x%lx\n", pid, caps);

    it prints:

    [C7x_1 ] 791190.611898 s:  VX_ZONE_WARNING:[PrintCaps:80] DRU PID (raw) = 0x662c0902, CAPS = 0x188d9000d0f20

    So I have the same capabilities as you. I'm having trouble where to find the definition of the register, could you point me to the correct document and section, please?

  • Hi FredC_LT,

    You can find the details about this register in the MMR excel sheet, available on CDDS. 

    Regards,

    Brijesh

  • I couldn't find it in my CDDS, either because acces hasn't been granted to me or because I'm not used to the interface.

    However, it seems to now be public. I got the excel from the TRM zip package [https://www.ti.com/lit/zip/spruj28]

  • I also found this line in the TRM in section 10.4.1 DRU Overview

    Seems like it is documented, after all