• State
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 17 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TDA4VEN-Q1: TDA4VEN CSI-RX packet error detection conditions

toshiki kouzai
Prodigy 80 points

Part Number: TDA4VEN-Q1

We are using a TDA4VEN SoC and receiving video streams from three deserializers through the CSI-RX interfaces.

System Configuration

  • Deserializer #1 → CSI0_RX
  • Deserializer #2 → CSI1_RX
  • Deserializer #3 → CSI2_RX
  • Interface: MIPI CSI-2
  • Configuration: 4 data lanes + 1 clock lane per port
  • CSI0_RX and CSI1_RX receive RAW image data
  • CSI2_RX receives YUV image data

The video streams can be received successfully by the SoC and image data appears to be available. However, we observe packet-related errors reported by the CSI-RX diagnostic registers, as shown in the attached screenshot.

From the log, we see the following error indication:

  • CSIRX_ERROR_IRQ
    • PAYLOAD_CRC_HEAD_ERR = NG (0x00001000)
  • CSIRX_IF_ERR_IRQ
    • Frame truncation error detected

Question

Could you please explain under what conditions the following errors are generated?

  • PAYLOAD_CRC_HEAD_ERR
  • Frame truncation error

Specifically, we would like to understand:

  1. What internal CSI-2 protocol violations or packet conditions trigger these error bits?
  2. Can these errors occur even when image data is successfully received?
  3. Are there known causes related to RAW/YUV mixed usage across different CSI-RX ports?
  4. Are there any recommended debug steps or registers that should be checked to identify the root cause?

Our goal is to narrow down the source of the packet error and determine whether it originates from the deserializers, the CSI-2 transmission path, or the TDA4VEN CSI-RX receiver.

  • 0
    TI__Guru**** 500345 points

    Hi,

    CRC comes when incoming packets has bits inverted, so when CSIRX calculates CRC, it will not match with the CRC in the received packet. This essentially means the received data has error. 

    When you say Frame truncation error, i guess you are getting header truncated error or packet truncation error. This also essentially means received packet is of incorrect size. 

    I really doubt these are coming due to RAW and YUV Mixes usage, since you are using different CSIRX instances for RAW and YUV data. In order to confirm this, you can independently check these instances and see if they report any error. 

    Lets first check RAW or YUV data capture in each CSIRX instances and confirm that there are no errors. 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Prodigy 80 points

    Hi Brijesh,

    Thank you for your explanation.

    From your description, is it correct to understand that the CRC errors and Frame Truncation Errors are most likely caused by invalid/corrupted packets being received, rather than by the mixed usage of RAW and YUV streams?

    Also, we are not completely sure about the CSIRX instance assignment at the moment. There is a possibility that both stream #1 and #2 are assigned to CSI0_RX. In such a configuration, are there any other possible causes or items that you would recommend checking?

    As suggested, we checked each CSIRX instance independently (RX0 and RX1). We observed packet corruption errors on RX0, while RX1 showed no successfully received packets. The packet corruption error is indicated by the white hatched area in the attached screenshot.

    Regards,

    Toshiki