BT817 – Unstable Rendering on 7"

[maciej_ch]

Hi,
I'm working with BT817 (STM32 + EVE-MCU-Dev) and multiple displays. On a 480×272 panel (PH480272T015-IAA15), everything works reliably — ASTC images from flash, fonts, stable rendering.
After moving to larger panels (MI0700COT-1 800×480 and LMT070WS027C 1024×600), I'm seeing unstable and non-deterministic behavior. The initialization and overall approach are analogous, but results are inconsistent. Depending on reset, the display may work correctly or show flickering, corrupted fonts/images, or ghosting (previous screen content partially visible).
Importantly, the issue also occurs with minimal code using only CMD_TESTCARD(), which is sometimes stable and sometimes shows artifacts. This suggests the problem is not related to display lists or assets.
Given that even testcard is affected, I suspect RGB timing (porches/sync), PCLK (frequency/polarity), CSPREAD, possible underruns, or signal integrity issues at higher pixel clocks. I've tried multiple timing configurations (both from datasheets and library defaults) as well as different PCLK settings, but without consistent improvement.
Has anyone seen similar behavior when moving from 480×272 to higher resolutions? Are there known-good timing settings for these panels?

Additionally, I have a few related questions:

• What is the practical maximum size/resolution of images that can be displayed smoothly on BT817 (especially when using ASTC 4×4 or assets from flash)?
• In flash FULL mode, is the SPI clock fixed by EVE, or can it be increased to improve throughput?
• For very large fonts (~400–500 pt), EVE Asset Builder seems to hit limits (glyph width issues) — what are recommended approaches to handle large fonts while keeping full character support?

Any suggestions or best practices would be greatly appreciated.
Thanks!

[BRT Community]

Hi Maciej,

Just one initial suggestion to check the PCLK polarity setting compared to your display datasheet as that can also lead to visual corruption.

One way to check if the issue is performance related (such as due to ASTC 4x4 assets from Flash) is to check the REG_UNDERRUN to see if it counts up. You can do a read of the register after you do the swap at the end of your new display list and print the value the next time round the loop via CMD_NUMBER.

Best Regards, BRT Community

[Rudolph]

In my experience, using the external flash for display list contents is an issue. And it gets worse with higher resolutions.
The reason is simple, the bandwidth for the external flash is limited and the higher the resolution, the less time the BT817 has to fetch data.
And it gets worse with lots of random access reads when using fonts.

So, rule of thumb, avoid displaying from flash as much as you can, use it as a last resort. This does not render the external flash useless, you can still copy assets to RAM-G when you need them.

Importantly, the issue also occurs with minimal code using only CMD_TESTCARD(), which is sometimes stable and sometimes shows artifacts.

That might be two things, incorrect initialization or an electrical issue with unstable supply.

Which library are you using?
I am working on a project right now which uses a 10" with 1280x800 and BT817, I just changed my project to use CMD_TESTCARD on startup for five seconds. And while there was a slight flicker initially, this was from the supply still stabilizing. When I just reset without power down it does not happen and after I changed the code to initially wait 2s, it stopped, so electrical issue.

What is the practical maximum size/resolution of images that can be displayed smoothly on BT817 (especially when using ASTC 4×4 or assets from flash)?

Apart from that I recommend using ASTC 8x8 as I only observed artefacts beyond that, it is less the resolution as the amount of images and therefore the random accesses necessary per scan line.
Years ago I ran into issues when trying to display 64x64 color icons, the limit was like 12 from external flash - but this is 8kiB per image, there is not really a reason to load these from flash.

Right now I am using a 720x720 ASTC 8x8 in my project and since it is "only" 126kiB it just sits in RAM_G. For the last iteration of the project I was using three ASTC 8x8 with 624x624 each and rotated two of these, 95kiB each, RAM-G, no problem.

Last year I did a project in which I had to emulate a TV for a demonstrator, my task was to display pictures from one particular american football team on a 5" with 800x480, in the end I used two RAM_G buffers to copy the images to from the external flash, 96000 bytes per image. But I tried, the double-buffer was not even necessary, I only kept it as there is no use saving RAM-G. The copy with CMD_FLASHREAD was so fast that I did not notice any issues from switching the images while there were displayed.

In flash FULL mode, is the SPI clock fixed by EVE, or can it be increased to improve throughput?

No, there is no API to change the flash clock, the only way would be to overclock the BT817 and that would also ruin the display settings, apart from other side effects that might occur.

Hmm, what clock speed is your BT817 configured to?

For very large fonts (~400–500 pt), EVE Asset Builder seems to hit limits (glyph width issues) — what are recommended approaches to handle large fonts while keeping full character support?

500? Wow.
Yes, I am also getting a warning: "WARNING: Characters with widths exceeding 255 pixels have been filtered out."
The limit for the reduced character Roboto I used was 290px.
The full font lost a couple of glyphs, out of 901 "only" 856 got converted to the size.
But the Roboto-Regular_280_ASTC.glyph for that is 28.3MiB...
What do you mean by "keeping full character support"?
Tried 400px, the glyphs converted went down to 587 - 35.4MiB.

At this size a tile approach should make more sense, I am not sure though if there are actually tools for that.

The BT820 could probably handle that as a font.
It still has the same limitation, if that can be called a limitation.

The output from the font converter in EAB 4.2.0 is not the same though:
Characters submitted by the user: 901
Accepted characters for conversion: 587
   Success: 587
   Fail   : 0

The relocatable asset Roboto-Regular_400_ASTC.reloc needs to be loaded by
cmd_loadasset. It will take 37536544 bytes of RAM_G after decompression.

Font conversion is now complete!

That is an issue, EAB in BT82x mode just silently refuses to convert glyphs without telling why.

[maciej_ch]

Thanks for your reply.
I had similar ideas and did some checks along those lines as well.

PCLK seems to be OK and aligned with the display datasheet. I also tried changing it, but it didn't have any visible effect on the issue.
I checked the REG_UNDERRUN yesterday in both projects. In both cases it is increasing, but it looks like in the large display project it increments much faster. That could explain the observed problems — in the smaller display project I didn't notice anything wrong because everything appeared to render correctly.

I ran a few tests on a very minimal setup and everything works fine as long as I don't use fonts or large images from flash. For example(displaying form flash):

• 800×480 image in ASTC 12×12 works fine
• 580×480 image in ASTC 4×4 causes the underrun counter to increase, but the display still looks correct

For images this is manageable since I can load and display them from RAM_G, but the real issue is with fonts. I need a relatively large font with a wide character set, and my tests show that even a standard Calibri font at 45pt with only basic Latin characters already causes the underrun counter to increase.

Do you have any recommendations for handling larger fonts or fonts with more glyphs when reading from flash, without increasing underrun or causing display issues?