cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F469I-DISCO NEW LCD Driver Missing NT35510

ilyus
Senior II

About a month ago (April 2021) I purchased STM32F469I-Disco from mouser.de here in Germany, my first discovery board with display. Things went fishy from day 1, but only after more than 2 weeks of black screen I realized: my disco has a different screen with a different LCD driver IC than in the examples! (which is NOT indicated ANYWHERE! I have to be a telepath apparently to know that, good job, ST).

My disco is incompatible with examples specifically for my disco. The LCD either stays off or shows random gargabe image slowly dimming around the edges and then in the middle over 2 minutes - hard to say what exactly goes wrong with it, seems like configuration problem of some sort, doesn't seem like porch problem or anything, seems more complicated.

All examples are for OTM8009A IC, while my LCD runs (I think? doesn't say anywhere) on NT35510, for which no drivers exist in the free internet (some random snippets, nothing fitting STM32 with DSI - some SPI drivers for some android supporting SoC were the best I found), I tried BSP, tried playing with it, modifying in most nefarious ways, etc., didn't help. Even consulted the datasheet of the supposed LCD driver, but since I'm writing this, you can safely conclude it didn't work out either.

QUESTION: Can anyone provide initialization/configuration routine/parameters for NT35510 over DSI? What clock ranges, what other parameters, commands? I would be VERY grateful. I have no wish to develop driver for the board, for which ST obviously HAS a driver, since default program that comes built-in worked with it.

________________________________________________________________

P.S.

ST, please, provide up-to-date drivers for your very own disco board!

If you update a component, you could also include updated driver for it! Especially since when I first plugged the disco in, there was a running example program on it! Which is NOT available for download anywhere, there is only a useless binary from which I can't extract any values or configurations. Or at least provide some resource, description of display specs, ANYTHING. You sell a disco board without saying what kind of display is on it and without prividing ANY compatible drivers or anything. I don't even know if it was produced on Mars, because I don't know ANYTHING about display out of the box. It's like I offer you to fly a plane because you have a driving license - old drivers obviously won't work. Currently I have no idea how to run this display, and I believe STM32F469I-DISCO is an unsupported gargabe (my personal opinion, don't take it personally; and 60EUR is significant money for me), I don't think it's OK to sell board and provide INCOMPATIBLE useless examples for it. I had to buy STM32F746 Disco instead (there go another 60EUR YAY I think I'm on a diet this month), just because unlike 469 it actually WORKS with the very FIRST example I try.

8 REPLIES 8

I'd imagine most of the clocking is materially very similar. The 2-lane DSI clocks at 500 Mbps (1GBps total bandwidth), it can clock slower, but needs to be as fast or faster than the data as it comes out of the LTDC for the display.

I don't know the panel part#, but I'd suspect the same resolution at the same refresh rate would be very similar, with perhaps some subtle changes in the line totals (vsync, porches, active), but if the DSI is already pegged at 500 MHz (250 DDR) the LTDC Pixel Clock * Colour Depth is still well below that.

https://focuslcds.com/content/NT35510.pdf

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

yeah this is exactly the document with missing parts, I found full version, and it still didn't help, it missed specific values

I have to provide clock for the display; Does it have to be close to 27xxx kHz as declared in BSP code? Or it can be anything within display's supported range, which is, I think, 8MHz-32MHz or something of that sort? Do I have to adjust that variable to my LCD-TFT MHz value? (The closest I can get with prescalers is 28.8MHz)

The Pixel Clock is all STM32 side LTDC setting. The DSI gets set to 500 MHz, at least in the examples I've previously pulled apart, except for the DSI/HDMI where there was an attempt to get the inflow/outflow clocks closer to parity.

Ignoring other line total components the minimum for 60 Hz refresh would be a pixel clock north of 23 MHz

800 x 480 x 60 > 23,000,000

@Imen DAHMEN​ @Amel NASRI​ is there a schedule to release a new BSP for the STM32F469I-DISCO, or a beta available?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
ilyus
Senior II

I got it to show a picture of touchgfx, attaching QSPI wasn't a problem, old drivers work. But it's not working 100% correctly. In fact, I'm not sure what I changed in the stm32469i_discovery_lcd, but it turns on now. Will compare it to my other attempts today or tomorrow (already did - read further), this one is called stm32f469try12 :D Already have try16 project (and I started numerating them only recently), which doesn't work (when it produced picture, I decided to reproduce it to make sure I can make it work - apparently I couldn't reproduce it - I couldn't turn on the display and make it show meaningful image again - so I backed up that project version just in case).

On the good side: I've read the entire code of the entire thing, I think, and I actually understand what every line of code does and what every struct is for - kinda feels nice. I didn't dare change much if anything in the file because it didn't seem necessary. I even compared original LCD file and my LCD file, I actually didn't find any difference other than porches that don't work. Yes somehow examples produce no image or warped, and my file works...well, 90% works.

On the bad side: there is a diagonal tearing line on the image. I tried changing all porches and active zones and stuff in all combinations going from small values like 1 through 12 through 20 through 144 through 255 for every parameter; Surprisingly, I get full screen picture when I set

/* lcd_orientation == LCD_ORIENTATION_LANDSCAPE */
    VSA  = (uint16_t)240;        /* 12 */
    VBP  = (uint16_t)255;          /* 12 */
    VFP  = (uint16_t)12;          /* 12 */
    HSA  = (uint16_t)800;        /* 120 */
    HBP  = (uint16_t)12;          /* 120 */
    HFP  = (uint16_t)12;          /* 120 */
    lcd_x_size = OTM8009A_800X480_WIDTH;  /* 800 */
    lcd_y_size = OTM8009A_800X480_HEIGHT; /* 480 */

Notice I set active zone of 1/2 screen height, with full 480 I get full picture but it's shifted 1/4 screen to the side, no porch adjustments resolve this unless I set active zone to fraction of 480 (I think 120 active height worked too with some porch adjustments, but not full 480). And I still have other issues regardless.

The comments in the code have original values that were there before big bad I showed up; don't ask me why this works, but this gives me full screen image, so I even have TouchGFX work now, BUT:

  1. I have 1 diagonal tearing "seam" on the screen in one of the corners. It goes from the middle of the right side of the screen to the middle of the top side of the screen. I don't know what to adjust to fix it.
  2. Whenever there is an animation or anything moving at all on the screen, the bottom line of the screen (all 800px) messes up for the duration of animation. Like I can see noise on the lowest row of pixels whenever anything moves on the screen, and it seems like it's actually moving the lowest row of pixels left and right very quickly; but if nothing on the screen moves, it's perfect like Mona Lisa.
  3. Just informing that touch driver doesn't work from LCD_init, but I have reimplemented it in touchgfx, so touch is not an issue. Focus only on image here.

You know what, how about I post my entire LCD file here for anyone to enjoy. As I said, I've noticed differences only in porches. Included .c, .h in the archive.

Also tried to up the LTDC Clock (LCD-TFT in clock configuration screen) to max 72MHz. Tearing and one line noise both still there. So seems like it's not about the clock and not about the porches. Seems to me like DSI/Configuration issue. Given I'm not sure about my screen model, there is a chance it's not solvable.

Funny fact: I found in google some request on freelancer website to write an LCD initialization driver for THIS VERY DISCOVERY BOARD with seemingly same screen model and problem as me, and the offers are like 300 euro per driver. Someone has the has question as me - why are there no native drivers provided with the board itself. Guess if I figured this out I could earn a little. Yet I only care about getting it to work to proceed with my project, of course.

ilyus
Senior II

Keeping my developer's diary: I've set the LCD-TFT (LTDC) clock at 72MHz, and then I did this in discovery_lcd file (original value in the comment):

uint32_t LcdClock  = 72000; /*!< LcdClk = 27429 kHz */

Note it's kHz, so to set 72MHz, I need 72000. Diagonal tearing is gone, I only have somewhat shifted picture now (something like 50px to the right from normal, with wrapping around, so what is supposed to be 50 most-right pixels of the screen are actually on the left on the screen), and I still have noise on the bottom 800px line of the screen whenever anything on the screen moves.

Tried 36MHz clock configuration and uint32_t LcdClock = 36000; Tearing was there just like before, only with 72MHz no tearing.

I will report my findings here in case some lost soul in 2025 runs into this forum thread with the same issue.

ilyus
Senior II

I kept going through the code again and have another improvement. I took closer look at DSI setup section of the code, it seems the thing overwrites my clock configuration among other things. As usual, original values in the comments, new values are the values I have come from the clock configurator. I'm talking about stm32469i_discovery_lcd.c file.

PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_LTDC;
PeriphClkInitStruct.PLLSAI.PLLSAIN = 144; //384
PeriphClkInitStruct.PLLSAI.PLLSAIR = 2; //7
PeriphClkInitStruct.PLLSAIDivR = RCC_PLLSAIDIVR_2;//RCC_PLLSAIDIVR_2
HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct);

Tried original porches (same file but a little higher):

/* lcd_orientation == LCD_ORIENTATION_LANDSCAPE */
    VSA  = (uint16_t)480;        /* 12 */
    VBP  = (uint16_t)12;          /* 12 */
    VFP  = (uint16_t)12;          /* 12 */
    HSA  = (uint16_t)800;        /* 120 */
    HBP  = (uint16_t)120;          /* 120 */
    HFP  = (uint16_t)120;          /* 120 */
    lcd_x_size = OTM8009A_800X480_WIDTH;  /* 800 */
    lcd_y_size = OTM8009A_800X480_HEIGHT; /* 480 */

Now I have:

  1. Full 800x480 Image. Haven't noticed any tearing anywhere.
  2. Animation causes no tearing, picture looks crisp, smooth, no flickering, actually, almost perfect (see 4).
  3. If I changed porches even from 12 to 16, the entire image on the screen is weirdly shifted. There is only very little adjustment one can make, it seems.
  4. I still have 1 line of pixels going crazy when there is animation. It was bottom row of pixels, now it's top row of pixels that's jittering. Just 1 pixel line going crazy during any animation (if there is no movement of the screen, that line of pixels shows what it's normally supposed to show and it's 100% correct picture). 800px-wide top line of the screen. Other than this defect, everything looks and works, seemingly, perfectly.

Will post updates if I get anything else useful out of this and, hopefully, get rid of that 800x1 line animation jitter.

Osman SOYKURT
ST Employee

Hello,

A new TBS is now available on TouchGFX Designer 4.21.0 for this STM32F469I-Disco $AU1 revision (B08)

0693W00000Y7iYHQAZ.png  

/Osman

Osman SOYKURT
ST Software Developer | TouchGFX
gmaajid
Associate

Can you also update TouchGFX Designer to support the A09 revision of the display for the STM32747I-DISCO

it defaults to using the otm8009a controller but should be using NT35510 controller as ateted here in your repo:

https://github.com/STMicroelectronics/STM32CubeH7/commit/1c84713102f8509deb79ae14db8dbb104c17c45e#diff-8a5b12f7040dfb560c495dc0a1213725ba939bf19d531dd1e97067b6a1a79ec0

 

The default code results in screen tearing and other issues.