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.

TDA4VM: CSITX verify

Part Number: TDA4VM

Hi everyone,

I have created a graph with only CSITX node and i want to send data from memory and see if CSITX is able to transmit.

I configure CSITX node parameters as follows:

    tivx_csitx_params_init(&local_csitx_config);
    local_csitx_config.numInst                          = 1U;
    local_csitx_config.numCh                            = NUM_CHANNELS;
    local_csitx_config.instId[0U]                       = CSITX_INST_ID;
    local_csitx_config.instCfg[0U].rxCompEnable         = (uint32_t)vx_true_e;
    local_csitx_config.instCfg[0U].rxv1p3MapEnable      = (uint32_t)vx_true_e;
    local_csitx_config.instCfg[0U].laneBandSpeed        = TIVX_CSITX_LANE_BAND_SPEED_770_TO_870_MBPS;
    local_csitx_config.instCfg[0U].numDataLanes         = 4U;
    for (uint8_t loopCnt = 0U ;
        loopCnt < local_csitx_config.instCfg[0U].numDataLanes ;
        loopCnt++)
    {
        local_csitx_config.instCfg[0U].lanePolarityCtrl[loopCnt] = 0U;
    }
    for (uint8_t loopCnt = 0U; loopCnt < NUM_CHANNELS; loopCnt++)
    {
        local_csitx_config.chVcNum[loopCnt]   = loopCnt;
        local_csitx_config.chInstMap[loopCnt] = CSITX_INST_ID;
    }

I initialize transmit buffers as follows:

printf("Initializing Transmit Buffers...\n");
    for (frmIdx = 0U ; frmIdx < NUM_CHANNELS ; frmIdx++)
    {
        tx_frame_array_item = (tivx_raw_image)vxGetObjectArrayItem(tx_frame , frmIdx);
        /* Initialize raw_image with running pattern using WRITE ONLY MAP */
        tivxMapRawImagePatch(tx_frame_array_item, &rect, 0U, &map_id, &addr, (void **)&ptr,
                                        VX_WRITE_ONLY, VX_MEMORY_TYPE_HOST, TIVX_RAW_IMAGE_PIXEL_BUFFER);
        //ASSERT(ptr != NULL);
        for (i = 0; i <CSITX_IMAGE_HEIGHT; i++)
        {
            for(j=0; j<CSITX_IMAGE_WIDTH; j++)
            {
                ptr[((i*CSITX_IMAGE_HEIGHT)+j)] = (j + frmIdx);
            }
        }
        /* Do cache operations on each buffer to avoid coherency issues */
        appMemCacheWb(ptr, (CSITX_IMAGE_HEIGHT * CSITX_IMAGE_WIDTH * sizeof(uint16_t)));
        tivxUnmapRawImagePatch(tx_frame_array_item, map_id);
        tivxReleaseRawImage(&tx_frame_array_item);
    }
    printf("Initializing Transmit Buffers Done.\n");

Application stuck in verify phase (vxVerifyGraph function). vxVerifyGraph function doesn't return any status.

Can anybody give some advice how to handle this problem?

Best regards.

  • Hi Aleksandar,

    Are you still facing this issue? 

    Can you please try commenting out portion of the code where you are filling up the buffer space? 

    Also what the is the value of num_channels? Can you make sure to keep it one? 

    Rgds,

    Brijesh

  • Hi Brijesh.

    We have solved the issue with verify graph, application now passes successfully this phase.

    We have found some problems with your driver code, precisely the register(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_DPHY_TX0_CTRL) which is used to select CSI output instead of DSI output isn't configured correctly. It's value is 0x0 instead of 0x1. We found out that this register should be unlocked before writing new value to it.

    Also we had an issue with CSITX task creation, specifically this function tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_CSITX, 16, "TIVX_CSITX", 8u) that is being executed on RTOS proccessor R5F does not actually create that Task. We figured out thet the priority of 8 was the issue so we raised the priority to 15 and now Task is being created successfully. We also noticed the same issue with creating custom kernels where priority needs to be raised.

    Regards,

    Aleksandar.

  • Hi Aleksandar,

    Which SDK release are you using? In SDK7.3 release, i see that this bit is set in CsitxDrv_dphytxSelectSrc API in the pdk_jacinto_07_03_00_29/packages/ti/drv/csitx/soc/V0/csitx_soc.c file.

    Do you see task with the priority 8 not being scheduled at all? 

    We have CSITX test working fine on EVM, so the issue is something else. do you have any other high priority task on R5F, which is taking up CPU time and not allowing CSITX task to run?

    Regards,

    Brijesh

  • Hi Brijesh,

    I am using PSDK_7.0.2.006 and we are using usecase from the PSDK framework and the not from the PDK examples. I have checked the file which you are talking about, have you read that register after setting this value? In PSDK this bit is set in appCsi2TxInit in vision_apps/utils/hwa/src/app_hwa.c, but when we read it's value it is 0x0(although there are function call for setting this value to 0x1). Then we unlock that register and value is set correctlly after that. To do that we call Board_init(boardCfg) function with the following configuration boardCfg = BOARD_INIT_UNLOCK_MMR in vision_apps/apps/basic_demos/app_tirtos/common.app_init.c before appCsi2TxInit function call.


    We have capture tasks with higher priority(there are eight capture tasks with priority 15).

    Which test you use for CSITX test, test_csitx_csirx.c? We have referred to test_csitx_csirx.c while we were developing our application.
    We want to send image from CSI output(image from TDA4 memory) to DS90UB953 serializer and then to pass that on FPD output(CSITX -> DS90UB953 -> FPD).

    Basically we want to stream data with CSITX node, is there any restrictions to do that?

    Regards,

    Aleksandar

  • Hi Aleksandar,

    Agreed, this register is being written without unlocking control MMR, i have raised this issue to team and will be fixed in upcoming release. 

    Nope, there is not restriction in sending data over CSITX. Even if the capture is running at highest priority, there would be sometime when CSITX task will get scheduled and it should send out the data. Do you see it not getting scheduled at all? Any other task other than capture running on this R5F?

    Regards,

    Brijesh

  • Hi Brijesh,

    In the following file tivx_target_config_mcu2_0.c there is a fuction  tivxPlatformCreateTargets that is called once when vision_app_init.sh script is executed. All of the tasks that are below 13 priority are not being scheduled at all. When we use these kernels in our TIOVX applications we don't get IPC ACK from these Tasks in the creation phase (vxVerifyGraph). This is how we noticed that these Tasks are not scheduled properly. We also attached content of the tivxPlatformCreateTargets function.

    void tivxPlatformCreateTargets(void)
    {
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_IPU1_0, 0, "TIVX_CPU", 4u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_VPAC_NF, 1, "TIVX_NF", 8u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_VPAC_LDC1, 2, "TIVX_LDC1", 8u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_VPAC_MSC1, 3, "TIVX_MSC1", 8u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_VPAC_MSC2, 4, "TIVX_MSC2", 8u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_DMPAC_SDE, 5, "TIVX_SDE", 8u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_DMPAC_DOF, 6, "TIVX_DOF", 8u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_VPAC_VISS1, 7, "TIVX_VISS1", 13u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_CAPTURE1, 8, "TIVX_CAPT1", 15u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_CAPTURE2, 9, "TIVX_CAPT2", 15u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_DISPLAY1, 10, "TIVX_DISP1", 14u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_DISPLAY2, 11, "TIVX_DISP2", 14u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_VDEC1, 12, "TIVX_VDEC1", 8u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_VDEC2, 13, "TIVX_VDEC2", 8u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_VENC1, 14, "TIVX_VENC1", 8u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_VENC2, 15, "TIVX_VENC2", 8u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_CSITX, 16, "TIVX_CSITX", 8u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_CAPTURE3, 17, "TIVX_CAPT3", 15u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_CAPTURE4, 18, "TIVX_CAPT4", 15u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_CAPTURE5, 19, "TIVX_CAPT5", 15u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_CAPTURE6, 20, "TIVX_CAPT6", 15u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_CAPTURE7, 21, "TIVX_CAPT7", 15u);
        tivxPlatformCreateTargetId((vx_enum)TIVX_TARGET_ID_CAPTURE8, 22, "TIVX_CAPT8", 15u);
    }

    Regards,

    Aleksandar

  • Hi Aleksandar,

    We have multiple examples in vision apps, which use many of the targets multiple times and we don't see this issue. For example, multi-camera example uses capture, viss, ldc and msc nodes, and this example is running fine on EVM. 

    So again do you have any other higher priority, CPU consuming task running on the R5F, which you have added?  

    Because in the above list, the only with the priority higher than 13 are encode/decode and capture. I really doubt that this takes up so much that other tasks do not get the chance to run. 

    Regards,

    Brijesh 

  • Hi Brijesh,

    We have figured out what was the issue with Tasks on R5F not being scheduled. We have added three new remote services for R5F in vision apps and the issue was with this define value (#define APP_REMOTE_SERVICE_HANDLERS_MAX  (8u)). We needed to raised this value to more than 8, and now we don't have problems with Task creation.

    Unfortunately, we still have a problem with CSITX usecase, now the graph application executes successfully and we can see on statistics that the frames are being produced but on the physical layer(FPD connectors) we don't have any image signal.

    This might be related to the our custom hardware design that we are looking into, but in the meantime do you have any other suggestions that we can also try?

    Can you also explain in more details (because there are very little information in documentation) CSITX parameters rxCompEnable and rxv1p3MapEnable? How relevant are these parameters for our usecase?

    Regards,

    Aleksandar

  • Hi Aleksandar,

    Where is the output of CSITX connected? Is termination enable on the receiver side? Without proper termination enable, it might not work. Could you please check?

    Regards,

    Brijesh

  • Hi Brijesh,

    We had issue with our HW design. We have solved this issue and now we have fully functional our use case. Thank you very much for support!

    Best regards,

    Aleksandar Kecman.

  • Thank you Aleksandar for the update. closing this thread.