• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 33 subscribers
  • Views 144 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.

DS92LX1621: CRC Errors in back channel with enabled GPIOs

Simon Gerber
Prodigy 10 points
Part Number: DS92LX1621

Tool/software:

Hi,

we are using a DS92LX1621/1622 with custom designed PCBs to transfer data from a camera to an FPGA board. Additionally, we have frame trigger and a PWM signal which we would like to transfer from FPGA board to camera using one of the GPIOs.

Ser/Des chips are setup in camera configuration and things are working mostly. We can establish a stream from our camera with our defined trigger pulses.

However, if we configure the second GPIO in direction from DES -> SER and try to transfer our PWM signal (also with constant HIGH), we observe many back-channel CRC errors and spurious signals on other GPIOs.

In forward direction CRC error counter is normally 0.

We also observed that PCLK on serializer switches between 50MHz when reading from camera to 25MHz int. clock between frames. At the time of this switch, the LOCK pin on DES goes low for ~280us. This seems also to be the time when spurious signals appear on our camera trigger (GPIO0).

Is this intended behavior that we lose LOCK when switching from external PCLK to internal CLK?

How can we assure that no spurious signals appear at the GPIO outputs on the SER when switching between clocks?

 

Best regards,

Simon

  • 0
    TI__Mastermind 22900 points

    Hi Simon,

    1. Is the GPIO signal configured and passing through? Is the issue that it's also causing CRC errors or what it's not passing GPIO?

    Are the lock drop issues occurring continuously or when certain signals are sent?

    Could you tell us more about the GPIO behavior? If you probe the GPIO outputs is it as expected? And does it cause lock drops? If you read the CRC errors on register 0xA - 0xB, does it keep increasing?

    2. It is expected to lose lock momentarily if PCLK is changed. The datasheet has Lock time specs for time it takes to lock to incoming signal.

    Best regards,
    Ikram

  • 0 in reply to Ikram Haque
    Prodigy 10 points

    Hi Ikram,

    thank you for your fast response.

    1. GPIOs are configured and passing through. However, back channel communication seems to be unreliable when PCLK is switched from external (camera) to internal CLK. CRC errors in registers 0xA - 0xB are increasing. During unlocked state we masure some short spurious peaks (~18us) on our GPIO outputs on deserializer side. This would fit to maximum frequency of 66kHz for back channel singals.
    We have now implemented a workarround, by blanking this signal on DES side while LOCK is low.

    2. So this ser/des chips only have a valid link when we have a continuous PCLK. Also back channel communication seems to be only reliable when we have a lock on the channel. We didn't find any indication on this behaviour in the datasheet...

    In our application we use a camera in triggered mode to create HDR images. Therefore, we do not have a continuous clock signal from our camera. Exposure times and trigger timing is controlled by an FPGA on DES side.

    Q1:
    We also identified another issue with GPIOs in forward direction. We have an active low signal with pull-up on SER side which is high. On DES side (also with pull-up) we see high level when link is locked and low when link is unlocked. When running from internal clock the signal is always low independent of LOCK status.
    Also OSS_SEL value in register 0x2 does not seem to have an effect on GPIO3 level in unlocked state. It is always pulled LOW.
    On SER side we configured GPIO3 as input / enabled: reg 0x10 = 0x03. On DES side we tried as GPIO and as ROUT3 also with both values of OSS_SEL. It is always pulled low.

    Do you have any more recommendations?

    Q2:
    In another E2E thread we found some information on BCC register 0x27. It seems to be used for echo cancellation. However, there is not more information. Is it used to cancel echo from back channel data on DES side? Is there any indication on scaling factors?
    If we activate CMLOUT debug output with reg 0x3F, can we also observe the influence of BCC value?

    Q3:
    We also stumbled accros general purpose control register 0x23 on DES. We did not find any information on its use case. Could you explain it's use case?

    Best regards,
    Simon

  • 0 in reply to Simon Gerber
    TI__Mastermind 22900 points

    Thank you Simon, please give me 1-2 days to review this and get back to you.

    Best regards,
    Ikram

  • 0 in reply to Ikram Haque
    TI__Mastermind 22900 points

    Hi Simon,

    You are correct, the devices only have have LOCK with valid continuous PCLK, and it needs to have lock to have working bidirectional control channel.

    You could check whether LOCK is stable before doing these transactions to ensure that incorrect data or spurious noise is not captured.


    1. Is GPIO3 not passing the signal when you set the SER as input? Is this GPIO set the same as the other GPIOs but outputting differently?


    2. Is this the E2E you are referring to? https://e2e.ti.com/support/interface-group/interface/f/interface-forum/556553/ds92lx1622-receive-signal-quality

    For general use you can leave it as 0xE0 if you are not seeing errors and CRC errors with LOCK stable when valid PCLK is applied.


    3. The GPCR is just a scratch pad register that refers to internal memory; which isn’t associated with any particular device function or mode. 

    Best regards,
    Ikram