STM32H7R/S lines: 1st STM32 with bootflash and on-the-fly encryption

[Amel NASRI]

The new STM32H7R/S lines are built on the success of the STM32H7 series, offering even higher performance and security at a lower cost. The STM32H7R/S is a bootflash-based MCU powered by a Cortex®-M7 core running up to 600 MHz, with 64 KB of user flash and 620 KB of flexible SRAM. It is designed for external memory scalability and flexibility accommodating the most demanding application requirements in IoT, medical and industrial settings.

The STM32H7R/S lines cover a general purpose line (STM32H7R3/7S3) and graphics line (STM32H7R7/7S7), to address the MPU-like GUI applications. Additionally, both lines offer advanced security features (including secure boot, secure firmware installation, and hardware encryption/decryption) and target SESIP3 and PSA Certified Level 3 certifications.

 

 

STM32 software and hardware tools available:

• Nucleo board: NUCLEO-H7S3L8
• Discovery kit: STM32H7S78-DK
• Dedicated software package: STM32CubeH7RS
• X-CUBE-TOUCHGFX board support package in TouchGFX Designer
• Expansion packages such as X-CUBE-AWS-H7S, X-CUBE-AZURE-H7S, X-CUBE-AZRT-H7RS

 

For more information:

• Press release: https://newsroom.st.com/media-center/press-item.html/p4615.html
• Blog article: https://blog.st.com/stm32h7r-stm32h7s/
• Website: www.st.com/stm32h7rs
• Youtube playlist: https://www.youtube.com/playlist?list=PLnMKNibPkDnEEBenkOkcJTWLfW1ep4r4s

 

[etheory]

Will you ever develop a 1GHz ARM Cortex M7 option to compete with the NXP i.MX RT1170 Crossover MCU?

600MHz is great, but it's still not maxing out what the M7 is capable of.

Thank you.

[Soren Myllerup MIKKELSEN]

Hello @etheory 

A "real" MCU is more than just MHz. Please take a look at the sub-system, the speed on the interconnect etc. access to external memories, etc. package size for simpler PCB, int flash, etc. 

Can you be a bit more specific about 1GHz requirement you see? 

Best regards

Soren 

 

[etheory]

Thanks for your reply @Soren Myllerup MIKKELSEN. I'm well aware of your point, I'm just curious if the 600MHz speed is limited by the things you mention. i.e. the maximum speed of your flash interconnect, memory interconnect etc. If so, that's totally fine, but so far your H7 chips have gone from 480MHz to 550MHz now to 600MHz. I'm just curious what the ceiling is given your current technology and if we might see even faster M7's in the future? MHz isn't everything, but with MCU's running the same ARM CPU architecture, it is. Especially with the M33 and M7 comprising most (almost all) of your current MCU performance line. Personally I'm just hoping for an STM32 M85 running at 480MHz+ to compete with the new Renesas RA8 line because I prefer the STM32 eco-system and products personally (and have a lot of experience with them) and because I would really like some SIMD capabilities in your MCU products to get more performance than raw MHz would provide.

Thanks for responding.

[Soren Myllerup MIKKELSEN]

Response time is almost like a normal conversation, @etheory I will try to keep up :).

Of course I cannot disclose the full roadmap here, but with STM32N6 announced some while ago reaching high MHz, and the 18nm technology platform coming, you can for sure expect much performance, more integration both in terms of features and memory. then let's see which core will be used here.  

If you are in contact with a local distribution or ST contacts, under NDA you are able to get a better insight. 

I know its not the answer you are looking for.

 

 

 

 

[tjaekel]

To be honest:

• 600 MHz (compared to STM32H723 with 550 MHz and similar memory sizes) - is not really an improvement:
  Yeah, I would also expect to see a 1 GHz CM7 running, especially if other vendors like NXP have it.
• A quick glance at the features and datasheet: how to connect the external memory? It is needed to have code flash externally. At a first impression: OK, it makes my HW now more complicated (a "must" to have external memory).
• OK, there is mentioned: 2x OCTOSPI with up to 200 MHz (not mentioned if 200 MHz in DDR or SDR mode or just able to clock with 200MHz internally, as the STM32U5xx can do):
  I would "hope": QSPI with 160 MHz external flash in DDR mode will work (but who does know?)
• Reducing the internal flash in favor to let users connect an external flash, esp. JUST if this could be faster as the internal flash - is fine by me. But where is the performance benefit?
• But when it ends up in a more complicated schematics, e.g. to connect external memory via FSM (or OCTALSPI) and "complicated", larger PCB - where is the benefit of using external code memory now? External Hyperflash is not really so easy to design (as PCB) and to bring up to work. And it needs much more space now on PCB.

To be honest: I would not consider to have such a MCU chip. It makes it more complicated on PCB (with a "must" for external memory), with FW (configure now QSPI external memory to keep booting from it), it can result in a slower boot process.

Are you "speculating" that external memories are faster as you could design internally in chip RTL?
I know, internal flash memories are a nightmare for chip designers: power consumption, different architecture and technology in RTL chip design.
Is the hidden message? You cannot speed up internal flash memory even more, you cannot reduce the power consumption even more? You give up and now you let the users decide how to solve it with their schematics and system setup?  LOL (sorry)

But where is the benefit to have such a MCU (with external memory needed)?

• is it "dramatically" faster as existing MCUs? - NO
• is it much more power efficient as with internal flash? - not checked, but assuming - NO (not really on a system view)
• is it easier and more convenient to use? (PCB, external components needed) - for sure! NO

Not in my bucket list to use.

I suggest also: be focused on getting 1 GHz working for a CM7 core, or a RISC-V MCU core in your portfolio...

[tjaekel]

You might make your MCU RTL design Open Source: now users can tweak and optimize for their needs (you are going already towards this direction, don't you?). LOL

Be focused on 1 GHz and reducing the items listed in errata sheets. Placing all the burden now onto the users... "nice idea". LOL

[tjaekel]

I get your "message" as: "you have trouble to increase speed on internal flash memory". I understand: Flash memory and SRAM inside chips are very challenging. Do you have also a problem to design chips with faster and larger internal SRAM? When will you tell us to connect also external RAM memory?

If flash memory integrated is your concern: add more SRAM (if you are able to handle internal SRAM with fast speed). Make more SRAM available so that users can load code into SRAM. Make Caches larger... Just reducing the flash memory size without any other improvements and forcing to use external (slower memory) does not sound to be "a benefit".

And Security:

What is "on-the-fly encryption"?
Do you mean the code on external flash memory can be encrypted? And it will be decrypted when reading code from it?

It raises another question for me:

• how to flash the external flash memory?
• how to encrypt the code going into this external flash memory?
  Is there any debugger, tool support to do so?
  If anybody can encrypt content with the same keys and tools - it would be wide open for everybody to decrypt again.
  Do you consider providing tools for encrypting, flashing code in such external memory, with public and private keys?
• And is the system really secure when "hackers" are able to monitor the data coming from external flash into MCU? Anybody would be able to use a scope, logic analyzer and decode (and decrypt) the data/code from external memory going into MCU. It does not sound really secure for me.

I like the idea on the STM32U5xx MCU: nobody can trace the data/code on a memory (nothing populated on external pins). If somebody tries to hack, to intrude the system (tamper) - there is an option to erase quickly all memory contents, including the flash. This would be really secure!

But if you design a system with all the sensitive data and code on external flash: everybody can let the MCU unpowered, desolder the chip and read it out, decrypt its content. Or: monitor the external interface when running and decrypt on the fly, in parallel.

This is (for me) for sure not an improvement on security: NO, it is a big hole in secure systems! Nobody would be able to realize a snoop on your system, an intrusion. No way to erase all the content in external memory when realizing an "attack" and intrusion.

And how would such an external memory support "trust zone"? Some code and data on secure memory, some as non-secure. It is just ALL one external memory, so that all seems to be on "non-secure" zone. Or do you have option to provide two external memory interfaces? One for secure code and data, the other for non-secure? I would expect to see TWO external memory interfaces, for "trust zone" (secure vs. non-secure). But is it there?

Would it be still possible to separate the FW, code and data into secure and non-secure? To have different memory regions for "trust zone" on (external now) memory? It does not look like it will be there.

If all users have to connect now external flash memory, e.g. via OCTOSPI (or simply QSPI) - is this a violation of "trust zone" approach now? Any hijacked or even "wrong" designed FW can now access and read "secure data/code" in external flash! Just reprogramming the MCU with a different FW can read now all what was "considered secure" before.

I think: this concept of external flash as a need to be connected "violates" the ARM trust zone idea. And there is not a clear demarcation line for secure and non-secure: the external interface, e.g. as OCTOSPI is now mixing secure and non-secure traffic: easy to trace all the data/code with external scopes.

You (as company) seem to divert into directions which are not clear, why and for what improvement. And you seem to open holes for really secure systems. Is this idea driven by a "system design" or just the fact that you cannot make the internal flash faster anymore (because of your design tools used, the technology, e.g. the fabrication process, ...)

Your message is not a good sounding message for me. Sorry (it sounds more like: "we gave up on...")

[Soren Myllerup MIKKELSEN]

Hello @tjaekel 

First of all, we appreciate your time already investment in getting to know the STM32H7R/S just introduced, and it is great to see your youtube channel loaded with STM32 kits.

We took the time to address your points raised and further explain the motivation and positioning behind this product

Secondly I have commented and corrected on wrong assumptions/statements.

Next time, less LOLs would be appreciated, to keep a friendly tone on the community.

I hope our reply will help you and all the community with more clarity. 

Part 1:

To be honest:

• 600 MHz (compared to STM32H723 with 550 MHz and similar memory sizes) - is not really an improvement:
• A quick glance at the features and datasheet: how to connect the external memory? It is needed to have code flash externally. At a first impression: OK, it makes my HW now more complicated (a "must" to have external memory).
• OK, there is mentioned: 2x OCTOSPI with up to 200 MHz (not mentioned if 200 MHz in DDR or SDR mode or just able to clock with 200MHz internally, as the STM32U5xx can do):
  I would "hope": QSPI with 160 MHz external flash in DDR mode will work (but who does know?)
• Reducing the internal flash in favor to let users connect an external flash, esp. JUST if this could be faster as the internal flash - is fine by me. But where is the performance benefit?
• But when it ends up in a more complicated schematics, e.g. to connect external memory via FSM (or OCTALSPI) and "complicated", larger PCB - where is the benefit of using external code memory now? External Hyperflash is not really so easy to design (as PCB) and to bring up to work. And it needs much more space now on PCB.

A:

To ensure the most versatile 32-bit MCU portfolio we are always designing new architectures to address different market needs. For sure, one MCU cannot cover all needs. This MCU is addressing some of customers needs, not all.

You will be surprise to see, that we can reach a new cost entry with this STM32H7RS, but of course the product relays on external flash at least, which is commonly used in the industry (SPI, QSPI, octo, etc.), and the developers should have this in mind, when designing.  

The overall idea is provide at the lowest cost possible on the high perf MCU, to free $$ selecting the right external memory/memories.

By embedding all the common STM32 interfaces we have: 16/32bit FMC, 1xOctoSPI, 1x HexaSPI (8/16bit) with up to 200MHz DTR, and 2xSDIO, it is the STM32 with the most rich memory interfaces you can find now.

So what about performance, for sure you can never beat internal memory execution, but what is the need? We have XiP from external memories, we have caches, large internal SRAM to load critical code, and lastly fast memory interfaces. This allows external code execution with zero wait execution.

We have done test on coremark with different memory setups, and execution from external memories with cache ON, is only few percentage performance decrease. Same study done on FFT, with similar results. And very good results indeed.

This will be available this week in an application note called X-Cube-Perf-H7RS.

So overall it’s a cost benefit analysis you must do. Can you fit your code internally in 1-2 MB flash and xx SRAM, not needing external mem. Then for sure the STM32H7RS is not a good choice.

But do you need the memory scalability and flexibility and ensure future proofing possible FW upgrades needing more memory, then STM32H7RS is a good choice.

Last point, the STM32H7RS does not need an external PMIC, and it still embeds 64Kbytes of flash, and we also ensure to offer from QFN64, LQFP100 all the way up to 225TFBGAs. So we keep the DNA of microcontroller.

If you wonder more about performance, we placed a new AN here: https://www.st.com/resource/en/application_note/an6062-introduction-to-stm32h7rx7sx-system-architecture-and-performance-stmicroelectronics.pdf

 

Part 2 

To be honest: I would not consider to have such a MCU chip. It makes it more complicated on PCB (with a "must" for external memory), with FW (configure now QSPI external memory to keep booting from it), it can result in a slower boot process.

Are you "speculating" that external memories are faster as you could design internally in chip RTL?
I know, internal flash memories are a nightmare for chip designers: power consumption, different architecture and technology in RTL chip design.
Is the hidden message? You cannot speed up internal flash memory even more, you cannot reduce the power consumption even more? You give up and now you let the users decide how to solve it with their schematics and system setup?  LOL (sorry)

But where is the benefit to have such a MCU (with external memory needed)?

• is it "dramatically" faster as existing MCUs? - NO
• is it much more power efficient as with internal flash? - not checked, but assuming - NO (not really on a system view)
• is it easier and more convenient to use? (PCB, external components needed) - for sure! NO

Not in my bucket list to use.

I suggest also: be focused on getting 1 GHz working for a CM7 core, or a RISC-V MCU core in your portfolio...

 

A:

The boot sequence is fast, and one reference is a graphics applications needing large external Flash and RAM in many cases, the boot time, is like any other microcontroller. Just watch it yourself if you have access to a STM32H7S8-DK.

For sure we already have many customers designing on the STM32H7RS and also some going to production in the coming months.

The bullets you are raising seems a bit of scope...

1: No one states its faster or better then internal, but for sure its much larger, flexible, future proof, and in many cases the architecture can deliver very fast, and zero-wait execution.

2: This is not a Ultra low power MCU. Same power scheme as other H7s.

3: more external components always equals less easy PCB design. But the whole point is provide lower cost MCU, freeing BoM on ext components.

 

Part 3….

 get your "message" as: "you have trouble to increase speed on internal flash memory". I understand: Flash memory and SRAM inside chips are very challenging. Do you have also a problem to design chips with faster and larger internal SRAM? When will you tell us to connect also external RAM memory?

If flash memory integrated is your concern: add more SRAM (if you are able to handle internal SRAM with fast speed). Make more SRAM available so that users can load code into SRAM. Make Caches larger... Just reducing the flash memory size without any other improvements and forcing to use external (slower memory) does not sound to be "a benefit".

A:

Its possible to add a large SRAM and large Flash like the STM32U5x9 series, but it means a higher MCU cost, and then less £$ to spend on external memories if needed. For some customers the STM32U599 is the perfect choice, for others its not. Again, we are offering a portfolio with different positionings on: Performance, memory, features, power etc.

And Security:

What is "on-the-fly encryption"?
Do you mean the code on external flash memory can be encrypted? And it will be decrypted when reading code from it?

A:

This is correct. We have expanded the OFTDEC, to MCE (memory crypto engine), so support encrypting and decryption on-the-fly, not needing any SW ciphering.

This is done by HW now both encryption and decryption.

The code or data can be encrypted at the same time as writing it (HW IP = MCE). And decrypted at the same time as reading it.

There is a more info on the security part here: https://wiki.st.com/stm32mcu/wiki/Security:Security_features_on_STM32H7RS_MCUs

 

It raises another question for me:

• how to flash the external flash memory?
• A: The external flash is programmed with a flash loader (Sw component).
• how to encrypt the code going into this external flash memory?
  Is there any debugger, tool support to do so?
  If anybody can encrypt content with the same keys and tools - it would be wide open for everybody to decrypt again.
  Do you consider providing tools for encrypting, flashing code in such external memory, with public and private keys?
• A: The code encryption ca be performed by SW or HW, and you could use the Cubeprogrammer for for debugging. The MCE (memory crypto engine, protects the confidentiality of your code or data stored in the external memory using differentiated or same keys. The cubeprogrammer tools supports provisioning code in external memory. A new application note currently under revision will help you to understand and use the MCE.
• And is the system really secure when "hackers" are able to monitor the data coming from external flash into MCU? Anybody would be able to use a scope, logic analyzer and decode (and decrypt) the data/code from external memory going into MCU. It does not sound really secure for me.
• A: Yes, because the data and code is encrypted.

 

Part 4:

I like the idea on the STM32U5xx MCU: nobody can trace the data/code on a memory (nothing populated on external pins). If somebody tries to hack, to intrude the system (tamper) - there is an option to erase quickly all memory contents, including the flash. This would be really secure!

But if you design a system with all the sensitive data and code on external flash: everybody can let the MCU unpowered, desolder the chip and read it out, decrypt its content. Or: monitor the external interface when running and decrypt on the fly, in parallel.

This is (for me) for sure not an improvement on security: NO, it is a big hole in secure systems! Nobody would be able to realize a snoop on your system, an intrusion. No way to erase all the content in external memory when realizing an "attack" and intrusion.

And how would such an external memory support "trust zone"? Some code and data on secure memory, some as non-secure. It is just ALL one external memory, so that all seems to be on "non-secure" zone. Or do you have option to provide two external memory interfaces? One for secure code and data, the other for non-secure? I would expect to see TWO external memory interfaces, for "trust zone" (secure vs. non-secure). But is it there?

Would it be still possible to separate the FW, code and data into secure and non-secure? To have different memory regions for "trust zone" on (external now) memory? It does not look like it will be there.

If all users have to connect now external flash memory, e.g. via OCTOSPI (or simply QSPI) - is this a violation of "trust zone" approach now? Any hijacked or even "wrong" designed FW can now access and read "secure data/code" in external flash! Just reprogramming the MCU with a different FW can read now all what was "considered secure" before.

I think: this concept of external flash as a need to be connected "violates" the ARM trust zone idea. And there is not a clear demarcation line for secure and non-secure: the external interface, e.g. as OCTOSPI is now mixing secure and non-secure traffic: easy to trace all the data/code with external scopes.

You (as company) seem to divert into directions which are not clear, why and for what improvement. And you seem to open holes for really secure systems. Is this idea driven by a "system design" or just the fact that you cannot make the internal flash faster anymore (because of your design tools used, the technology, e.g. the fabrication process, ...)

Your message is not a good sounding message for me. Sorry (it sounds more like: "we gave up on...")

A:

The H7S security concept is based on the MPU approach ( similar to using cortex A & Linux / android) where all codes and data are stored and computed on external memories (NVM & RAM).

In that case, the global security is based on the global chain of trust for which all code is authenticated first before to launch it.

• In the H7S, the Root of this chain of trust is the ST-iRoT (ROM code)
• It authenticates the first application boot code stored in external NVM.
• This authentication can be done :
  • From the external NVM directly and then use the Execute in Place
  • Using the load in internal RAM and Run solution.
  • à Authenticated application means that nobody did any modification of the code, so no malware.
  • à In case a hacker unsolders the Flash, make modification of the code and resolder it, the authentication process will fail.

 

To protect this first application boot code confidentiality (hacker dumps for example), the MCE IP and its automated encryption/decryption of code & data shall be used. Here, encrypted code means that it will be extremely complex to reverse it. The security assurance level of our MCE is validated by the SESIP level 3 attack level.

So, “monitoring the external XSIP interface” to reverse the code is not possible in practice. Even when the MCE protect external RAM, it will be not possible to reverse the information exchanged on the external bus. This is used for example on the STM32MP135 product and

Regarding the usage of TrustZone, it is a different subject. The TrustZone technology is used to isolate runtime execution of 2 applications running into the same MCU. The concept is that a non-secure application cannot see / dump / modify a secure application. Its access is controlled, and the jump access is clearly defined and protected. We can do the parallel with the Memory Protection Unit on the H7S which is used to isolate tasks within the same MCU and control their different and limited memories accesses. Secure RTOS can easily managed such task isolations in the Viper.

So, H7S with all its security concepts is a secure microcontroller and can be used to execute and protect a wide variety of applications. Now, customers shall understand its concept and used them correctly.

 

 

[ManishNair]

Hi,

The biggest problem with STM32 series is lack of big data handling capability. Do you have any (plan) microcontrollers with Giga Bit ethernet port or RGMII? 

[tjaekel]

Sorry, I am not an STM employee.
"big data handling" and you ask for Giga Bit ethernet when the chip runs with MCU core clock of 600 MHz.
Why?
The MCU cannot generate a network packet so that Giga Bit ethernet could be utilized.
For my experience: even with a 100M ETH - hard to get this throughput really at the end.
And I think, the board might have a 1G ethernet PHY and configured as such one - but getting 1Gbit via ETH with a 600 MHz MCU - can it be possible?

And RGMII is there already, I think, many MCUs and boards use it.

The STM MCUs are mainly "for embedded systems", not for "network routers".

"big data handling" is often not needed, if MCU FW is designed to pre-process "gig data" (and to reduce the amount of data still needed to send to a host for post-processing).

What can be so fast as a connected sensor, camera, ... (?) that 1G ETH would be needed? And who wants to burn so much power at the end (because of this speed)? (besides the fact that such a fast speed as 1Gbps needs also very large buffers and memories, so even more burning power...).

To be honest: I am happy with the STM32 MCUs: they are fast, they have enough memory, they have support for
fast ETH speed (100M)... and all is a topic to design an efficient distributed embedded system, to share the load between MCU as aggregation and pre-processing on a host as post-processing.