800 x 800 Display with STM32U5G9VJT6Q - possible?

[Ricko]

Hi,

we are trying to get a 800x800 display to work with the STM32U5G9VJT6Q, using either RGB888 or RGB565 in Video Mode (Burst).

According to what we read it is definitely possible. Did we miss something?

Could someone please confirm that is definitely possible?

Much appreciated

Thank you

[Ricko]

Thank you @Tesla DeLorean 

I have that controller datasheet but it does not show any clock specs.

The manufacturer suggested the pixel clock = 44MHz (which is what we also get) and the DSI clock = 270MHz so byte clock = 33.75 MHz

But CubeMX does not allow setting the PLL to that combination of values, which is the reason for asking the previous question.

For example, if I set the the pixel clock to 44MHz (as suggested by the manufacturer) then the values that CubeMX calculates for the DSI are only 33 MHz (lower than the minimum so not an option) or 44 MHz (quite a bit higher than the value suggested by the manufacturer).

That is why I was asking whether I can set the DSI much higher than the minimum value of 33.75MHz (in this case 44MHz)?

Thank you :)

[MM..1]

Try show screenshot , where CubeMX calculate 33MHz for DSI? And display info is clasic defined for 4 lanes MCUs.

Then for STM you require 33,75x2, but this is over 500 limit... Simply start test display on max DSI speed 62,5MHz byte DSI clock. Display controllers accept this speed , but require right setup for LP iddle transitions etc.

[RobNewbury]

Hi Ricko,

Did you get your display working? I'm having similar problems with a Tailor Pixels display (TTH040BRT-02C) which also uses JD9365DA-H3. I am sure I have the timings correct but the display remains blank.

I know that LP commands are being processed correctly as I am enabling the TE output to check the frame timing and this is correct. I've also used the LP command to activate the display built in self test which works, but oddly only if the D-PHY bus is stopped, the JD98365 datasheet is poor so this may just be how it's supposed to operate. 

I'm using STM32F469 and have taken into account the maximum supported pixel frequency as per AN4861 and discussed earlier in this post.

I have been succesful using Tailor Pixels TTH345BRS display, but this uses FL7705 controller.

Do let us know how you got on with driving your display. :)

[Ricko]

Hi@RobNewbury 

Apologies, I haven't logged in for weeks so I just saw your message.

Interestingly I was using a Taylor Pixels Display too...

I got it kind of working... the image was split in two halves and the right half of the image was displaying on the left half of the display... and the right half of the image was displaying on the left half of the display.

It took months only to get to that point so the project was then dropped. 

Did you get yours working?

Thank you

Rick

[RobNewbury]

Hi @Ricko 

Thanks for getting back to me. Yes I have got both my Tailor Pixels displays working! But it's probably a bit like having a baby, it was so painful getting there, I can't remember what I did to make them work, otherwise you would never try again!

That said, luckily I wrote it down.

1. For the TTH040BRT-02C display (this uses Jadard JD9365DA-H3) and is 720x720 pixels.
   The problem was that I had incorrectly set the DSI packet size to 800. I had thought that the packet size needed to include all the sync's as well as the active pixels, however this assumption seems to be wrong so the JD9365DA-H3 was just ignoring any data sent to it on the DSI-PHY.
   I changed the setting to 720 (which is the active pixel width) and it all worked great!
2. For the TTH345BRS display (uses FL7705 display controller) and is 800 x800. I was trying to initialise the display in HS mode. This worked 70% of the time, so I changed to sending the initialisation in LP mode and all is now ok.

Interesting what you say about the screen vertical lock. I've seen this also, but only on some screens. I found that by adusting the pixel clock (which also adjusts the vertical sync timing) you can walk the vertical sync to the edge of the screen. However I don't understand why this only happens with some and not all rendered screens. I have a hunch that it may be some sort of timing issue to do with TouchGFX double buffer access beating with Vsync? As I find it's not a problem if you render direct to GRAM without involving TouchGFX.
It's one of my next jobs (after sorting out TouchGFX TBS's) to address this. I'll let you know how I get on.

By the way I've been working on this 2 years (on and off) and only now do I consider the project to be far enough on to order prototype PCB's, up untill now I've been interfacing to a DISCO board. ... So don't give up!

[Ricko]

Thank you @RobNewbury for the detailed reply.

At some point I would like to get the display to work properly and use it for some project, especially given how much was spent to make the prototypes. 

Any chance you could share the display configuration part of the code? Obviously nothing confidential, just the minimum that got the display to work. Either here or in a private message?

Many thanks

Rick

[RobNewbury]

@Ricko Hi Rick, It's a bit tricky to define what got the display working as there are number of parameters that need to configured correctly and work in unison before the display will do anyting sensible at all. Besides, it sounds like you have gone beyond that stage, i.e. to get the display to render, even if it's not synced correctly, you must have written a display driver to initialise the display and set up the LTDC plus DSI accordingly using CubeMX.
We're also using different procesors, mine is STM32F649, yours is STM32U5G9VJT6Q I believe, so the HAL etc., will be different.

What I found helpful was to add some test code in a user area in Main.c.

I added this code immediately after the initialization code.

It does the following:-

1. Invokes the inbuilt pattern generator of the DSI, this will verify that the DSI and display is working ok regardless of the LTDC and framebuffer setup.
2. Write the pixel values for RED, then GREEN, then BLUE (I'm using 16 bit RGB) direct to the frame buffer. This will tell you if the frame buffer and LTDC are seup correctly regardless of any higher level configuration.

/* USER CODE BEGIN 2 */

  /* for test, show pattern generator for 2s */

    HAL_DSI_PatternGeneratorStart(&hdsi,0,0);

    HAL_Delay(2000);

    HAL_DSI_PatternGeneratorStop(&hdsi);



//    Now check the colours

    uint8_t *framebuffer;

      framebuffer =(uint8_t *)0xc0000000;

// Red Screen

    uint8_t *fb = framebuffer;

    while(fb < (uint8_t*)(framebuffer + (720*720*2)))

    {

      *fb++ = 0x00; // Write red colour

      *fb++ = 0xf8; //

    }

    HAL_Delay(2000);

//Green Screen

    fb = framebuffer;

    while(fb < (uint8_t*)(framebuffer + (720*720*2)))

    {

      *fb++ = 0xE0; // Write green colour

      *fb++ = 0x07; //

    }

    HAL_Delay(2000);

    //Blue Screen

    fb = framebuffer;

      while(fb < (uint8_t*)(framebuffer + (720*720*2)))

      {

        *fb++ = 0x1F; // Write blue colour

        *fb++ = 0x00; //



      }

      HAL_Delay(2000);



  /* USER CODE END 2 */

I hope this helps.

[Kelly3]

Hi, @Ricko ,

I am using stm32u5g9-dk1 kit for a 454x454 display. The driver IC is SH8601. This driver can work in command mode or video mode since it has internal GRAM. But in either mode, display initialization has to be in LP mode. 

In command mode, I only be able to configure it and turn the display one by sending all pixel on command 0x29.

In video mode, command write is set in LP mode as in the following screen shot, and it does not work.

Since the largest configuration data is  bytes, total DCS long write packet would be 10 bytes long according to MIPI standard. 1 byte DI + 2 bytes WC +1 byte ECC + 4 bytes data + 2 bytes CS = 10 bytes. So, setting the LP largest packet for commands to be 16 should be enough. And in LTDC configuration, synchronization for horizontal and vertical in also guarantees time interval for 16 bytes long command packets. HSYNC, VSYN, back porch and front porch value are given by display manufacture. 

Yet, in video mode, I am not able to configure the display even turn it on using all pixel on command 0x29. 

I have been working on it for quite long time. So far, I only can send image data for proper image display by configuring DSI host in " Command Mode via APB Interface", i.e. in LP mode. But the LP mode is so slow. I am stuck in the middle of using HS mode to send image data to display. 

If you were able you make your display working with STM32U5G9, may I have some information on which part could be wrong with my configuration?  I have been working on it for 3 months, still no clue what could be wrong.

[Ricko]

Thank you @RobNewbury ! :)

[Ricko]

Hi @Kelly3 

Attached are two project.

It has now been many months since the client halted this version of the project and move to another solution because it was taking months just to get the display working, so I don't remember the details. But by the time the project stopped, we had only managed to get the display to show the left half of the image on the right side and the right half of the image on the left side.

It was unbelievable that something as straightforward as bringing up a display - normally a task that takes a few days at most - ended up dragging on for months. And this was with active assistance from ST technical support, the display manufacturer, and the display IC manufacturer, all working with us simultaneously.

And bit of a shame we had to shift for this project because - coming from Microchip - I love the ST product line and dev tool, in my opinion they beat everything else hands down! 

Anyway... attached is the latest code. This is the simplest version that handles only the display initialization and nothing else. It reflects the final modifications provided by ST’s technical support, who were extremely helpful in getting us even to that point.

Unfortunately, by then the client instructed us to stop the project entirely and move to a different platform, as they were losing tens of thousands of pounds per week.

There are two ZIP files included with mods made by ST tech support (see their comments in the code):

- The first one uses an HSE = 16MHz and they tested it with an STM32U DK board and apparently works well
- The second project ST adjusted the PLL settings to use our HSE  = 8 MHz HSE but they did not test it because this don't have our hardware 

I hope that helps :)