• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 97 subscribers
  • Views 457 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.

TDA4VL-Q1: Does Driver layer drop the frame occasionally in the CSIRX module?

Zekun Bai
Expert 3675 points
Part Number: TDA4VL-Q1

Hi, Expert

Our customer have done an experienment about CSIRX module drop frame count. They insert an I-O Toggle into the callback function of frame capture(CsirxDrv_udmaCQEventCb).

They tested the waveform of MIPI and I-O Toggle. 

Normally when MIPI's signal ends, the frame capture process node is in processing and go into the callback function, then I-O will be toggled. So you can see that I-O toggle will happen in the  corner of the MIPI. But when power on, during the initial period, I-O toggle will happen in the middle of the MIPI waveform. They add a drop count frame code in the driver and find that when I-O toggle happen in wrong place, drop count value will be not 0. 

So does Driver layer drop the frame occasionally in the CSIRX module, especially for the initial period of power on?

Looking forward to you reply. Thanks in advance.

Regards

Zekun 

  • 0
    TI__Guru**** 479035 points

    Hi Zekun,

    This can happen only if the CSIRX receives early end of frames.. You can check the status of this frame and see if it is complete or not. 

    CSIRX is just a receiver, it just works based on the incoming signals. So if there is a early end of frame, then we will see this early GPIO toggle and driver will indicate to the application that this is a short received frame.. 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    TI__Expert 3675 points

    Hi, Brijesh

    But in this scenario, the incoming signals should keep same length from my understanding as the MIPI is keeping transmitting image. Please correct me if my understanding is wrong. If length keep same, then this short received frame need to be considered as a wrong frame or not?

    actually they did another test, they change the I-O toggle to I-O pulse and change the code position to the IF branch as below:

    and the waveform is as below:

     

    As you can see, the I-O pulse need to occur in every corner of the MIPI waveform, but there lacks of several I-O pulse when power on. 

    This scenario seems more like dropping frame. Appreciate your help and look forward to your reply.

    Regards

    Zekun

  • +1 in reply to Brijesh Jadav
    TI__Expert 3675 points

    Hi, Brijesh

    According to customer's requirement, let's use this internal link to trace this issue:

    e2e.ti.com/.../tda4vl-q1-does-driver-layer-drop-the-frame-occasionally-in-the-csirx-module

    Thanks

    Zekun

  • 0 in reply to Brijesh Jadav
    TI__Expert 3675 points

    Hi， Brijesh

    Can you please help to point out if there is a way to monitor whether the early ends of the frame is received. Some register value to indicate this scenario？

    Another question is that the early end of frame is a normal or abnormal scenario? Is there any description in the TRM?

    Looking forward to your reply.

    Thanks

    Zekun

  • +1 in reply to Zekun Bai
    TI__Guru**** 479035 points

    Hi Zekun,

    Well the driver marks these frames as erroneous in below code. But i dont think this is being used in the OpenVX node. Can you please check for this error in the Fvid2_Frame and see if this error (FVID2_FRAME_STATUS_ERROR) is getting set? 

                            /* check only 'STATUS_TYPE' fields of TR response */
                        if ((CSL_REG32_RD(pTrResp) & 0xFU) != 0U)
                        {
                            if ((chObj->status == CSIRX_DRV_CH_STATE_STOPPING) ||
                                (chObj->status == CSIRX_DRV_CH_STATE_STOPPED))
                            {
                                /* Aborted frame due to forced teardown at
                                   Udma_chDisable() */
                                qObj->frm->status = (uint32_t)FVID2_FRAME_STATUS_ABORTED;
                            }
                            else
                            {
                                /* Received frame is either truncated/elongated */
                                qObj->frm->status = (uint32_t)FVID2_FRAME_STATUS_ERROR;
                                chObj->instObj->status.errorFrameCount[chObj->chCfg->chId]++;
                            }

    Also early end of frame is not normal scenario.. This is not coming from CSIRX, so it will not be explained in the TRM. CSIRX is a receiver, it is just detecting these frame markers. 

    Regards,

    Brijesh