• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 738 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TVP5146M2: Intermittent sync issue after configuration

Doug Brown
Intellectual 320 points
Part Number: TVP5146M2

Hi,

For some reason the forum is forcing me to post in Consumer & Computing Forum instead of Legacy Video Converters, but the instructions say to post anyway.

I'm running into a weird issue where sometimes after configuring the TVP5146M2, it seems to get stuck on an incorrect sync with an NTSC camera. What happens is the output picture just looks like a bunch of rapidly moving black and white horizontal blobs, and register 0x3A (Status 1) reads back as 0x14. That means vertical sync lock = true but horizontal sync lock = false and color subcarrier lock = false. It doesn't seem to be able to recover from this situation on its own. It's like it has mistakenly locked onto something that it shouldn't have locked on for vertical sync, and it's stuck.

In the code I can detect this situation and temporarily set the video standard to SECAM (write 6 to register 0x02) and then back to autoswitch (write 0 to register 0x02), which fixes the problem.

Here is my initialization sequence for the TVP5146M2 (address, value pairs):

{0x03, 0x01},
{0x03, 0x00},

{0x00, 0x00},
{0x01, 0x0F},
{0x02, 0x00},
{0x03, 0x30},
{0x05, 0x10},
{0x06, 0x00},
{0x07, 0x00},
{0x08, 0x02},
{0x09, 0x80},
{0x0A, 0x80},
{0x0B, 0x80},
{0x0C, 0x00},
{0x0D, 0x00},
{0x0E, 0x0E},
{0x10, 0x80},
{0x11, 0x80},
{0x12, 0x80},
{0x14, 0x80},
{0x32, 0x0C},
{0x33, 0x03},
{0x34, 0x11},
{0x35, 0xEE},
{0x36, 0xAF},
{0x37, 0xFF},
{0x38, 0xFF},
{0x39, 0x01},

Any ideas about what might be causing this? It's not a huge deal because I can detect and fix the situation at runtime, but it feels like the chip shouldn't be getting into that state in the first place.

  • 0
    TI__Mastermind 43875 points

    If your camera will always send a specific format then I suggest disabling auto switch and force the video standard to the correct format.

    Noisy and/or slightly non-compliant video sources can cause issues with the sync detection.

    I would also suggest not touching unnecessary registers.

    Why are you setting the following registers...

    {0x03, 0x30},//Setting to 0x30 is invalid. Don't do it. Just leave this register as its default

    Try only write the following registers, leave the rest as their default... I know you write default values, for the other registers, but seems redundant and only partial anyhow.

    {0x02, 0x01},//Force NTSC. You can try omitting this completely to leave the TVP in auto-switch mode

    {0x32, 0x0C},//I assume these sync polarities match your target processor requirements?

    {0x33, 0x03},//I assume these sync polarities match your target processor requirements?

    {0x34, 0x11},//Enable data/clock outputs

    {0x35, 0xEE},//Enable sync output types

    {0x36, 0xAF},//Enable sync output types

    {0x39, 0x01},//Clear lost lock status

  • 0 in reply to Steve Clynes
    Intellectual 320 points

    Hi Steve,

    Thanks. I was using auto-switch so that I could potentially support PAL as well. I can definitely try eliminating extra register writes. Yes, I have confirmed that the sync/clock polarities are correct.

    The reason I'm writing 0x30 to the Operation Mode Control register is to put the H-PLL into "Normal" mode. It says it improves noise immunity and provides a more stable output line frequency. We were having issues with wobbly pictures from certain cameras, and changing that register to 0x30 instead of 0x00 fixed the wobble. I assumed that there is a typo on page 44 of the datasheet, and that 11 for those bits means normal mode (00 is repeated for both adaptive and normal mode, so I'm pretty sure it's a mistake in the datasheet).

    Doug

  • 0 in reply to Doug Brown
    TI__Mastermind 43875 points
    Doug,
    Thanks for the clarification.
    You are probably correct on the 00/11 issue. Unfortunately I can't verify one way or the other at the moment.
    The extra register writes shouldn't be an issue, but wanted to clear away as much as possible to leave only changes, as much for clarification as anything.
    Do you find that your issue occurs with all video sources, or is it only with specific cameras? As a test can you try a signal from something like a DVD player which should output a rock solid signal. This might help determine if there is a system level issue (noise injected on your board, grounding etc...) or if this is more an intolerance to a slightly non-standard signal.

    BR,
    Steve