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: TDA4VM CSITX question

Part Number: TDA4VM

hi expert 

sdk8.2 qnx+rtos

1.Is there a technical manual provided for TDA4 CSITX status and fault registers outside of the TRM manual

2.Is there a successful mass production case of TDA4 with CSITX direct connection (no Serializer and deserializer on the link), especially the successful mass production case of direct connection 8155

3.At present, the product has been mass-produced, and there are serious issues related to CSITX in the end market. We expect TI to provide a local interface person in China, who will coordinate the 8155 chip technology interface person with OEM, as well as Tire1 of TDA4 and 8155, to solve the problem together and discuss follow-up strategies

  • Hi,

    1.Is there a technical manual provided for TDA4 CSITX status and fault registers outside of the TRM manual

    May I know if you would like to know anything more specific that is missed in the TRM?

    2.Is there a successful mass production case of TDA4 with CSITX direct connection (no Serializer and deserializer on the link), especially the successful mass production case of direct connection 8155

    3.At present, the product has been mass-produced, and there are serious issues related to CSITX in the end market. We expect TI to provide a local interface person in China, who will coordinate the 8155 chip technology interface person with OEM, as well as Tire1 of TDA4 and 8155, to solve the problem together and discuss follow-up strategies

    Let me check this internally and get back to you

    Regards,

    Nikhil

  • hi expert 

    1.When an error occurs, we want to know the status of CSITX to assist the receiving end in resolving the resulting error, There are many csitx registers in TRM that do not have detailed meanings, such as CSI_ TX_ IF_ DPHY-STatus: DPHY_ ULPS and DPHY_ STOPSTATE;

    Perhaps my description is not accurate enough; Or rather, we use CSITX to communicate with another SOC (no Serializer and deserializer on the link). If I want to monitor the integrity and effectiveness of our sent data, and if there are errors, we want to use some status of our sending end to assist in solving the problem, I should refer to which registers to use

  • Hi Yao Zhang,

    If I want to monitor the integrity and effectiveness of our sent data, and if there are errors, we want to use some status of our sending end to assist in solving the problem

    The integrity and effectiveness are monitored on the receiving end (i.e. csirx). The csitx can only transmit the data. 

    2.Is there a successful mass production case of TDA4 with CSITX direct connection (no Serializer and deserializer on the link), especially the successful mass production case of direct connection 8155

    Typically the usecase involves a SERDES.

    At present, the product has been mass-produced, and there are serious issues related to CSITX in the end market. We expect TI to provide a local interface person in China, who will coordinate the 8155 chip technology interface person with OEM, as well as Tire1 of TDA4 and 8155, to solve the problem together and discuss follow-up strategies

    Please check with the Local TI support for the same.

    Regards,

    Nikhil

  • 1.The error reported by our competitor has been analyzed in detail as CSI frame loss, FIFO queue data is empty. Do we have any relevant processing experience and investigation direction
    2.The bits of the registers in the attached figure can indicate the loss of CSI frame header data and the empty FIFO queue data

  • Hi,

    As mentioned above, the errors from the transmitting side can only be identified from the csirx receiver diagnostics, and you can check if it is a FIFO overflow, ecc error or crc error etc. 

    Let me check internally again, if there are any error checker for CSITX

    Regards,

    Nikhil

  • Hi,

    The errors obtained from csitx are 

    Csitx_fifoUnderflow : Indicates Synchronization FIFO has underflowed. Caused by the rate at the PPI interface being higher than the data rate at the pixel interface

    Csitx_dataFlowErr : Caused by the system attempting to start a frame when the controller or D-PHY are not ready

    Csitx_byteCntMismatch : Indicates that the number of bytes received for a line on the pixel interface did not match the programmed word_count for the particular virtual channel.

    Csitx_lineNumberErr: Indicates that the number of lines received for a frame on the pixel interface exceeded the programmed max_line_number value for the particular virtual channel

    But these errors are checked before sending the data to DPHY, i.e. within the csitx controller. 

    Anything, sent on the dphy should be checked at the csirx end.

    Regards,

    Nikhil