Problem with black and white camera and DM355 Demo Apps(capture)

This certainly sounds like an issue atthe TVP5146 stage.  The demos by default run in BT.656 mode (BT.656 is video standard that uses YCbCr 422 video data);  The YCbCr data can be color or black and white; the DM355 really does not check the data, it simply copies incoming BT.656 video data to DDR2.

Does the composite signal you are feeding to the board (from your camera source) adhere to any video standard in particular? 

Though I could not say exactly what is going on with this, I can maybe point you in the right direction. I think the code snippet that would be of interest in this case is the gettvp5146std function within \lsp\ti-davinci\drivers\media\video\davinci\tvp5146.c which is what ultimately results from the VIDIOC_QUERYSTD IOCTL. The main reason I could see this function call failing is if the TVP5146 was reporting a lack of a lock on the incoming signal, this includes the color subcarrier lock (!). Essentially it is reading the I2C register 0x3A shown in section 2.11.42 of the TVP5146 datasheet, and verifying that color subcarrier lock, vertical sync lock, and horizontal sync lock are set. My suspicion is that the TVP5146 is working properly, but since there is no color you are never getting a color subcarrier lock and the driver is throwing back this error when the TVP5146 is queried.

As a first step to debug this I would modify the driver to print out some of the values it is getting back from the TVP5146, in particular the 0x3A status register, to see what is locking and what is not.

If it is only the color subcarrier that is missing, you may try modifying the driver to ignore the color subcarrier bit to see if you can capture the black and white stream (note I have not looked at all the driver to verify this is the only place it is checked, so there may be more to this).

Hi Bernie,

after a post on the Video Converters forum about this same issue I implemented both the suggestions being to force the Autoswitch mask register in the TVP5146 to use PAL and to set the Video Standard Register to PAL but I still get what you describe.  On my debug output I see first round that TVP5146 indicates lost color subcarrier (register 3Ah = 0x66) but on second fly-by it looses the vertical and horizontal link and driver returns with lost detect and fails(reg_3Ah=0x70).  The input is from a Philips PM5514V video pattern generator where it work fine in color mode but when I set it to remove chroma I get these errors.  Any suggestions what to change in the driver or would it be ok to change the driver not to return the error but I would have assumed that it would only loose the color lock and not the other before I hack it not to return the Lost Lock detect in order to carry on.  What is also strange is that debug indicates "i2c_adapter i2c-0: tvp514x_setinput:lost lock]" at the point it returns the Status1 (3Ah) register with a value of 0x70.  Could it be that it shuts down and the i2c is also lost at this point?  I have added extra debug printouts in order to see how ioctl level interfaces with the tvp5146 low level and this makes sense but the i2c that goes of track I can't explain.  Any suggestions?  I am running encodedecode demo on EVMDM365 with DVSDK_2_10_01_18 and the app will use Pulnix B&W cameras.

Thanks, Jinh T.

Jinh said:

On my debug output I see first round that TVP5146 indicates lost color subcarrier (register 3Ah = 0x66) but on second fly-by it looses the vertical and horizontal link and driver returns with lost detect and fails(reg_3Ah=0x70).  The input is from a Philips PM5514V video pattern generator where it work fine in color mode but when I set it to remove chroma I get these errors.  Any suggestions what to change in the driver or would it be ok to change the driver not to return the error but I would have assumed that it would only loose the color lock and not the other before I hack it not to return the Lost Lock detect in order to carry on.

This is unusual, I would not expect it to be losing the horizontal and vertical locks, just the color lock, this is something you may have to bring up with the video decoder forum folks you have been posting with.

Jinh said:

What is also strange is that debug indicates "i2c_adapter i2c-0: tvp514x_setinput:lost lock]" at the point it returns the Status1 (3Ah) register with a value of 0x70.  Could it be that it shuts down and the i2c is also lost at this point?

The lost lock here does not refer to the i2c, this is showing that the lost lock detect bit (bit 4) of the status1 register (offset 3Ah) was set, seeing this message actually means the I2C is still working.

#define TVP514X_STATUS1                        (0x3A)
#define TVP514X_LOST_LOCK_MASK                    (0x10)

tvp514x.c said:

    /* wait here so that if lock is lost, it can be detected */
    mdelay(500);
    err |= tvp514x_i2c_read_reg(&tvp514x_channel_info[ch_id].i2c_dev.
                    client, TVP514X_STATUS1, &status);
    if (err < 0) {
        dev_err(tvp514x_i2c_dev[ch_id], "tvp514x_setinput:error "
            "reading status register\n");
        return -EINVAL;
    }
    if (TVP514X_LOST_LOCK_MASK == (status & TVP514X_LOST_LOCK_MASK)) {
        dev_err(tvp514x_i2c_dev[ch_id],
            "tvp514x_setinput:lost lock]\n");
        return -EINVAL;

I found the setting to configure the board to pick up black and white video:

Change lock_mask from 0x0E to 0x06 in dm365_tvp514x_evm_chan_config in file video_davinci_evm.c.  There is no need to change autoswitch mask or video standard register.

Thanks to all for input, Jinh T.