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

TDA4VM: CSI interface data ID errors management

Ugo Bertacchini
Intellectual 300 points
Part Number: TDA4VM

Hello experts,

we are trying to capture (12 bits) raw image data from our camera on a CSI 2 interface.
In addition to the image data (with data type 0x2C) the sensor is sending some lines of embedded data (with 2 different data types) and optical black data with yet another data type (so we have 4 different data types in total).

We modified the csirx_capture_test example to test the frame capture.
If we create one CSI RX channel for data type 0x2C, we receive frames but with “Data ID” error: we have 3 times the number of Data ID errors as the number of received frames. No data seems to be copied inside the frame: the content is all zeros.

 
•    What can cause this data ID error? Can it be because of the different data type of the embedded and optical black data?
•    How do we have to configure the CSI channels to avoid these errors and properly receive the frames?
•    Do these data ID errors prevent image data to be properly received and copied into the frames?

If we enable error bypass, by setting appInstObj->createPrms.instCfg.enableErrbypass to TRUE, we get "Stream0 FIFO Overflow" errors, 1 per frame.

•   What can be the root cause for these errors ? 
•    Does it indicate a wrong configuration for the frame size?

Thanks for the support and regards.

  • 0
    TI__Guru**** 476815 points

    Hi Ugo,

    There is a possibility that both the issues Data ID error and overflow errors are because of the single channel being configured for the capture. I see you are using PDK standalone example for this capture. In this case, can you please enable all channels in this example and try to capture? This capture example can support capture for this metadata by setting correct data type and size of the frame correctly.   

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 300 points
    Hi Brijesh, thanks for the answer.
    When using 4 channels (APP_CAPT_CH_NUM == (uint32_t)4U) we are receiving the same kind of errors:

    Frames received = 300
    Data ID Error Count = 900
     
    CSIRX_CAPT_APP:[Channel No: 0] | Frame Queue Count: 304 | Frame De-queue Count: 304 | Frame Drop Count: 0
    CSIRX_CAPT_APP:[Channel No: 1] | Frame Queue Count: 4 | Frame De-queue Count: 4 | Frame Drop Count: 0
    CSIRX_CAPT_APP:[Channel No: 2] | Frame Queue Count: 4 | Frame De-queue Count: 4 | Frame Drop Count: 0
    CSIRX_CAPT_APP:[Channel No: 3] | Frame Queue Count: 4 | Frame De-queue Count: 4 | Frame Drop Count: 0

    For this test to work, we need to set the virtual channel chCfg.vcNum = to Channel number. (so vcNum = 0 for channel 0, vcNum = 1 for channel 1, and so on)


    It seems that we can not fix the virtual channel to 0 which is where our sensor is sending all the data.
    When we try to fix the virtual channel to 0, TDA4 is not detecting frames, it just detects data ID errors:

    CSIRX_CAPT_APP: Frames Received: 0
    CSIRX_CAPT_APP: Frames Received with errors: 0
    CSIRX_CAPT_APP: Capture Application Completed!!!
    CSIRX_CAPT_APP: FIFO Overflow Count: 0
    CSIRX_CAPT_APP: Spurious UDMA interrupt count: 0
    CSIRX_CAPT_APP: Front FIFO Overflow Count: 0
    CSIRX_CAPT_APP: CRC Error Count: 0
    CSIRX_CAPT_APP: Un-corrected ECC Error Count: 0
    CSIRX_CAPT_APP: Corrected ECC Error Count: 0
    CSIRX_CAPT_APP: Data ID Error Count: 900
    CSIRX_CAPT_APP: Invalid Access Error Count: 0
    CSIRX_CAPT_APP: Invalid Short Packet Receive Error Count: 0
    CSIRX_CAPT_APP: Stream0 FIFO Overflow Error Count: 0
    CSIRX_CAPT_APP:[Channel No: 0] | Frame Queue Count: 4 | Frame De-queue Count: 4 | Frame Drop Count: 0
    CSIRX_CAPT_APP:[Channel No: 1] | Frame Queue Count: 4 | Frame De-queue Count: 4 | Frame Drop Count: 0
    CSIRX_CAPT_APP:[Channel No: 2] | Frame Queue Count: 4 | Frame De-queue Count: 4 | Frame Drop Count: 0
    CSIRX_CAPT_APP:[Channel No: 3] | Frame Queue Count: 4 | Frame De-queue Count: 4 | Frame Drop Count: 0
    CSIRX_CAPT_APP: 0 frames captured in 10000 msec at the rate of 0. 0 frames/sec.

    We've tried setting a DT for each channel, but we are still getting data only for Channel 0.

    So, can you share any details on how we should configure these Channels? 
    Can we set the virtual channel to 0 for all of the channels? If so, where should we do so?

    In addition to that, is there any datatype that rises errors on TDA4 side? It seems like some of the DT are giving us problems, but not all of them.
  • +1 in reply to Ugo Bertacchini
    TI__Guru**** 476815 points

    Hi Ugo,

    As discussed in the call yesterday,

    - Meta data type 0x13 is reserved data type, as per the MIPI specs, so this data should not be used as metadata. CSIRX will not able to capture this datatype. Please change the datatype to starting from 0x30. This is valid user defined datatype as per MIPI specs.

    - Also please setup output for all CSIRX channels that are getting transmitted. Otherwise there might be overflow error, which can also affect other streams.

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 300 points

    Thanks Brijesh,

    we were able to change the datatype and continue with the integration.

    Best regards,

    Ugo

  • 0 in reply to Ugo Bertacchini
    TI__Guru**** 476815 points

    Thanks Ugo, does it mean you are able to capture all three types of data without DATA ID and/or overflow error? 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 300 points

    Yes, we get rid of data id and overflow errors.

    Nevertheless we are still receiving some generic errors but not for all the frames.  We are trying to understand the root cause (at the moment we suspect they are related to unespected frame size).

  • 0 in reply to Ugo Bertacchini
    TI__Guru**** 476815 points

    Thanks Ugo, i will move this thread status to waiting for customer. We can reopen it if you have further questions/update.

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 300 points

    Thanks Brijesh,

    I have selected "This resolved my issue" on the answer you gave. We will open other specific question when required.

    Best regards.

    Ugo