Author Topic: Help with STM32H7 and LCD timings  (Read 2279 times)

0 Members and 1 Guest are viewing this topic.

Offline BoscoeTopic starter

  • Frequent Contributor
  • **
  • Posts: 276
Help with STM32H7 and LCD timings
« on: October 27, 2020, 02:07:26 pm »
Hi all,

I'm a little confused due to the general ambiguity and lack of information that ST like to introduce.

I'm currently trying to get this https://www.newhavendisplay.com/specs/NHD-5.0-800480TF-ATXL.pdf display to work on the LTDC module on the STM32H743ZI. Page 45 of this https://focuslcds.com/content/ILI6122.pdf data sheet gives the full timings for the screen.

I have images on the screen but they are not perfect and only possible with strange timing values for the horizontal signals.

First, ST like to confuse things by adding up the timings across some variables in the struct that configures the LTDC module. If I take the numbers from the data sheet for the display controller and enter them into cube I get the wrong timings output on the HW. So based on the HW I adjust the numbers in the struct so they are correct in real life. For my 800x480 screen this is as follows:

Code: [Select]
hltdc.Init.HorizontalSync = 5;
hltdc.Init.VerticalSync = 5;
hltdc.Init.AccumulatedHBP = 45;
hltdc.Init.AccumulatedVBP = 23;
hltdc.Init.AccumulatedActiveW = 845;
hltdc.Init.AccumulatedActiveH = 504;
hltdc.Init.TotalWidth = 865;
hltdc.Init.TotalHeigh = 550;


However this configuration only results in a black screen whatever I try to display. But while losing hope I started playing with the numbers. I found if I increase the
Code: [Select]
AccumulatedActiveW variable to 886 or above the screen works however the image is offset the screen to the left by about the amount I increase this variable by ~30 pixels (I can change this variable a lot and offset doesn't change). Changing this variable is just increasing the front porch which (from the data sheet) doesn't seem to be very fussy.

Does anyone have any experience or pointers that can give me?

Many thanks
George
 

Offline Silenos

  • Regular Contributor
  • *
  • Posts: 54
  • Country: pl
  • Fumbling in ignorance
Re: Help with STM32H7 and LCD timings
« Reply #1 on: October 27, 2020, 03:34:46 pm »
1. Get yourself a logic analyzer with bandwitch capable of capturing your desired, or at least minimal possible timings. You should be able to capture all the control signals and maybe 1 bit of color lines for the entire frame to be able to debug it properly. It is a waste of time to debug these things in dark.

2. I had issues with surprise, "undocumented" offsets of the lcd device - these maybe came from the fact that lcd prolly used the same controller shared between lcd of different sizes.
If I recall correctly, the frame handled by a controller was bigger/misaligned(?) than the actual height (count of pixels) of the lcd. I had to manually palpate offset to set the frame vertically aligned. It was a total random number. Maybe you also experience this issue.

3. I should have somewhere initialization code for this thing. If you don't mind waiting, I'll try to find those in the evening?
« Last Edit: October 27, 2020, 03:45:58 pm by Silenos »
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1719
  • Country: se
Re: Help with STM32H7 and LCD timings
« Reply #2 on: October 28, 2020, 08:24:56 am »
First of all, did you read the LTDC application note?
It contains a description of the peripheral and and some examples of its application.

If you are using CubeMX, the only strange thing is that is does not include the synch pulses in the back porch.

The variables in the HAL data structure reflect the internal LTDC registers, see table 6 in the AN, they make some sense if you think to the simplest HW implementation you can imagine: every value tells you when something changes since the beginning of the frame/line, so they are accumulated values.

That said:
  • The numbers in your structure would seem to match the ones in the data sheet, though the front porch duration is close to the lower limit.
    You might try to have it longer, closer to the typical 210 clocks, i.e. changing the total width - not the accumulated active width - to something congruous (or use the CubeMX).
  • Check that the effective pixel clock is within the display limits.


Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline BoscoeTopic starter

  • Frequent Contributor
  • **
  • Posts: 276
Re: Help with STM32H7 and LCD timings
« Reply #3 on: October 31, 2020, 11:43:36 am »
1. Get yourself a logic analyzer with bandwitch capable of capturing your desired, or at least minimal possible timings. You should be able to capture all the control signals and maybe 1 bit of color lines for the entire frame to be able to debug it properly. It is a waste of time to debug these things in dark.

2. I had issues with surprise, "undocumented" offsets of the lcd device - these maybe came from the fact that lcd prolly used the same controller shared between lcd of different sizes.
If I recall correctly, the frame handled by a controller was bigger/misaligned(?) than the actual height (count of pixels) of the lcd. I had to manually palpate offset to set the frame vertically aligned. It was a total random number. Maybe you also experience this issue.

3. I should have somewhere initialization code for this thing. If you don't mind waiting, I'll try to find those in the evening?

Thank you both for the replies.

I ended up going with option 2 here. I added 30 pixels onto the width and shifted my GUI layer on the X by 30 pixels, too. Works like a charm. It's still niggling me there's something I'm doing wrong underneath though.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf