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.

  • Answer Suggested

TVP5158: Video artifacts at temperatures below -30 degrees Celsius

Part Number: TVP5158

Hi All,

We have an issue with the TVP5158 in our custom CCA design. When the temperature dips below -30 degrees Celsius we start seeing line artifacts on the video. I've attached a couple of examples.

We've verified that the reset sequence is being followed and we are applying the 2.3.2 patch just in case. The issue has been narrowed down to the decoder by verifying the input signals look good at the pin. And the output looks good if the blue loss of sync test pattern is being applied. Only when it starts processing input video do we see the artifacts (including a blue test pattern from a generator).

The issue won't go away unless we reset the chip or power cycle the board. Even if we bring the temperature back up, the video still shows the corruption. We've also seen this on multiple boards, so we're pretty sure it's not just a one off part or PWB issue.

Along with the patch, we modify the following registers to configure the part to our use case.
NAME, REGISTER, VALUE
TVP5158_DECODER_WREN, 0xFE, 0x0F
TVP5158_AVD_OUT_CTRL_1, 0xB0, 0x60
TVP5158_AVD_OUT_CTRL_2, 0xB1, 0x17
TVP5158_POWER_CTRL, 0x1A, 0xF0
TVP5158_OUTPUT_FORM_CTRL_1, 0xA8, 0x04
TVP5158_OUTPUT_FORM_CTRL_2, 0xA9, 0x44
TVP5158_BLUE_SC_Y_CTRL, 0x90, 0x29
TVP5158_BLUE_SC_CB_CTRL, 0x91, 0xF0
TVP5158_BLUE_SC_CR_CTRL, 0x92, 0x6E
TVP5158_OFM_MODE_CTRL, 0xB2, 0x25
TVP5158_BRIGHTNESS_CONTRAST_RANGE, 0x12, 0x13

I'm hoping that only a simple register tweak is all we need to fix this!

Thanks for your help in advance!

Jason

  • Are you using the industrial temp range variant of the TVP?

    The blue screen test is a great test, but can you please extend a little on the test by setting the luma and chroma values such that there are forced transitions on each bit, i.e. luma = 0, chroma = 255, then luma = 255, chroma = 0, and other single bit transitions, e.g. luma = 192, chroma = 64 so the msb toggles. I just want to make sure that this isn't a system level issue with transitioning bits.

    BR,

    Steve

  • In reply to Steve Clynes:

    Hi Steve,

    Sorry for not replying in a timely manner. My company switched e-mails so I didn't get the notification!

    We are still investigating the issue. We are using the industrial temp range variant of the part. I'll post the video of the luma / chroma results as soon as I get it.

    There are a couple of new observations we've made.

    1) If all 4 inputs are fed by the same source (using a buffered splitter), then the issue is much worse and more frequent.

    2) On our board, the Analog Power (1.1V, and 3.3V) and Digital Power (1.1V & 3.3V) are tied to the same power supply. We did this because the datasheet provided the same tolerance for each and didn’t specify tighter/cleaner requirements on VDDA. Could this potentially be causing an issue with the initialization of the analog circuitry? Our PDN for 3.3V and 1.1V meets the requirements from the datasheet, but perhaps the high frequency events are causing ADC or PLL issues?

    We noticed that one of the dev kits we had used previously that VDDA & VDD were isolated by ferrite beads and the separate power islands had their own decoupling. Can you provide details on how the VDDA rails are used internally?

    Please let me know if you have any questions! Thanks for your help!

    Jason

  • In reply to Jason Chapman16:

    It is always better to filter analog supplies, but I don't think this is the issue here. The tolerance is not the issue with the analog supplies, but noise injection. Any noise on the digital supplies will potentially feed through into the analog domains.

    Looking more closely at the second image above you can see the big image shift. This implies to me that the real issue is timing, possibly setup/hold violations feeding the digital data to your down-stream processor.

    Can you capture an eye diagram of the clock vs each digital data-pin at your target processor in turn and make sure that there is sufficient setup and hold margin per the target requirements?

    BR,

    Steve

  • In reply to Steve Clynes:

    Hi Steve,

    Thanks for the quick response! We'll get to work on the eye diagrams.

    I'm still a little confused as to how this would explain some of the original observations:

    1) The internally generated blue loss of sync test pattern looks fine, yet the same color blue from an external pattern generator would look bad.
    2) Being in pixel interleaved mode I'd expect all the channels to be equally as bad. We're seeing the behavior mostly on a single channel out of the 4.
    3) Warming the board up to room temperature doesn't fix the issue unless we reset the chip.

    Thanks again!

    Jason
  • In reply to Jason Chapman16:

    Jason,
    I wasn't sure what more you are using or how the TVP is configured, so just guessing at possibilities. The large shift could be caused by the target getting out of sync with the TVP and one possibility would be setup/hold violations.

    Regarding pixel interleaved, each channel will have its own sync codes embedded so if the receiving device does not re-sync every line then it could be caused by a receiving channel getting out of sync due to a momentary glitch in the sync codes.

    Re-warming up, again, if the receiving processor does not continually sync to the digital video stream then once out of step it would remain that way.

    We have seen many processors assume that once they have locked to the video that there is a fixed frame size and never re-sync. This is bad since the source is an analog stream and the video could go in and out of lock causing jumps in the number of lines sent and/or the line length whilst the TVP re-locks.

    Not saying this IS the issue, but setup/hold needs to be verified anyhow for general system stability.

    Is it possible for you to reset the target processor without power cycling the TVP or force the target to try to re-start looking for the video?

    BR,
    Steve
  • In reply to Steve Clynes:

    Hi Steve,

    We only modify the settings as per the first post. So not a lot changes were made to the default settings. These being the ones I could see causing trouble:

    AVD_OUT_CTRL_1 = 0x60

    AVD_OUT_CTRL_2 = 0x17

    POWER_CTRL = 0xF0

    OUTPUT_FORM_CTRL_1 = 0x04

    OUTPUT_FORM_CTRL_2 = 0x44

    OFM_MODE_CTRL = 0x25

    We were able to reset the target device during the failure state (video attached this time) without changing the TVP or its settings. It still kept failing in the same manner after a number of resets. I've attached the register dump from all 4 cores in the 5158. One failed for channel 2 and the other for channel 4. I did a diff of them and there were no obvious differences in the registers.

    We're getting a board moded up with jumpers to try and capture the eye. It's a little difficult as most of the design is blind and buried vias. Hopefully have some results soon.

    The next test I'm trying to do is experiment with some of the individual core settings in the TVP. See if there is a way make it worse or cause any change.

    Thanks!

    Jason

    tvp5158_cahnnel_4_fail.txttvp5158_channel_2_fail.txt

  • In reply to Jason Chapman16:

    Jason,

    This video clip doesn't seem to have the image slip that the above picture shows. Not sure if this is telling us anything or not to be honest.

    In the video clip you can see a rolling artifact. Was the same video signal being fed to all analog inputs or were they different? Does the rolling occur if the same video is fed to all channels. (just information gathering)

    For the forced blue screen test you did earlier I assume you only forced one channel to blue screen and left the remaining channels enabled?

    BR,

    Steve

  • In reply to Steve Clynes:

    Hi Steve,

    You're correct, the image slip only occurs randomly. Haven't really noticed a pattern as of yet.

    In the case of the video we were sending all the same pattern on all 4 inputs. From the same pattern generator and through a buffered splitter.

    I believe that the earlier blue test pattern behavior for loss of sync was on all channels, not just the failing one. Never occurred to me to just pull the one input, as I was toggling at the source instead of the buffer. I'll redo the test with just the single input being pulled.

    Thanks again!

    Jason
  • In reply to Jason Chapman16:

    Hi Steve,

    We repeated the failure with removing only the misbehaving source and leaving the others active. I was surprised to see the failure still occurring on the blue loss of sync pattern (attached). We're working on some SI simulations to see if there's an issue on the receiving end of our FPGA. And we're also having one of the cards moded up to try and filter the input rails.

    We're still a little perplexed as to why only 1 channel of the 4 interleaved gets into that state. Are there any other documents from TI that describe how the timing of the interleaved output is derived? i.e. whether individual channels could have different timing behavior.

    Thanks again!

    Jason

  • In reply to Jason Chapman16:

    Jason,

    If you have access to the clock signal trace between the TVP and your FPGA you could try loading it slightly. (I call it the finger test). Try touching the pin or exposed trace, adding a little capacitance. If this has ANY effect on the displayed image (makes it worse or makes it better, or even just changes anything at all) then you most likely have a timing violation.

    I can't comment why it seems to only affect one channel since there are many factors which feed into correctly decoding the data correctly.

    The fact that you see this on the blue screen makes me think that it isn't anything to do with the analog front end, so I don't think filtering the analog supplies will have any effect.

    BR,

    Steve

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.