A bit disappointed about the STM32H7R/S lines

[Southbranch]

Dear ST,

I was pleased to hear about the new STM32H7R/S lines, especially with the new graphic acceleration features in the R-line.

However, and perhaps I have missed something, but I have to admit I am also disappointed about the absence of large sized internal RAM and FLASH. I was hoping to see a new boosted H7-version with large capabilities of internal memory similar to some devices in the STM32U5-series. A minimum of 4 MB RAM  +  4 MB FLASH would probably have made the need for external memory interfacing unnecessary in 9 out 10 applications and making the device work perfect with large screen resolutions out-of-the-box.

Instead, the new STM32H7R/S lines would now need to be interfaced with BOTH external RAM and FLASH. Also, it seems to lack support OCTO SPI interface which would lead to a more complex PCB design with parallel memory interfacing.

So, I am curious to hear if there are any plans for making a device version with larger internal RAM and FLASH like the U5-series, preferable also in a LQFP-package with low pin count like 100 or 144 pins?

[LCE]

No OCTO SPI, and not more SRAM ?

Wow, that's terrible. Not only for graphics stuff.

[Soren Myllerup MIKKELSEN]

Hello Southbranch,

Thank you for sharing your feedback on the newly announced STM32H7RS. 

First let me clarify and important point. The STM32H7RS is the STM32 the MCU with the mosh rich external memory interfaces. It has 2x OctoSPI, but also a 16bit SPI with 200MHZ DTR and 1 32bit FMC, and 2x SDIO. So you have all the interfaces needed. Very fast, with XiP, and L1 cache, and 620K of SRAM with TCMs which can be increased also. 

Overall the strategy put in place with the STM32H7R/S lines, is to give maximum memory flexibility to the developer. 

One of the drivers behind this the example or running a 800 x 480 resolution or above. The flash requirements for sure exceeds the 2-4 Mbytes of internal Flash in many STM32s, so instead of paying for the internal Flash, we limited it to 64Kbytes, so the developer has more room (BoM), so select the right density and type needed.

Second point, is for the required SRAM running a GUI. The U5x9 is indeed a good product, IF you can fit internally only. But as with embedded development it is not easy to pre-plan the needed SRAM. You need to fit minimum 2 framebuffers, then maybe a video buffer, and on top it could a stencil buffer to do vector graphics + the rest of the applications requirements.  

All of above adds to the SRAM need, and in many cases exceeding the 1-3Mbytes of internal SRAM some MCUs has.

The point you raise about creating a high-perf MCU with maximum flash and RAM inside, is also raised by others, and something we take into account.

Overall, the STM32H7RS intends to bring MPU-like applications to the MCU world, maintaining the real-time aspects, price, MCU simplicity and keeping performance and maximum memory flexibility. 

[Southbranch]

Hello Soren,

Many thanks for replying on this matter.

Of course, the flexibility with external memories would be essential and I believe this is a good strategy from ST for the new H7-line.

However, sometimes less is more while still being able to maintain computational performance. 

I our case we have an "industry-like" application with the need of a large display 1024 x 600 px that does not need video or much animation since the screen mainly will be made up from straightforward page navigation around gauges, meters, measurement values etc.

In additional we are keen to achieve as simple PCB-design as possible for low production costs and maintenance, thus we would have loved a new H7-line with BIG internal FLASH and RAM.  We have successfully tested our application on a device from the U5-series, however, we are worried about the computational performance and scalability.

In the meanwhile, is there a chance you could guide me to a device with 2 x OCTOSPI in the new H7-line? (low pin count preferably)

[Soren Myllerup MIKKELSEN]

Hello Southbranch,

I agree that there is a positioning for a high memory High-performance MCU in our portfolio, even larger than H7A3 with 1.4Mbytes.

Your case is interesting. Breaking it down:

1. 16bpp: ~2.5Mbytes of RAM. (1024*600*2*2)/1024 assuming 2 framebuffers
2. 24bpp: 3.6Mbytes of RAM (1024*600*3*2)/1024, assuming 2 framebuffers

What about the rest of the application? you might require some communication stacks? dynamic data inputs, etc.

Your concerns about performance and scalability is why we are doing the STM32H7RS, also to ensure any potential FW upgrades in the future which might increase flash or RAM needs.

Your point of the small packages is valid, STM32U5x9 comes in LQFP100 (14x14mm).

If you require LTDC and 2xOctoSPI you have 2xOctoSPI interface on the UFBGA144 (10x10mm) and LQFP176(24x24mm) on the STM32H7R7 lines. 

Best regards

Soren

[Tesla DeLorean]

>>However, and perhaps I have missed something, but I have to admit I am also disappointed about the absence of large sized internal RAM and FLASH.

It is a play to get very high die counts off a single wafer, akin to the RP2040 model.

Compare that to a die with 4MB FLASH / 4MB RAM, it's going to be very large, very expensive, and relatively few to a wafer. Sure it shrinks your BoM, and locks you to a single supplier/source. The supply chain issues of the last few years aren't a lesson we should forget to soon.

I'd imagine its a chip that will get made, it's just higher risk and more niche, especially with the geometrically expanding STM32 portfolio.

[Southbranch]

Thank you both,

Our project uses the 24 bpp display and yes, then we would need 3.6 MB in order to manage a double frame buffer. A bit tight in a potential 4 MB internal flash, but a single buffer could also be ok.

We are actually using a STM32U5x9 in a LQFP100 package. In regards to peripherals, our sensor measurements come in via a CAN and I2C and we are using a handful of GPIO:s to “control the outside world”. Together with 1-2 UARTS, OCTO SPI (extra mem backup) and SD we are managing fine with just the LQFP100 package. The only thing we are missing is support for ETH.

So basically, to get a new device best seller -;) You would just need to copy the architecture from a STM32U5x9-line into new H7-line with large internal memory. Also add ETH and make sure it comes in 100 or max 144-pin LQFP. I believe such as device could cover a vast majority of apps.

Also, for us is it not just about reducing the BOM as such, which in fact could lead to suboptimization. It is more about keeping the PCB-design as simple as possible. Most PCB-manufactures charges extra fees if more than 4-layers are used, if blind/micro vias are used, if via dia is small, mounting components on both sides etc. Using a MCU with low pin count in LGFP will help reduce the PCB-costs. Needless to say, a simple and straightforward PCB design are much easier and cheaper to maintain and scale over time with upgrades and modifications.

[Pavel A.]

@Southbranch But it has ETH. It has even I3C. It will even make coffee, with an external coffee machine ))

[Southbranch]

@Pavel A. Sorry for not clarifying. I was referring to STM32U599VJT6 LGFP100 which we are using, it does not have ETH. I am not sure if any of the other higher pin U5-devices have support for ETH.

As an observation, lower pin packages from e.g. the previous H7-series often seems to have a conflict between configuring ETH and LTDC 24 bpp at the same time.

[Soren Myllerup MIKKELSEN · Accepted solution]

Hello @Southbranch,

If you target 1024*600 and doublebuffer you are exceeding by far the internal SRAM of the U599 MCU. 

As the framebuffers needs to recide in either internal or external SRAM your options are too lower the BPP to 16bpp, which requires around 2.5Mbytes of SRAM or use external RAM with enough space.

Then you have the option with STM32H7R/S or the STM32U5F9, which is also in 100pin LQFP with 3Mbytes of SRAM.

Anyway, its important to ensure enough memory to room for your future FW upgrades and product enhancements, and the STM32h7RS was designed for this. I see that you still buy external memory eventough have 4Mbytes of internal Flash, for future proofing. 

You have an interesting point witht the PCB, and in limited insight to PCB design, its not only about the package size and type, but also the pitch which all comes in great flexibility on STM32H7RS lines.

I take your point of a high-perf with large memory, low pin count for graphics applications. 

Would be a good positioning with low memory devices vs high memory devices in the future high performance portfolio.