• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 1299 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: The ECC and CRC errors cause the csirx driver can not receive the image

subin li
Expert 1050 points
Part Number: TDA4VM


Dear experts,

I use psdk_rtos_sdk_07_03 to develop TDA4 software.

In some extreme cases, our camera will send some erroneous image data to csirx through the LVDS link. 

In this case crcCount and eccCount increase rapidly as shown by “CsirxDrv_errorEventIsrFxn()” in the file "csirx_event.c". Then we cannot receive image data in csirx, and CsirxDrv_udmaCQEventCb() will not be called.

I cannot solve the problem by powering off and powering on the camera.

I cannot solve the problem by calling Csirx_deInit() and Csirx_init().

But if I  powering off and powering on the TDA4, it will get back to normal.

Our question is:

        When this problem occurs, how to get back to normal in the case of uninterrupted power?

I asked a similar question more than a year ago as shown in the link below;

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/971127/tda4vm-csirx-ecc-and-crc-error

The advice you gave me before was that this issue may solved on ES1.1, but we are already using ES1.1

  • 0
    TI__Guru**** 479825 points

    Hi Subin Li,

    I think there were some changes in the way we should close and reopen the driver in the later release, let me check and share the patches.

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Expert 1050 points

    Hi Brijesh

    Hope to get your reply soon.

    Regards,

    subin

  • 0 in reply to Brijesh Jadav
    Expert 1050 points

    Hi Brijesh

    thank you for your reply.

    I have seen the link you send, but I think the problem described there is not the same as what we encountered. Our problem has nothing to do with the channel mask.

    We have our own set of software at the upper level, so we don't use the imaging and tiovx. Our software is somewhat more similar to csirx_test.c.

    I have seen the PDK.patch, and I think the patch just optimize the startup process of csirx. These modifications can also be found in sdk8.2.

    I applied the PDK.patch, but it didn't solve our problem.

    Can you help us analyze the problem in more detail based on the phenomenon I described?

    thank you!

    Regards,

    subin

  • 0 in reply to subin li
    TI__Guru**** 479825 points

    Hi Subin li,

    subin li said:
    I have seen the link you send, but I think the problem described there is not the same as what we encountered. Our problem has nothing to do with the channel mask.

    The issue is not just about channel mask. The issue is about clean exit, so applicable even in this case. 

    subin li said:
    We have our own set of software at the upper level, so we don't use the imaging and tiovx. Our software is somewhat more similar to csirx_test.c.

    Even in this case, can you please refer to the change here and implement similar changes for your sensor/SERDES? 

    Another question i have is, do you still get the ECC and CRC errors from the sensor? 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Expert 1050 points

    Hi Brijesh

    thank you for your reply.

    I've checked our serdes/sensor init/deinit process and no problem found. So imaging.patch is useless for us.

    We don't use the tiovx, so imaging.patch is useless for us.

    We use the pdk.patch, but the problem still exists.

    We still get the ECC and CRC errors. The errors increasing in CsirxDrv_errorEventIsrFxn().

    I have some new findings. When this problem occurs, the ECC becomes particularly large. And it's still increasing.

    When I do deinit and init, CSIRX can't receive the image, but the ECC is still increasing.

    Regards,

    subin

  • 0 in reply to subin li
    TI__Guru**** 479825 points

    Hi Subin Li,

    But if the sensor is keeping outputting ECC/CRC errors, there is nothing much we can do in CSIRX. Can you please first make sure that there are no ECC/CRC errors from sensor? 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Expert 1050 points

    Hi Brijesh

    thank you for your reply.

    I don't think the increase in ECC and CRC is caused by sensors or serdes. Because in the process of deinit and init, we will power off and power on the sensor and serdes, and reconfigure them according to the correct timing requirements. So I think the data output by sensor and serdes is not wrong.

    So I think at that time maybe csirx or the udma or interrupt it involves is in the wrong state. 

    Is there any operation that can perform a power-off reset on cSIRX to free up all resources or clean up the error state?

    Another phenomenon is that after we have done several deinit and init operations, the CsirxDrv_errorEventIsrFxn() function is not entered, so neither ECC nor CRC increases. At this time, the sensor and serdes have output data, but TDA4 does not seem to generate interrupt, so it does not enter the interrupt handler function.

    Regards,

    subin

  • 0 in reply to subin li
    TI__Guru**** 479825 points

    Hi Subin Li,

    The changes i shared earlier will make sure to start the CSIRX cleanly, by resetting it. There is no change required in the udma, because ecc error is reported by csirx. 

    Can you put breakpoint on the ECC ISR (error callback) and see if interrupt cleared correctly?

    Can you please try in later release of CSIRX driver? Since you are not using TIOVX or imaging, it should be easy to take driver from later release and try it? 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Expert 1050 points

    Hi Brijesh

    thank you for your reply.

    Brijesh Jadav said:
    The changes i shared earlier will make sure to start the CSIRX cleanly, by resetting it. There is no change required in the udma, because ecc error is reported by csirx. 

    We found it's not enter CsirxDrv_udmaCQEventCb(), so we think there isn't udam event. So we suspect this issue may be related to udma.

    Brijesh Jadav said:
    Can you put breakpoint on the ECC ISR (error callback) and see if interrupt cleared correctly?

    We found when enter CsirxDrv_errorEventIsrFxn(), it will use CSIRX_SetErrorIrqs() to clear event status, and the times of entries and exits of CsirxDrv_errorEventIsrFxn() is equal. So we think the interrupts cleared correctly.

    Brijesh Jadav said:
    Can you please try in later release of CSIRX driver? Since you are not using TIOVX or imaging, it should be easy to take driver from later release and try it? 

    We use the CSIRX driver in SDK8.2 to replace the driver we use now, the problem still exists.

  • 0 in reply to Brijesh Jadav
    Expert 1050 points

    Hi Brijesh

    I have some new findings, I don't know if it will help you to analyze the problem.

    I dump all the register value about the csirx.

    reg addr before the problem after the problem
    0x04504020 0x22 0x62
    0x04504048 0x333306 0x333300
    0x0450404c 0x100 0x100100
    0x04504060 0x10000000 0x100d0000
    0x04504074 0xd2fe00de 0x0
    0x04504104 0x80000133 0x80000111

    Can you find something based on these register value changes?

    Also, I suspect that dphy_rx is not reset during deinit and init of csirx. I found that SET_DEVICE_STATE_ON(TISCI_DEV_DPHY_RX0) is performed in appCsi2RxInit(), but the reverse is not performed in appCsi2RxDeInit(), could there be a problem here?

    How can I reset dphy_rx?

    Regards,

    subin

  • 0 in reply to Brijesh Jadav
    Expert 1050 points

    Hi Brijesh

    subin li said:
    Also, I suspect that dphy_rx is not reset during deinit and init of csirx. I found that SET_DEVICE_STATE_ON(TISCI_DEV_DPHY_RX0) is performed in appCsi2RxInit(), but the reverse is not performed in appCsi2RxDeInit(), could there be a problem here?

    I implemented the operation of SET_DEVICE_STATE_OFF(TISCI_DEV_DPHY_RX0),  SET_DEVICE_STATE_OFF(TISCI_DEV_CSI_RX_IF0) and SET_DEVICE_STATE_OFF(TISCI_DEV_CSI_PSILSS)) in appCsi2RxDeInit()， then this issue seems to have been resolved.

    Please help us confirm this modification.

    On the other hand, we want to know if we can implement a mechanism to automatically eliminate the error and restore functionality when the dphy_rx or cisrx fails to receive images due to an error.

    Regards,

    subin

  • 0 in reply to subin li
    TI__Guru**** 479825 points

    Hi Subin,

    subin li said:
    I implemented the operation of SET_DEVICE_STATE_OFF(TISCI_DEV_DPHY_RX0),  SET_DEVICE_STATE_OFF(TISCI_DEV_CSI_RX_IF0) and SET_DEVICE_STATE_OFF(TISCI_DEV_CSI_PSILSS)) in appCsi2RxDeInit()， then this issue seems to have been resolved.

    Good to know this issue resolved. It looks like it is not detecting clock (0x04504048 is set 0x333300). Resetting the PHY seems to be good solution. 

    Since the issue is resolved, closing this ticket. 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Expert 1050 points
    Brijesh Jadav said:
    Good to know this issue resolved. It looks like it is not detecting clock (0x04504048 is set 0x333300). Resetting the PHY seems to be good solution. 

    Hi Brijesh

    When it is not detecting clock (0x04504048 is set 0x333300), Is there any other way other than reset dphy to get it back to normal?

    Regards,

    subin

  • +1 in reply to subin li
    TI__Guru**** 479825 points

    Hi subin li,

    No, i can't think of anything else. I think this way of resetting phy was present in my patch as well.. 

    Regards,

    Brijesh