• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 410 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.

TVP5147 Initialisation Issues on EVM6437

Peter Rose
Prodigy 50 points

Other Parts Discussed in Thread: TVP5146

Hi,

I am having difficulties in initialising the TVP5147M2 device on the EVM board. I am encountering this problem with my own code (based on a DVSDK example) and also with a basic example VPFE_tvp5146_example from SPRAAP3a.

The symptoms are that when issuing the following FVID command:

    result = FVID_control(hGioVpfeCcdc, VPFE_ExtVD_BASE+PSP_VPSS_EXT_VIDEO_DECODER_CONFIG, &tvp5146Params);

with valid parameters there will be a delay of several seconds before the function returns with a result of -10. I understand that this means that the arguments are invalid. However, if I restart the program several times it will eventually work correctly with unchanged code.

On the VPFE_tvp5146_example code it seems to fail to get a response from the tvp5146 device when it first begins to configure it.

EVMDM6437 boards and have the same problem with both of them.

Any suggestions would be gratefully received!

Peter.

  • 0
    TI__Genius 14405 points

    I would suggest you to first try a simple testcase w/o using BIOS as using BIOS will complicate the issue.

    If you are not able to talk to 5147 w/ a simple testcase, I will get TVP team involved. 

  • 0 in reply to Paul.Yin
    Prodigy 50 points

    Thank you Paul.

    I have carried out some more fault-finding and have discovered that the I2C appears not to be working and this is what is causing the TVP configuration to fail. Attempting to write or read to/from any of the I2C peripherals will result in failure. I have used the low level functions to test this eg. EVMDM6437_I2C_write rather than the GIO_Write variant. It appears unaffected by DSP/Bios.

    I noticed a comment in one of the example files which set me thinking: when the demo code reads one of the dip switches there is a loop which it traverses until the result comes back successfully. The comment reads:

    /*
     * ======== read_JP1 ========
     * Read the PAL/NTSC jumper.
     *
     * Retry, as I2C sometimes fails:
     */
    static int read_JP1(void)
    {
        int jp1 = -1;

        while (jp1 == -1) {
          jp1 = EVMDM6437_DIP_get(JP1_JUMPER);
          TSK_sleep(1);
        }
        return(jp1);
    } 

    Does this imply that the I2C is a bit unreliable?

    Many thanks,

    Peter.

  • 0 in reply to Peter Rose
    TI__Genius 14405 points

    I am not familiar with this part of the code, but I don't think it is a DM6437 I2C issue. It might be to do w/ the I2C client DM6437 is trying to access (PCF8574APWRG4). The repeat polling there might have been added in case the I2C client (it is very slow compared to DM6437) is not out of reset yet, might be just being cautious. Instead of a while loop, a for loop time at least times out might be a better candidate.

     

    For more info, see http://c6000.spectrumdigital.com/evmdm6437/reve/files/EVMDM6437_Schematic.pdf

  • 0 in reply to Paul.Yin
    Prodigy 50 points

    Many thanks Paul,

    After spending some time looking at these issues I tried updating to the latest version of DSP/BIOS (5.33.06) and this fixed the problem. In addition it fixed a problem we were experiencing with the system crashing after a short time.

    Thanks again for your help,

    Peter.