Non-Standard Timing Formats on ADV7403

Hello ADI VIdeo Forums,

I am trying to implement a Non-standard timing resolution for the ADV7403 chip on FPGA. I have gotten 1024x768@60 to work and now need to implement 1024x768@30. I have been following this document on how to implement, however, when I write to certain required CP registers, the values do not stick. For example, when I set the PLL DIV Ratio, registers 0x87 and 0x88, sequentially only the first register will actually stick. Any idea this would happen? I do not believe there is anything wrong with the I2C Bus.

Thank you.

PDF

Parents
  • 0
    •  Analog Employees 
    on Aug 10, 2020 12:46 PM 5 months ago

    Hi,

    The below script is for 1024x768@50HZ format.

    Please modify writes in blue to match timing of your 1024x768@30Hz.
    42 05 02 ; Prim_Mode =010b for GR
    42 06 0C ; VID_STD=1100b for 1024x768 _@ 60
    42 1D 47 ; Enable 28MHz Crystal
    42 3A 21 ; set latch clock settings to 010b, Power Down ADC3
    42 3B 80 ; Enable External Bias
    42 3C 5D ; PLL_QPUMP to 101b
    42 6A 00 ; DLL Phase Adjust
    42 6B C2 ; Swap Pr & Pb
    42 73 90 ; Set man_gain
    42 7B 1D ; TURN OFF EAV & SAV CODES Set BLANK_RGB_SEL
    42 85 03 ; Enable DS_OUT
    42 86 0B ; Enable stdi_line_count_mode
    42 87 E4 ; Man set PLL_DIV_RATIO to number of pixels per line
    42 88 F0 ; Man set PLL_DIV_RATIO to number of pixels per line
    42 8F 02 ; FREE_LL = period of line / period of XTAL
    42 90 F8 ; FREE_LL = period of line / period of XTAL
    42 F4 3F ; Max Drive Strength
    42 0E 80 ; ADI Recommended Setting
    42 52 46 ; ADI Recommended Setting
    42 54 00 ; ADI Recommended Setting
    42 0E 00 ; ADI Recommended Setting
    Thanks,
    Poornima
  • Hello ,

    I followed your suggestions on configuring the highlighted blue. I believe the PLL_DIV_RATIO and FREE_LL calculation is correct. 

    PLL_RATIO_DIV = 1256

    FREE_LL = (2.4307e-5)/(37.037e-9) = 656

    For some reason a few register writes did not fully register, as you can see I write the register sequentially. Any clue on the reason?

    Boot Log:

    [ 18.526139] adv7403 1-0021: Write reg x00 val 00
    [ 18.530851] adv7403 1-0021: Write reg x05 val 02
    [ 18.535569] adv7403 1-0021: Write reg x06 val 0c
    [ 18.540299] adv7403 1-0021: Write reg x1d val 47
    [ 18.545018] adv7403 1-0021: Write reg x3a val 21 **
    [ 18.549729] adv7403 1-0021: Write reg x3b val 80
    [ 18.554444] adv7403 1-0021: Write reg x3c val 5d **
    [ 18.559159] adv7403 1-0021: Write reg x6a val 00
    [ 18.563864] adv7403 1-0021: Write reg x6b val 83
    [ 18.568576] adv7403 1-0021: Write reg x73 val 90
    [ 18.573283] adv7403 1-0021: Write reg x7b val 1f
    [ 18.577992] adv7403 1-0021: Write reg x85 val 02
    [ 18.582703] adv7403 1-0021: Write reg x86 val 0b
    [ 18.587419] adv7403 1-0021: Write reg x87 val e4
    [ 18.592135] adv7403 1-0021: Write reg x88 val e8 **
    [ 18.596838] adv7403 1-0021: Write reg x8f val 02 **
    [ 18.601556] adv7403 1-0021: Write reg x90 val 90 **
    [ 18.606264] adv7403 1-0021: Write reg xc3 val 31
    [ 18.610979] adv7403 1-0021: Write reg xc4 val c2 **
    [ 18.615690] adv7403 1-0021: Write reg xf4 val 3f **
    [ 18.620398] adv7403 1-0021: Write reg x0e val 80
    [ 18.625098] adv7403 1-0021: Write reg x52 val 46
    [ 18.629816] adv7403 1-0021: Write reg x54 val 00
    [ 18.634525] adv7403 1-0021: Write reg x0e val 00


    # i2cdump -yf 1 0x21
    0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
    00: 00 00 04 0c 00 02 0c 7f 00 80 00 00 04 7c 00 00 ..??.???.?..?|..
    10: 08 19 00 40 00 00 00 01 00 f1 08 19 08 47 00 10 ??.@...?.????G.?
    20: 08 9d 0c c8 00 9d 04 58 0c 9d 0c e1 0c f3 00 f7 ????.??X??????.?
    30: 00 12 00 84 00 02 00 01 00 c0 00 80 0c 43 00 e0 .?.?.?.?.?.??C.?
    40: 00 01 0c a4 0c b6 00 be 00 00 00 00 00 ef 08 08 .?????.?.....???
    50: 08 24 00 00 00 00 00 08 00 00 00 00 00 00 00 00 ?$.....?........
    60: 00 00 00 00 00 00 00 03 00 00 00 83 00 00 00 00 .......?...?....
    70: 00 00 0c 90 04 01 00 3f 0c ff 0c 1f 00 00 00 00 ..????.??.??....
    80: 00 d0 04 00 0c 02 08 e4 08 08 00 01 08 19 08 80 .??.??????.?????
    90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 89 ...............?
    a0: 00 c0 08 05 0c 01 0c 3f 0c ff 0c 00 00 15 04 d4 .????????.?..???
    b0: 04 a2 08 2b 08 83 00 00 0c 00 00 00 0c 1f 00 0a ???+??..?...??.?
    c0: 00 09 08 31 00 99 00 00 00 04 0c 95 08 00 00 b4 .??1.?...????..?
    d0: 00 10 0c ff 0c 7f 0c 08 0c 08 0c 9b 0c 4c 00 00 .??.?????????L..
    e0: 04 80 00 80 00 25 04 63 04 14 00 55 04 00 00 4a ??.?.%?c??.U?..J
    f0: 04 0c 00 00 0c e0 08 10 00 00 00 40 04 e4 0c 00 ??..????...@???.

    Thank you.

  • Hello ,

    Thank you for the app note, I will review it some more for any deltas with the version I have been referring to.

    Just to make sure I am selecting step 1 correctly, since I am trying to target 1024x768@30Hz, I would set the PRIM_MODE/VID_STD to values 0x5=0x2, 0x6=0xC or 1024x768@60?

    If this is the nearest available standard, I now would like to set the LATCH_CLK, PLL_DIV_RATIO, and FR_LL.

    When writing to LATCH_CLOCK register (0x3a), the desired value (0x11) does not want to stick, and the value that I am reading back (0x00) does not even exist on the datasheet. 

    So my main concern is not my calculated values, and I understand the steps needed to support non standard video formats. I just am not fully understanding why the values I am writing to are not fully registering as if they are locked from user space. Any more suggestions would be helpful.

    Thank you.

  • Hello ,

    It turns out I was conflicting I2C addresses with the ADV7403 chip, and was the reason for some registers to not work and have strange values when reading back. I was able to resolve this writing register issue, except for the FR_LL[10:0] register (0x8F,0x90). The values I am writing do not register. Any clue as to why?

    Thank you.

  • 0
    •  Analog Employees 
    on Aug 12, 2020 10:28 AM 5 months ago in reply to kernelpanic

    Hi,

     Please let us know whether you are facing the same writing issue with other video formats too?

     Also have you tried with other lower frame rate format like 1024 x 768 at 43 Hz (interlaced), These timing details are provided in VESA document.

    Thanks,

    Poornima

  • Hello ,

    It is occuring to be all video formats. According to the data sheet, the registers 0x8F and 0x90 are write only. Is that a reason why we aren't able to readback the last value written?

    I would like to try that 1024x768 at 43Hz resolution, can you point me to which VESA document you are referring to?

    Following these writes, I am still not able to lock onto the 1024x768@30Hz video stream so the CP is stuck in free run mode. 

    Thank you

  • +1
    •  Analog Employees 
    on Aug 14, 2020 11:33 AM 5 months ago in reply to kernelpanic

    Hi,

    1.According to the data sheet, the registers 0x8F and 0x90 are write only. Is that a reason why we aren't able to readback the last value written?

       Yes, the register locations where FR_LL[10:8] and FR_LL[7:0] reside are WRITE_ONLY.
       The FR_LL[10:0] parameter has no effect on the video decoding.

    2.Following these writes, I am still not able to lock onto the 1024x768@30Hz video stream so the CP is stuck in free run mode. 

        Timing information for 1024x768@30Hz missing somewhere in your side, thtsy it could not able to lock

    Note: FR_LL is only for free rum mode configuration.The CP uses the line length measurement to decide when to go into free-run state. And also CP uses VID_STD to determine the expected line length.

    To configure the CP for nonstandard video, the FR_LL[11:0] must be set manually.CP must be manually programmed to expect a different line length for non standard formats.
    To calculate the FR_LL[11:0] manual parameter, the line period is divided by the 27 MHz clock
    period (refer to Equation 2). The numerator in this equation can be calculated directly from the
    Hysnc period, or by using the total number of luma pixel periods per line multiplied by the pixel
    clock period.

       FR_LL[11:0] = Tline / T27Mhz.

    3.I would like to try that 1024x768 at 43Hz resolution, can you point me to which VESA document you are referring to?

       I am referring this vesa_dmt_1.12 document

    Thanks,

    Poornima

Reply
  • +1
    •  Analog Employees 
    on Aug 14, 2020 11:33 AM 5 months ago in reply to kernelpanic

    Hi,

    1.According to the data sheet, the registers 0x8F and 0x90 are write only. Is that a reason why we aren't able to readback the last value written?

       Yes, the register locations where FR_LL[10:8] and FR_LL[7:0] reside are WRITE_ONLY.
       The FR_LL[10:0] parameter has no effect on the video decoding.

    2.Following these writes, I am still not able to lock onto the 1024x768@30Hz video stream so the CP is stuck in free run mode. 

        Timing information for 1024x768@30Hz missing somewhere in your side, thtsy it could not able to lock

    Note: FR_LL is only for free rum mode configuration.The CP uses the line length measurement to decide when to go into free-run state. And also CP uses VID_STD to determine the expected line length.

    To configure the CP for nonstandard video, the FR_LL[11:0] must be set manually.CP must be manually programmed to expect a different line length for non standard formats.
    To calculate the FR_LL[11:0] manual parameter, the line period is divided by the 27 MHz clock
    period (refer to Equation 2). The numerator in this equation can be calculated directly from the
    Hysnc period, or by using the total number of luma pixel periods per line multiplied by the pixel
    clock period.

       FR_LL[11:0] = Tline / T27Mhz.

    3.I would like to try that 1024x768 at 43Hz resolution, can you point me to which VESA document you are referring to?

       I am referring this vesa_dmt_1.12 document

    Thanks,

    Poornima

Children
No Data