NHD-3.5-640480EF-MSXP (Rev1A) never accepts LPDT init

Sieun Ko

We are driving the NHD-3.5-640480EF-MSXP (Rev1A, FL7703NI) from a Toshiba TC9594 RGB-to-DSI bridge (4-lane, Linux). The panel never accepts initialization on two units: VOUT/HOUT never assert, the screen stays dark (backlight works). Before posting, we verified every documented requirement directly at the panel FFC pins with a scope and multimeter. Summary below.

What we measured at the panel pins — all within spec:

  • Escape-mode entry ladder (pins 13/14, decoded from capture):
    LP-11 → LP-10 (215 ns) → LP-00 (215 ns) → LP-01 (210 ns) → LP-00 (215 ns) → LPDT (0x87)
    Every state is more than 4× the 50 ns TLPX requirement in your datasheet.
  • Packet integrity: a fixed test long-packet captured at the pins decodes bit-perfect including ECC and CRC (22/22 bytes).
  • Init sequence: byte-identical to your official example code — SETEXTC F1 12 87, SETMIPI 0x33 (4-lane), full GIP (E9/EA), Sleep-Out + 250 ms, Display-On.
  • Static pin conditions: VDD = 3.3 V · RESX high = 2.7 V · T_IM = IM0 = LANSEL = 0 V · IM1 = 3.3 V (MIPI DSI mode, default lane mapping) · CSX/DCX/SCL/SDA = No Connect per your datasheet.
  • Reset timing: RESX low through power-up → released → 150 ms before the first command.
  • Also tried: 2-lane (SETMIPI 0x31 + matching host), HS-mode commands, continuous and non-continuous DSI clock, pixel clock 31.2 MHz (your recommended value) and 15.6 MHz.

Questions:

1. Given the measurements above, what additional condition does the FL7703NI require to accept LPDT commands? Is there any known sensitivity in escape-entry/LPDT recognition beyond TLPX ≥ 50 ns?

2. Is there a panel-side way to confirm command reception without a DSI read (our bridge is write-only)? For example, any pin or internal state that changes when SETEXTC is accepted?

3. Could this be lot-related? Both of our units carry the identical marking:
NEWHAVEN DISPLAY, S02512-7448-2604, NHD3.5-640480EF-MSXP_Rev1A
Since they are from the same lot, our two-unit test does not exclude a lot-level issue. Are there known anomalies for this lot, and would testing a unit from a different lot be worthwhile?

4. Your forum mentions expected panel IDs 38 / 21 / 1F — does this apply to Rev1A as well?

0

Comments

5 comments

Date Votes
  • Engineering Support
    Community moderator

    Hi Sieun,

    I can answer your questions below:

    1. Given the measurements above, what additional condition does the FL7703NI require to accept LPDT commands? Is there any known sensitivity in escape-entry/LPDT recognition beyond TLPX ≥ 50 ns?

    Based on your provided setup, the LPDT commands should work. There shouldn't also be any issues when the TLPX is greater than 50 ns. Per the spec, any value greater than 50 ns should work.

    2. Is there a panel-side way to confirm command reception without a DSI read (our bridge is write-only)? For example, any pin or internal state that changes when SETEXTC is accepted?

    There is a command for all pixels on:

    If you just want a sanity check if the display is receiving commands properly, then this command should work.

    3. Could this be lot-related? Both of our units carry the identical marking:
    NEWHAVEN DISPLAY, S02512-7448-2604, NHD3.5-640480EF-MSXP_Rev1A
    Since they are from the same lot, our two-unit test does not exclude a lot-level issue. Are there known anomalies for this lot, and would testing a unit from a different lot be worthwhile?

    Could you please send a picture of the back of the display with these markings visible? I can check our system to verify if there were issues with this lot.

    4. Your forum mentions expected panel IDs 38 / 21 / 1F — does this apply to Rev1A as well?

    The display should still have the expected default IDs. Per the IC datasheet:

     

    Based on the information you provided above, I would suggest checking the interface pins to see if the MIPI lane order and polarity are matching the MIPI lanes on your driver. I would also suggest changing IM0 = HIGH to see if its not a polarity issue.

    0
  • Sieun Ko

    Picture of the back of the display : 

    0
  • Engineering Support
    Community moderator

    Hi Sieun,

    Thank you for providing the photo. I checked the lot code and I couldn't find any documented issues. This is most likely an initialization problem.

    Did the changes I suggested have any effect on what you are seeing with the display?

    0
  • Sieun Ko

    Good news — the display is now working.

    Following your suggestion to re-check the lane order and polarity, our hardware engineer redid the wiring between the board and the panel, and the display came up right after that — no software changes were needed. So it appears there was a mistake somewhere in our original wiring, although we haven't pinpointed the exact spot.

    We now have a clean, stable picture on both panels, and good to know the lot has no documented issues.

    Thank you for the support — consider this resolved.

     

    0
  • Engineering Support
    Community moderator

    Hi Sieun,

    That's great to hear! If you have any more questions or concerns regarding our displays, feel free to reach out again.

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post