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.

TDA3MV: Identification of captured consecutive frames with having the same CRC (identical frames)

Part Number: TDA3MV

Hello,

I am using an own and lightweight CSI-2 capture driver to recieve frames from the UB954 deserializer. The driver is working good and there is also an CRC-error interrupt implemented.

But I need to identify incoming identical frames without an CRC-error. It could also happend, if there is an unknown error and the capture driver fakes a new frame. This is a safety feature requested from the customer.

Is there a way to read the CRC from the CSI-2 stream (packet footer)? Or is there another solution to identify identical frames?

Best regards,
Milan

  • Hi Milan,

    In this case of CRC error, you will get error interrupt from the capture module, you could process it and mark the frames accordingly .

    Rgds,
    Brijesh
  • Hi Brijesh,

    the CRC error handling is implemented.

    I need to identify incoming identical frames without an CRC-error. So I would like to read e.g. the CRC value from the CSI-2 frames. Is it possibel or is there another indicator for identical frames on CSI-2 or CAL level?

    Another idea is to read the CAL_CSI2_STATUS0_l register that contains the frame number generated from the sensor. So if two consecutive frames have the same frame number, then something gone wrong. That's, what I need to check.
    The disadvantage is the dependency from the sensor, so do you have another idea?

    Best regards,
    Milan
  • Hi Milan,

    There is a CRC module in TDA3x, that you could use to generate unique signature for the frame and signature could be used to see if the frames are identical..

    The CRC on the CSI packets is not for entire frame, but for that packet, which typically just have one line of data..

    Rgds,
    Brijesh
  • Hi Brijesh,

    thank you for your fast response.

    Ok, but a seperate CRC calculation needs to much performance. I hoped to have an indicator on CSI-2 or CAL level for this.

    So I have to use the frame number from the sensor. In case of the IMX390 I can check the frame counter inside the embedded data, so this is a good solution, I think.

    If anybody have another idea, so let me know.

    Best regards,
    Milan

  • Hi Milan,

    The additional CRC need not be done for the complete frame, may be we could limit it to ROI.

    The frame-number is provided by FS and FE short packets (note that it could be 0 (always 0), if the sensor do not implement frame numbering). Recommend to check with IMX390 on this usecase scenario.

    Regards,
    Sujith
  • Hi Sujith,

    yes, to use a ROI to calculate CRC is a possibility but also an overload and this would extends the video output latency.

    Regards,
    Milan

  • Hi all,

    for the capture driver I use the DMA_START1 event to trigger the ISR.
    If this interrupt occures, which frame is related to the frame counter in the register CAL_CSI2_STATUS0_l? Is it the frame counter of the last captured frame or the current arrived frame beginning with start of frame packet?

    Which CSI-2 packet contains the frame counter?

    Best regards,
    Milan

  • Hi Milan,

    The frame-number are sent as part of frame-synchronization short packets. So, when we read the frame counter on occurrence of DMA start event, it would reflect the current frame being captured.

    Regards, Sujith

  • Hi Milan,

    I haven't heard back from you, I'm assuming you were able to resolve your issue. If not, just post a reply below (or create a new thread if the thread has locked due to time-out).

    Regards, Sujith