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.
Part Number: TVP5158
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, VALUETVP5158_DECODER_WREN, 0xFE, 0x0FTVP5158_AVD_OUT_CTRL_1, 0xB0, 0x60TVP5158_AVD_OUT_CTRL_2, 0xB1, 0x17TVP5158_POWER_CTRL, 0x1A, 0xF0TVP5158_OUTPUT_FORM_CTRL_1, 0xA8, 0x04TVP5158_OUTPUT_FORM_CTRL_2, 0xA9, 0x44TVP5158_BLUE_SC_Y_CTRL, 0x90, 0x29TVP5158_BLUE_SC_CB_CTRL, 0x91, 0xF0TVP5158_BLUE_SC_CR_CTRL, 0x92, 0x6ETVP5158_OFM_MODE_CTRL, 0xB2, 0x25TVP5158_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!
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.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Steve Clynes:
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!
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?
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.
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?
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.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.