TFP410: No video on external HDMI monitor

Prodigy 220 points

Replies: 8

Views: 131

Part Number: TFP410

This is an extension to the project found in this thread:

https://e2e.ti.com/support/interface/f/138/p/851103/3151025#3151025

You can find my schematic and code in the above link.

The issue I am having now is that there is no video output to my HDMI monitor. When I plug and unplug my HDMI cable the monitor responds with a message saying "No HDMI Signal", which only appears when the cable is connected or removed. Thus I believe my HPD is working properly - it is at least detecting that it is being plugged in. 

I.K. in the above thread suggested it may be a problem with my DE signal, which I am generating with my code. Based on the provided schematic and C files, is it possible to determine what the cause of this "No Signal" error is?

A bit of background: I am modifying an old existing design to produce an HDMI output. The original design used 8-bit R, G, and B signals which were fed into an Analog Devices ADV7125 chip, which produced an 800x480 VGA output. I replaced the ADV7125 with the TFP410 since it could also accept 8-bit R, G, and B signals as inputs, but produced an HDMI output instead of VGA (my newer monitors don't have a VGA port). The DE values, along with the other specs, are based on the VGA device and I am not entirely sure whether or not they need to change when switching to an HDMI transmitter.

Thank you,
Isaiah Washburn

8 Replies

  • Hi Isaiah,

    Can you check the below items? 

    1. Do you see the input/output clock on an oscilloscope? Is it the correct frequency/amplitude?

    2. Do the HYSNC/VSYNC signals look correct? I would ask about DE too but I'm not sure if you would be able to look at this signal since it's internally generated.

    3. Can you review section 7.4.3 of the datasheet in regards to HTPLG, MSEN, and RSEN?

    4. What is the state of the PD# bit in the CTL_1_MODE register?

    5. The TFP410 requires a reset after power up. Instead of pulling ISEL/RST#, can you tie it to your system reset (see section 7.4.4)?

    Regards,

    I.K.    

  • In reply to I.K. Anyiam:

    Hello I.K.,

    I.K. Anyiam

    1. Do you see the input/output clock on an oscilloscope? Is it the correct frequency/amplitude?

    The input clock is measuring 40MHz, as expected (channel 1, yellow). The output TMDS CLK+ is a very ripply 3.3V (channel 2, green).

    2. Do the HYSNC/VSYNC signals look correct? I would ask about DE too but I'm not sure if you would be able to look at this signal since it's internally generated.

    HSYNC and VSYNC look correct. HSYNC is measuring 37.88kHz and VSYNC is measuring 60.12Hz, which is consistent with the 800x600p driver (implemented with a FPGA).

    3. Can you review section 7.4.3 of the datasheet in regards to HTPLG, MSEN, and RSEN?

    According to section 7.4.3:

    "When I2C is enabled, the connection status of the DVI link and HTPLG sense pins are provided by the CTL_2_MODE register"

    My HTPLG (HPD) pin is connected directly to Pin #19 of the HDMI connector. MSEN is pulled high through a 4.53k resistor, and outputs the HTPLG bit in the firmware (lines 49 and 50 in main.c - ignore the comment saying it's disabled, that is not accurate). I'm not exactly sure what I should be doing with these pins/bits/values.

    4. What is the state of the PD# bit in the CTL_1_MODE register?

    PD# is set to 1 (Normal operation) in lines 46 and 47 of main.c.

    5. The TFP410 requires a reset after power up. Instead of pulling ISEL/RST#, can you tie it to your system reset (see section 7.4.4)?

    Unfortunately I do not have a system reset. Currently the micro switches on at the same time as the TFP410 (which is the same time the rest of the board powers up), and ISEL is simply connected to Vdd. Are you saying that this won't work properly? Do I need to cut the trace connecting ISEL to the supply (if I can even get to it) and connect it to one of the I/O pins on the micro instead, so that I can enable/disable it in firmware?

    Thank you,
    Isaiah Washburn

  • In reply to Isaiah Washburn:

    Hi Isaiah,

    Yes, please find a way to control ISEL. The TFP410 requires a reset after power up, so ISEL should be asserted high only after the power supplies are stable. 

    I remember another customer had a similar issue (no/bad video on the display intermittently), and they were also using the I2C to access the DE generator. Their ISEL pin was just connected to Vdd, but when they connected it to their system reset instead it fixed the issue.

    Can you also provide a register dump of the TFP410 so we can check if everything's being written correctly?

    Regards,

    I.K. 

  • In reply to I.K. Anyiam:

    I.K. Anyiam

    Hi Isaiah,

    Yes, please find a way to control ISEL. The TFP410 requires a reset after power up, so ISEL should be asserted high only after the power supplies are stable. 

    I remember another customer had a similar issue (no/bad video on the display intermittently), and they were also using the I2C to access the DE generator. Their ISEL pin was just connected to Vdd, but when they connected it to their system reset instead it fixed the issue.

    Can you also provide a register dump of the TFP410 so we can check if everything's being written correctly?

    Regards,

    I.K. 

    Hello I.K., thank you for your patience. I have been on vacation and just got back to this.

    I lifted the ISEL pin of the TFP410 and soldered a jumper wire onto it, which I then brought over to P1.2 of my MSP430G2230. I added in the following code:

    	// Configure I2C enable (ISEL) output
    	P1SEL |= BIT2;									// Select P1.2 to be I/O
    	P1DIR |= BIT2;									// Set P1.2 to output
    	P1OUT |= BIT2;									// Set P1.2 high
    
    	// Wait a bit for the power supplies to settle
    	__delay_cycles(50000);
    
    	// Reset I2C configuration registers
    	P1OUT &= ~BIT2;									// Disable I2C
    	__delay_cycles(10000);							        // Delay 10ms
    	P1OUT |= BIT2;									// Re-enable I2C
    
    	I2C_Init();										// Initialize I2C pins

    I added this code right before my I2C_init() function, after configuring the MSP430 clocks. I wasn't sure what to use for delays, so I guessed - 50ms to allow the power supplies to settle, and 10ms before re-enabling the I2C. Unfortunately this does not appear to have worked.

    You suggested I post a register dump of the TFP410. Would you be able to tell me how to do that? 

    Thank you,

    Isaiah W.

  • In reply to Isaiah Washburn:

    Hi Isaiah,

    For the register dump you'd just need to read back all of the TFP410 registers in the register map. 

    Also, taking another look at your clock waveforms, it looks like the input clock is around 6V in amplitude, which is over the absolute maximum rating listed in the datasheet. Can you reduce the amplitude to 3.3V so that it's within DC specifications? 

    Below are some additional items to check:

    1. Do you have access to the receiver in your monitors? If so can you look at the DE, HSYNC, VSYNC, and clock output of the receiver? We can see that these are available to the TFP410 on the input but they may not be getting transmitted to the receiver. 

    2. Can you check if there's any activity on the output TMDS data lanes of the TFP410? It looks like the output clock is pulled to 3.3V due to the termination on the receiver side, but it doesn't look like it's actually outputting a clock.

    Regards,

    I.K. 

  • In reply to I.K. Anyiam:

    I.K. Anyiam
    For the register dump you'd just need to read back all of the TFP410 registers in the register map.

    Oh of course, I should have known that. I'll give that a shot tomorrow, assuming I have time to work on this project.

    Also, taking another look at your clock waveforms, it looks like the input clock is around 6V in amplitude, which is over the absolute maximum rating listed in the datasheet. Can you reduce the amplitude to 3.3V so that it's within DC specifications?

    Good catch, I didn't even notice that! I just checked my schematic and I appear to be missing a 75 ohm resistor on the clock line that I imagine would have eliminated those peaks. You can see in the image the level at which the clock waveform is supposed to be. There are just large peaks before that level is reached. I will have to see if I can mod the existing board to put it in.

    Below are some additional items to check:

    1. Do you have access to the receiver in your monitors? If so can you look at the DE, HSYNC, VSYNC, and clock output of the receiver? We can see that these are available to the TFP410 on the input but they may not be getting transmitted to the receiver.

    Not that I am aware of, but I will have to dig into this once the existing, known issues have been corrected.

    2. Can you check if there's any activity on the output TMDS data lanes of the TFP410? It looks like the output clock is pulled to 3.3V due to the termination on the receiver side, but it doesn't look like it's actually outputting a clock.

    That was my instinct as well. Once again I can probe these pins once the known problems have been fixed.

    I will get back to you with additional information as soon as I get it.

    Thank you,
    Isaiah W.

  • In reply to Isaiah Washburn:

    Good day,

    I finally got to finish this round of testing this evening, so here are my results.

    I was able to cut a trace, scrape the solder mask off of both sides, and solder in a 100 ohm resistor between the FPGA output and the TFP410 clock input pin. I would have used 75 ohms but did not have any resistors with that value handy. This cleaned up the clock signal substantially:

    My next step was to read back the I2C registers after (supposedly) writing to them. The write of one of the registers is shown below - all appears to be in order:

    To read back the data, I added the following line of code just below the I2C_WriteData() call and the subsequent 1ms delay:

    I2C_ReadData(Buff, SLV_ADDR, CTL_2_MODE, 1);
    

    Unfortunately, the results do not look good:

    As you can see, it is reading back 0x00 when it should be reading back 0x39. Below is my I2C_ReadData() function contents:

    /*--------------------------------------------------------------------------------
    Function    : I2C_ReadData
    Purpose     : Read n bytes from I2C bus
    Parameters  : Buff          - Pointer to buffer for storing value
                  DevideAddr    - Device Address
                  Register      - Register Address
                  nLength       - Number of bytes to be read
    Return      : None
    --------------------------------------------------------------------------------*/
    void I2C_ReadData(unsigned char *Buff, unsigned char DeviceAddr, unsigned char Register, unsigned char nLength)
    {
        unsigned char nIndex;
        I2C_Start();
        I2C_WriteByte(DeviceAddr << 1);
        I2C_WriteByte(Register);
        I2C_Stop();
        _NOP();                                 // Short delay
        I2C_Start();
        _NOP();                                 // Short delay
        I2C_WriteByte((DeviceAddr << 1) | 1);
        for(nIndex = 0; nIndex < nLength; nIndex++)
        {
            *(Buff + nIndex) = I2C_ReadByte();
                if(nIndex > 0)I2C_Writebit(ACK);
        }
        I2C_Writebit(NACK);
        I2C_Stop();
    }

    I tried increasing the delays after I2C_Stop() and I2C_Start() but that did not seem to have any effect. Since I am apparently not properly configuring the registers, I suspect that is why I am not seeing any clock on the TMDS side of things. 

    I do not seem to have access to the receivers in the monitors, unfortunately. 

    What might cause the config data to not be properly written to the TFP410, even though I am still receiving ACKs?

    Thank you,
    Isaiah W.

  • In reply to Isaiah Washburn:

    Hm that’s interesting. It seems like your write/read process are correct, so I’m not sure what could be causing this other than the register somehow getting reset before you read it (the default is 0x00).

    I’ll see if I can recreate this in the lab.

    Regards,

    I.K.