What main gotchas are there going STM32F4xx to STM32H7xx

[peter-h]

My project is done on the 32F417 and I see no immediate need to go to the H7, but it does seem to be a way to get a longer product life, as well as getting about 3x more speed.

Looking back over the last few years I recall many gotchas, mainly related to different caching mechanisms. For example

Code: [Select]

{
 __asm volatile( "dsb" ::: "memory" );
 __asm volatile( "wfi" );
 __asm volatile( "isb" );
}
Above is from the FreeRTOS port but IIRC DSB doesn't do anything on the 32F4. Then in the ETH low level I see

Code: [Select]

/* Set Own bit of the Tx descriptor Status: gives the buffer back to ETHERNET DMA */
 //__DMB();
 heth->TxDesc->Status |= ETH_DMATXDESC_OWN;
 /* point to next descriptor */
 //__DMB();
 heth->TxDesc = (ETH_DMADescTypeDef *)(heth->TxDesc->Buffer2NextDescAddr);
where the DMB also does nothing hence is commented-out. But few people seem to really know... Some here: https://community.st.com/s/question/0D73W000001PMYnSAO

I am not planning on doing anything radical like zero-copy ETH/LWIP, which incidentally (for the H7)  I believe is the only 32x code that somebody spent a lot of time on fixing the bugs.

Other things I recall are not going to break code e.g. some H7 chips can do DMA to the CCM, which is nice.

What is news to me is this on the STM website

The STM32H7 single-core and value lines are pin-to-pin compatible with the STM32F7 series and STM32F4 series for the most common packages.

I wonder which chips that is true for?

[AndyC_772]

The need for ISB / DSB instructions is an important one you've already spotted.

Some areas of memory are cacheable, and some aren't. Maintaining cache coherency is up to you. If you use DMA, it's best to use tightly coupled memory, which isn't cached but does run at full speed IIRC.

Do check the difference in power consumption - H7 gets warm, F4 doesn't to any great degree.

[gpr]

If you use DMA, it's best to use tightly coupled memory, which isn't cached but does run at full speed IIRC.

Be careful with that, DTCM doesn't work with DMA, at least on some models of H7. Refer to documentation if unsure.

[rhodges]

In some thread about cache coherency, I said that MIPS was fun. But that was really sarcastic. Keeping coherency between the cached memory and physical memory needed attention in the device drivers. I have worked with STM32, but not with the advanced cache devices. I suggest care with physical and cached memory.

[peter-h]

H7 gets warm, F4 doesn't to any great degree

I am seeing CPU temp +47C with Tamb of +20C, running fairly normal sort of code, RTOS, context here:
https://www.eevblog.com/forum/microcontrollers/freertos-where-should-the-cpu-be-spending-most-of-its-time/msg4965922/#msg4965922
I looked at the H7 specs and it is about 2x the power at 480MHz versus 168MHz for the 32F4.

Keeping coherency between the cached memory and physical memory needed attention in the device drivers. I have worked with STM32, but not with the advanced cache devices. I suggest care with physical and cached memory.

This seems to be the biggest concern but what kind of code would bite you? One obvious one is moving data using code, with the data being put in RAM by DMA - as in ETH low level code. But looking at the above stuff I posted it seems more subtle.

[Siwastaja]

If you use DMA, it's best to use tightly coupled memory, which isn't cached but does run at full speed IIRC.

Be careful with that, DTCM doesn't work with DMA, at least on some models of H7. Refer to documentation if unsure.

But on the other hand the main SRAM behind the AXI bus is really fast, too. IIRC the access is only at half f_cpu (e.g. 240MHz) but then again the bus is 64 bits wide. Enabling data cache for main SRAM is probably such small improvement that it usually isn't worth it. In special cases where it matters, it's a better idea to just use DTCM and not having to think about coherency.

Like this: when DMA is needed or when absolute maximum performance is not necessary --> main AXI SRAM. When DMA is not needed AND maximum performance is needed --> DTCM.

Even just putting stack in DTCM already reduces pressure on the main SRAM (useful if you have on-going DMA) and maximum possible performance for local variables.

Also, these MCUs have so much ITCM you can just put large parts of your program there without having to much think about it. Like, all ISRs and anything that even remotely feels like needing a performance boost. Easy performance increase and again no need to think about caches or flash latency.

So as usual, I advice: i-cache is for running large programs out of external flash (especially slow like SPI flash), d-cache is for data in slow external memory.

[betocool]

I went from an F7 to an H7 years ago.

Gotchas:
- Memory Management Unit, could not get Ethernet working with their example, but there was a workaround.
- DMA is a different beast with the DMAMUX. And memory spaces, gotta be careful where you write what.
- Ended up declaring some spaces in the linker file in memory.

Pros:
- Man that thing is fast. I'm transferring 96KHz 32-bit audio in real time to a PC, no sweat, over TCP. I have a custom built ADC / DAC hat for a nucleo that allows me to record from my stereo in the living room to my PC in the office over LAN.
- Fast... but I already said that.

Mind you, this was a few years ago, I got one of the first H7s when they came out in 2017 I think. Still have the same Nucleo. Still works. Maybe these days it's easier than back then.

The application for me was pretty straightforward, for what I needed and wanted, it's pretty cool.

Cheers,

Alberto

[Siwastaja]

AFAIK MMU is disabled by default so it can only be a pro.

DMAMUX is the greatest thing since sliced bread, finally the correct way to do the DMA mapping. It was more than once before that I painted myself in a corner with STM32 where you have committed to a PCB layout and peripheral mapping just to find out that two unrelated peripherals can't use DMA at the same time because of very limited mapping options. With the H7 you don't have to check beforehand, any peripheral can always use DMA (as long as you don't actually run out of channels but that would be pretty extreme use of DMA).

[peter-h]

maximum possible performance for local variables.

If using RTOS, the task stacks are not on the "general stack"; they are in the RTOS task area. On the 32F4 I am using the 64k CCM for that and that fits well with my ~20 tasks (I have a GUI verification tool for checking stack usage). The main gotcha is that DMA can't access the CCM, so one needs to be careful to not put buffers used for SPI in an RTOS task's local variable stack. The H7 solves this.

MMU is disabled by default so it can only be a pro.

What is a "pro"?

What is news to me is this on the STM website

The STM32H7 single-core and value lines are pin-to-pin compatible with the STM32F7 series and STM32F4 series for the most common packages.

I wonder which chips that is true for?

[Siwastaja]

MMU is disabled by default so it can only be a pro.

What is a "pro"?

I mean betocool listed MMU as a gotcha, as opposed to some "pro"s he listed below. But IMHO because MMU is disabled by default it should not give you any gotcha's, but behave like MMU did not exist like in simpler parts. Then you can, if you so wish, enable it to add some extra protection against programming mistakes (like me accidentally writing to address 0, which on STM32H7 is not an invalid "NULL" pointer, but instead maps to ITCM, IIRC, and thus overwrites some of your program code).

This is I think similar to how some people say caches make parts like STM32H7 series difficult, but again my response is these things boot with caches disabled so they should cause no harm whatsoever. Just like having a JPEG codec or CAN peripheral do not harm you when you don't need them. Start small and add stuff step-by-step, and well-equipped microcontrollers are not that scary after all.

[peter-h]

Surely a data cache is unlikely to make much of a difference, if the RAM is fast.

I know that on the 32F417, running code from RAM is actually a bit slower than from FLASH, because the FLASH cache is so effective. But a code cache is normally very effective.

[SiliconWizard]

From what I get, the L1 cache in the STM32H7 (at least for the single-core variants that I had a look at) is only used for Flash access and otherwise external memory (external RAM/Flash), not for internal RAM. So that shouldn't bother you.

I suppose your main interest is something like the STM32H742?

[peter-h]

Probably yes, the VGT6. It is only ten bob more (1k) than the 32F417VGT6.

[dietert1]

Some months ago i implemented a H743 with FreeRTOS and LWIP app (fiber GPIB interface), starting from a http server example in their H7 repository. It went smooth. For somebody used to STM32 development, the H7 won't be much different.
I solved the MCU temperature problem adding a small external switcher for the 1.2 V core supply. I could disable the MCU internal LDO in CubeMX.
Another issue i remember was failure to power on without debugger connected. It did not work until i raised the voltage detection level to 2.85 V. Took me some time, as those settings are well protected.
And of course the usual nitty gritty like RTC battery charging and so on.
Today i received PCBs for making a graphics card for a TFT without video memory. This time it's a STM32H730 whose LTDC peripheral shall generate digital video to drive the TFT.

Regards, Dieter

[peter-h]

Good tips - thanks.

I solved the MCU temperature problem adding a small external switcher for the 1.2 V core supply. I could disable the MCU internal LDO in CubeMX.

I totally forgot about that. That should more than halve the CPU power draw! The LDO is dropping 3.3V to 1.2V (1.8V on the 32F4). But isn't there some issue with rail voltage sequencing? Also, this feature is available only on packages featuring the BYPASS_REG pin i.e. the 176-pin one which is probably why I never did anything with it.

[Siwastaja]

I solved the MCU temperature problem adding a small external switcher for the 1.2 V core supply. I could disable the MCU internal LDO in CubeMX.

I totally forgot about that. That should more than halve the CPU power draw! The LDO is dropping 3.3V to 1.2V (1.8V on the 32F4). But isn't there some issue with rail voltage sequencing? Also, this feature is available only on packages featuring the BYPASS_REG pin i.e. the 176-pin one which is probably why I never did anything with it.

I have done this on many projects involving H750 and H743 and don't remember any problems with power sequencing: basically 3.3V and 1.2V switchers out of common 5V bus. I have been under impression that no ill effects occur even when you feed external power to VCAP pins even with internal regulator operating during the time before you can disable it in your init code. Therefore I never used the BYPASS_REG control pin, and used smaller pin count packages just fine. But please double-check, maybe what I did was wrong and I have been just lucky. Some hundreds of units have worked fine for years anyway.

Whether you save or lose power depends on how much you use low-power modes. For a project which is awake running algorithms most of the time, the savings are obvious with a Vcore switcher. On the other hand if you sleep a lot and wake up for small bursts, then you lose the automagic Vcore voltage reduction / disabling functionality, unless you externally implement all that in your switcher circuit and that would get more complicated.

[peter-h]

Interesting. Presumably the ST LDO has a diode on its output, so feeding 1.2V up the output with the 3.3V rail at zero doesn't do damage. Most regulators won't take that; in my current project I am using a Ricoh R1191 to get this diode blocking.

Otherwise one would connect a schottky diode between 1.2V and 3.3V, normally reverse-diased.

https://www.st.com/resource/en/application_note/an4488-getting-started-with-stm32f4xxxx-mcu-hardware-development-stmicroelectronics.pdf suggests that power can be applied via VCAP1+VCAP2 (connected together).

This (32F4) suggests there is not a diode on that LDO output



H7 doc states that all available VCAP pins should be interconnected for external power, and their DISCO board interconnects them anyway. It's a mess and many people are asking questions about it online.

And there are some debugger issues. Anyway, this is digressing, though relevant to the H7 due to the higher power.

[dietert1]

Also the F4 didn't have the MPU of the H7. The example i used provided the MPU configuration and CubeMX also supports the MPU.

[peter-h]

Probably useful during development but most embedded systems can't tell you what blew up

BTW is there no way to make the F4 do a trap on a FLASH write? I know it will do one on invalid address e.g. writing to 0x00000000 - the main null pointer thing. What you can't do is prevent e.g. stack execution but that would be nontrivial with an RTOS unless it reprogrammed the MPU on a task switch..

[Siwastaja]

Probably useful during development but most embedded systems can't tell you what blew up

BTW is there no way to make the F4 do a trap on a FLASH write? I know it will do one on invalid address e.g. writing to 0x00000000 - the main null pointer thing. What you can't do is prevent e.g. stack execution but that would be nontrivial with an RTOS unless it reprogrammed the MPU on a task switch..

Oh, MMU interrupt handler which writes some debug value (e.g. address which was written to) in a non-cleared piece of RAM, then reboots is not too many lines of code and can really save the day compared to memory corruption. Once you think about it, it's quite obvious to protect code areas after you have initialized them; self-modifying code is very rarely used.

[wek]

What is news to me is this on the STM website

The STM32H7 single-core and value lines are pin-to-pin compatible with the STM32F7 series and STM32F4 series for the most common packages.

I wonder which chips that is true for?

Probably none (here see pins 19..49): [EDIT] TBH for this particular package, there is pin compatibility (bar the devil in the details) between 'F7 and 'H7 [/EDIT]

PIN	STM32F746VGTx.xml	STM32H742V(G-I)Tx.xml	STM32F427V(G-I)Tx.xml
1	PE02	PE02	PE02
2	PE03	PE03	PE03
3	PE04	PE04	PE04
4	PE05	PE05	PE05
5	PE06	PE06	PE06
6	VBAT	VBAT	VBAT
7	PC13	PC13	PC13
8	PC14OSC32_IN	PC14OSC32_IN (OSC32_IN)	PC14OSC32_IN
9	PC15OSC32_OUT	PC15OSC32_OUT (OSC32_OUT)	PC15OSC32_OUT
10	VSS	VSS	VSS
11	VDD	VDD	VDD
12	PH00OSC_IN	PH00OSC_IN (PH0)	PH00OSC_IN
13	PH01OSC_OUT	PH01OSC_OUT (PH1)	PH01OSC_OUT
14	NRST	NRST	NRST
15	PC00	PC00	PC00
16	PC01	PC01	PC01
17	PC02	PC02C	PC02
18	PC03	PC03C	PC03
19	VSSA	VSSA	VDD
20	VREF+	VREF+	VSSA
21	VDDA	VDDA	VREF+
22	PA00WKUP	PA00	VDDA
23	PA01	PA01	PA00WKUP
24	PA02	PA02	PA01
25	PA03	PA03	PA02
26	VSS	VSS	PA03
27	VDD	VDD	VSS
28	PA04	PA04	VDD
29	PA05	PA05	PA04
30	PA06	PA06	PA05
31	PA07	PA07	PA06
32	PC04	PC04	PA07
33	PC05	PC05	PC04
34	PB00	PB00	PC05
35	PB01	PB01	PB00
36	PB02	PB02	PB01
37	PE07	PE07	PB02BOOT1
38	PE08	PE08	PE07
39	PE09	PE09	PE08
40	PE10	PE10	PE09
41	PE11	PE11	PE10
42	PE12	PE12	PE11
43	PE13	PE13	PE12
44	PE14	PE14	PE13
45	PE15	PE15	PE14
46	PB10	PB10	PE15
47	PB11	PB11	PB10
48	VCAP_1	VCAP	PB11
49	VSS	VSS	VCAP_1
50	VDD	VDD	VDD
51	PB12	PB12	PB12
52	PB13	PB13	PB13
53	PB14	PB14	PB14
54	PB15	PB15	PB15
55	PD08	PD08	PD08
56	PD09	PD09	PD09
57	PD10	PD10	PD10
58	PD11	PD11	PD11
59	PD12	PD12	PD12
60	PD13	PD13	PD13
61	PD14	PD14	PD14
62	PD15	PD15	PD15
63	PC06	PC06	PC06
64	PC07	PC07	PC07
65	PC08	PC08	PC08
66	PC09	PC09	PC09
67	PA08	PA08	PA08
68	PA09	PA09	PA09
69	PA10	PA10	PA10
70	PA11	PA11	PA11
71	PA12	PA12	PA12
72	PA13	PA13(JTMS/SWDIO)	PA13
73	VCAP_2	VCAP	VCAP_2
74	VSS	VSS	VSS
75	VDD	VDD	VDD
76	PA14	PA14(JTCK/SWCLK)	PA14
77	PA15	PA15(JTDI)	PA15
78	PC10	PC10	PC10
79	PC11	PC11	PC11
80	PC12	PC12	PC12
81	PD00	PD00	PD00
82	PD01	PD01	PD01
83	PD02	PD02	PD02
84	PD03	PD03	PD03
85	PD04	PD04	PD04
86	PD05	PD05	PD05
87	PD06	PD06	PD06
88	PD07	PD07	PD07
89	PB03	PB03(JTDO/TRACESWO)	PB03
90	PB04	PB04(NJTRST)	PB04
91	PB05	PB05	PB05
92	PB06	PB06	PB06
93	PB07	PB07	PB07
94	BOOT0	BOOT0	BOOT0
95	PB08	PB08	PB08
96	PB09	PB09	PB09
97	PE00	PE00	PE00
98	PE01	PE01	PE01
99	VSS	VSS	VSS
100	VDD	VDD	VDD

                             
                                     

JW

[dietert1]

Even if the MCUs are only 90% pin-to-pin compatible they want developers to think about it. The H7 is a superset of the F4 and one should think about using it - like Peter does. I mean they also have the L4 and the G4 lines and might want to discontinue the F4 sooner or later.

Regards, Dieter

[peter-h]

The F407 is made by the chinese too so probably safe for many years. ST currently guarantee 10 years, from now, IIRC. The 417, maybe not as safe, but my box doesn't "need" the fast hardware AES256, and the F4 hardware crypto is usable only for AES; there is no RSA etc support which would make a big difference. Software AES is about 800k bytes/sec which is plenty for embedded work.

Thanks wek - I did wonder

[asmi]

Most H7 have variants with integrated SMPS, I always pick them as you only need a few extra parts, but get some serious efficiency boost. One thing to watch out for is that in some parts (I encountered it in STM32H747XI) integrated SMPS can not do the full range of VOS and so some run modes might not be available (in abovementioned part "boosted performance" run mode is only available if you use LDO).

[peter-h]

Mostly dual core have it, and the 730 has (the one with very little FLASH... I wonder why they did that version?).

An external LC is basically all that's needed.

That probably brings some interesting EM compatibility issues; usually most radiation out of a product is the switching power supply