STM32F469NI and NT35510 trying to determine LTDC parameters for custom LCD

[JSime.1]

I have a situation with a custom LCD that has the NT35510 chip, within the image titled NT35510-Custom_LCD you will see static at the bottom of the screen, in the image NT35510-DISCO_LCD this is the screen for the STM32F469I-DISCO board that has the NT35510 and the are running the same code. The difference between the custom LCD and the DISCO LCD comes down to glass, touch panel.

The initial code I am using for this build has been taken from the STM32F469I example called LCD_DSI_CmdMode_TearingEffect_ExtPin because it had NT35510 set up code and I merged with with the STM32F469I-DISCO TouchGFX Designer generated project, I am still using the OTM8009A LTDC values as it work on the NT35510-DISCO LCD however I have framing issues on the custom LCD which I believe is attributed to the LTDC parameters related to the VSYNC, HSYNC, HBP, VBP, etc.

Parameters I am currently using:

• Vertical Sync: 1
• Vertical Back Porch: 1
• Vertical Front Porch: 1
• Vertical Active: 480
• Horizontal Sync: 1
• Horizontal Back Porch: 1
• Horizontal Front Porch: 1
• Horizontal Active: 200

How would I go about finding the needed parameters for the custom LCD to solve the framing issue?

[Tesla DeLorean]

>>How would I go about finding the needed parameters for the custom LCD to solve the framing issue?

Ask the vendor for a data sheet or specification?

No one here has any clue about what you've actual bought and from whom.

200 x 480 ?

Pixel clock likely needs to reflect the refresh rate and line totals.

[JSime.1]

>> Ask the vendor for a data sheet or specification?

>> No one here has any clue about what you've actual bought and from whom.

Yeah fair, I am still waiting on their response.

>> 200 x 480 ?

The values were generated from when the project was created (STM32F469I-DISCO in TouchGFX Designer), I can't give you a reason as to why those are the values are that but it works so I haven't changed it; I can't show the true graphics on the screen due to NDA but on the OTM8009A custom LCD it works and currently trying to move the project to the next hardware NT35510 custom LCDs due to EOL components.

>> Pixel clock likely needs to reflect the refresh rate and line totals.

Cheers, I'll look into that.

[JSime.1]

This was meant to be a reply to /Tesla DeLorean, could not deleted this comment.

[JSime.1]

Solution:

Since this project is Adapted Command DSI rather than using RGB / DSI Video Mode, the DSI callback routine that updates the screen's region (in this project it does in sections of 200 lines), this is because the project is generated through TouchGFX Designer which also generated the DSI callback routines for the F4. If you were to create this in CubeMX you would have to design the callback routine for updating regions, if someone comes across a pixel off-set difference to their frame when they move from the OTM8009A LCD to another GRAM custom LCD my quick solution was not disturb the overall code but to find the part within the DSI Command callback routine that controlled location for the update regions via DSI Command.

For me this was the pCols array that was set out like this:

uint8_t pcols[4][4] =

{

{0x00, 0x00, 0x00, 0xC7}, /* 0 -> 199 */

{0x00, 0xC8, 0x00, 0x8F}, /* 200 -> 399 */

{0x01, 0x90, 0x02, 0x57}, /* 400 -> 599 */

{0x02, 0x58, 0x03, 0x1F}, /* 600 -> 799 */

}

My pixel difference was about 4 pixels so I added 0x4 to each second column (0x00, 0xC7 to 0x00, 0xCB) and this solved the issue.