Why the WXGA (1366x768) at 60fps limitation for STM32MP157C MPUs?

[AlexeyR]

I am evaluating different dual-core ARM Cortex-A7 MPUs for their graphical features; one of my requirements is that I need to support a 1280x1024 TFT LCD at 50-60fps using 16 or 24-bit parallel RGB interface.

The evaluation kits offer small LCDs below my requirements, and I need to make sure that the MPUs can support what I need.

Looking at the datasheet for STM32MP157C MPUs, it is clearly stated in multiple places that the upper pixel resolution limit for the LTDC module is WXGA (1366x768) at 60fps. However:

• the max pixel clock - LCD_CLK is stated to be 90MHz at specified supply voltage range. At that clock frequency, barring any external memory-related bottlenecks and assuming some small HSYNC/VSYNC + porch timings, I should be able to run a 1280x1024 LCD at around 63 fps max - and for sure at 60fps. Involved memory transfer clocks seem to be fine as well (I could be wrong on this one).
• LTDC register definitions seem to support much larger width and height values than what I need, so I should be able to program it to do what I need it to do without a problem.
• One of the product training presentations from ST states that "Higher resolutions are possible" using LTDC, but at lower FPS. Again, the stated clock limit should allow for much better performance

With these assumptions, what ends up being the bottleneck here? Why the oddly-specific WXGA specification in the datasheet?

Thanks!

[Thomas L.]

I asked pretty much the same question and it boils down to the memory interface: https://community.st.com/s/question/0D50X0000BCNoPUSQ1/stm32-ltdc-maximum-resolution

[AlexeyR]

Thank you for a quick reply.

While that thread and app note are applicable to working with LTDC itself, there are major differences between ST's MCUs and MPU lines:

• The older thread applies to the high-end MCU lines. The new MPU line seems to be quite a bit more advanced in its capabilities, including faster system and memory clocks, etc.
• While I understand that memory will be the ultimate bottleneck here, memory bandwidth may not necessarily be as much of a problem. I am eyeing the DDR3 interfaces that MP1 devices offer, and planing to use dedicated external memory specifically for LTDC. I have not worked with DDR3 before, but as I understand, it offers much higher bandwidths than the STM32H7/F7's DDR and FMC interfaces.

What I am wondering about is whether there is some internal bottleneck that I am not seeing. Where is the 1366x768@60fps limit coming from? I doubt that ST's R&D would base this spec off of a random external RAM chip (but if so, I'd like to know how they went about this). Other devices in a similar market field - for instance, i.MX7D - do not seem to have a similar limiting specification.

[Thomas L.]

I'm sorry. I didn't really read the "MP1" part of your question. Of course you are correct that leveraging DDR3 should result in far more bandwidth. I am wondering if the LTDC might be in the realm of the M4 coprocessor. I have worked with the i.MX family in the past and usually there was some special IP involved in all the graphics processing (and only limited documentation was available).

Sorry I can't be any help here but hopefully someone with more experience on the MP1 parts will come along.

[AlexeyR]

I appreciate the effort! Thank you.

[Tesla DeLorean]

Pretty much looks to be 2-lane DSI ceiling

16-bit x 1388 x 768 x 60 -> 1Gbps -> 64 MHz

[Tesla DeLorean]

https://www.st.com/content/ccc/resource/training/technical/product_training/group0/78/a1/45/b9/54/53/48/dc/STM32F7_Peripheral_DSIHOST/files/STM32F7_Peripheral_DSIHOST.pdf/jcr:content/translations/en.STM32F7_Peripheral_DSIHOST.pdf

https://www.st.com/content/ccc/resource/technical/document/application_note/group0/1d/b8/33/4f/dc/0a/45/52/DM00287601/files/DM00287601.pdf/jcr:content/translations/en.DM00287601.pdf

The MP claims to have a slightly higher ceiling, but might depend on specific displays,

24bit x 1388 x 768 x 60 -> 1.5 Gbps

24bit x 1920 x 1080 x 60 - > 3.0 Gbps

[AlexeyR]

Ah, that makes a lot of sense. So I am assuming that since I am not serializing my RGB data via DSI, I don't have to worry about this at all?

Suggestion to ST: if this is the case, you might want to move that spec out of your "general LCD TFT spec" section into a DSI-specific section of... pretty much all of your MP1 resources, including web pages, presentations, and marketing materials. Otherwise, to a anyone like me it just looks like the parallel RGB module can only support up to 1366x768@60fps, when in reality it seems like the parallel-mode capabilities are much better.

Thanks @Community member​ !

[PatrickF · Accepted solution]

Hello,

For the max resolution, your are right that the limit is directly linked to pixel clock frequency.

As effective resolution depend on LCD characteristics, we take a conservative +40% for porch/sync/etc... this mean 1366*768*60*1.4 = approximately 88MHz pixel clock. Higher resolution with lower frame rate are possible whenever fitting the max pixel clock.

Notice that 24-bits // RGB need to toggle simultaneously a lot of external signals, which, at high frequency such at 90MHz, will end up to a lot of supply noise/energy/signal integrity in case display is adding load above 20pF (which might be the case if one or two connectors, flat cables, etc...).

DSI has not this drawback (although still limited to 2x1Gbps).

RGB bridges (such ad RGB to HDMI) are soldered close to MP1, so keep usually load below 15pF.

As HSE crystal oscillator might be sensitive to the supply noise created by highly loaded RGB //, we recommend to use an external 24MHz oscillator when running above 48MHz pixel clock with VDD=3.3V.

VDD=1.8V involves less energy, so less concern is expected, but note RGB pixel clock is limited to about 70MHz due to lower IO strength at this lower voltage (LTDC IOs have no high speed option at low voltage as for SDMMC, ETH. SPI, QUADSPI)

see also :

AN5031: Getting started with STM32MP1 Series hardware development

ES0438: STM32MP151x/3x/7x device limitations

Hope this help.

[AlexeyR]

@PatrickF​ thank you so much for your insight! That makes sense. It seems that with a good hardware setup and lower porch/sync values (and an HSE oscillator), higher resolutions are definitely possible. Also, I did not know this limitations document existed - it will be very useful.