What main gotchas are there going STM32F4xx to STM32H7xx - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: September 17, 2024, 03:27:18 pm
content: 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 exampleCode:{__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 seeCode:/* 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/0D73W000001PMYnSAOI am not planning on doing anything radical likezero-copyETH/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 websiteThe 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?

author: AndyC_772
author_rank: Super Contributor
timestamp: September 17, 2024, 07:09:55 pm
content: 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.

author: gpr
author_rank: Contributor
timestamp: September 17, 2024, 08:23:11 pm
content: Quote from: AndyC_772 on September 17, 2024, 07:09:55 pmBe careful with that, DTCM doesn't work with DMA, at least on some models of H7. Refer to documentation if unsure.

author: rhodges
author_rank: Frequent Contributor
timestamp: September 18, 2024, 12:24:11 am
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: September 18, 2024, 06:22:56 am
content: QuoteI 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/#msg4965922I looked at the H7 specs and it is about 2x the power at 480MHz versus 168MHz for the 32F4.QuoteThis 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 18, 2024, 11:24:43 am
content: Quote from: gpr on September 17, 2024, 08:23:11 pmBut 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.

author: betocool
author_rank: Regular Contributor
timestamp: September 18, 2024, 02:20:50 pm
content: 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

author: Siwastaja
author_rank: Super Contributor
timestamp: September 18, 2024, 02:45:06 pm
content: 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 butthatwould be pretty extreme use of DMA).

author: peter-h
author_rank: Super Contributor
timestamp: September 18, 2024, 05:29:43 pm
content: QuoteIf 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.QuoteWhat is a "pro"?What is news to me is this on the STM websiteThe 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?

author: Siwastaja
author_rank: Super Contributor
timestamp: September 18, 2024, 06:34:36 pm
content: Quote from: peter-h on September 18, 2024, 05:29:43 pmI 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.

author: peter-h
author_rank: Super Contributor
timestamp: September 18, 2024, 09:17:05 pm
content: 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 cacheisnormally very effective.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 18, 2024, 09:38:22 pm
content: 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?

author: peter-h
author_rank: Super Contributor
timestamp: September 18, 2024, 10:32:24 pm
content: Probably yes, the VGT6. It is only ten bob more (1k) than the 32F417VGT6.

author: dietert1
author_rank: Super Contributor
timestamp: September 18, 2024, 10:35:23 pm
content: 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

author: peter-h
author_rank: Super Contributor
timestamp: September 19, 2024, 06:13:20 am
content: Good tips - thanks.QuoteI 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 19, 2024, 06:24:08 am
content: Quote from: peter-h on September 19, 2024, 06:13:20 amI 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.

author: peter-h
author_rank: Super Contributor
timestamp: September 19, 2024, 06:47:31 am
content: 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.pdfsuggests that power can be applied via VCAP1+VCAP2 (connected together).This (32F4) suggests there isnota diode on that LDO outputH7 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.

author: dietert1
author_rank: Super Contributor
timestamp: September 19, 2024, 07:24:02 am
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: September 19, 2024, 07:32:04 am
content: Probably useful during development but most embedded systems can't tell you what blew upBTW 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..

author: Siwastaja
author_rank: Super Contributor
timestamp: September 19, 2024, 08:06:38 am
content: Quote from: peter-h on September 19, 2024, 07:32:04 amOh, 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.

author: wek
author_rank: Frequent Contributor
timestamp: September 19, 2024, 09:05:26 am
content: Quote from: peter-h on September 18, 2024, 05:29:43 pmProbably none (here see pins 19..49):  TBH for this particular package, there is pin compatibility (bar the devil in the details) between 'F7 and 'H7 PINSTM32F746VGTx.xmlSTM32H742V(G-I)Tx.xmlSTM32F427V(G-I)Tx.xml1PE02PE02PE022PE03PE03PE033PE04PE04PE044PE05PE05PE055PE06PE06PE066VBATVBATVBAT7PC13PC13PC138PC14OSC32_INPC14OSC32_IN (OSC32_IN)PC14OSC32_IN9PC15OSC32_OUTPC15OSC32_OUT (OSC32_OUT)PC15OSC32_OUT10VSSVSSVSS11VDDVDDVDD12PH00OSC_INPH00OSC_IN (PH0)PH00OSC_IN13PH01OSC_OUTPH01OSC_OUT (PH1)PH01OSC_OUT14NRSTNRSTNRST15PC00PC00PC0016PC01PC01PC0117PC02PC02CPC0218PC03PC03CPC0319VSSAVSSAVDD20VREF+VREF+VSSA21VDDAVDDAVREF+22PA00WKUPPA00VDDA23PA01PA01PA00WKUP24PA02PA02PA0125PA03PA03PA0226VSSVSSPA0327VDDVDDVSS28PA04PA04VDD29PA05PA05PA0430PA06PA06PA0531PA07PA07PA0632PC04PC04PA0733PC05PC05PC0434PB00PB00PC0535PB01PB01PB0036PB02PB02PB0137PE07PE07PB02BOOT138PE08PE08PE0739PE09PE09PE0840PE10PE10PE0941PE11PE11PE1042PE12PE12PE1143PE13PE13PE1244PE14PE14PE1345PE15PE15PE1446PB10PB10PE1547PB11PB11PB1048VCAP_1VCAPPB1149VSSVSSVCAP_150VDDVDDVDD51PB12PB12PB1252PB13PB13PB1353PB14PB14PB1454PB15PB15PB1555PD08PD08PD0856PD09PD09PD0957PD10PD10PD1058PD11PD11PD1159PD12PD12PD1260PD13PD13PD1361PD14PD14PD1462PD15PD15PD1563PC06PC06PC0664PC07PC07PC0765PC08PC08PC0866PC09PC09PC0967PA08PA08PA0868PA09PA09PA0969PA10PA10PA1070PA11PA11PA1171PA12PA12PA1272PA13PA13(JTMS/SWDIO)PA1373VCAP_2VCAPVCAP_274VSSVSSVSS75VDDVDDVDD76PA14PA14(JTCK/SWCLK)PA1477PA15PA15(JTDI)PA1578PC10PC10PC1079PC11PC11PC1180PC12PC12PC1281PD00PD00PD0082PD01PD01PD0183PD02PD02PD0284PD03PD03PD0385PD04PD04PD0486PD05PD05PD0587PD06PD06PD0688PD07PD07PD0789PB03PB03(JTDO/TRACESWO)PB0390PB04PB04(NJTRST)PB0491PB05PB05PB0592PB06PB06PB0693PB07PB07PB0794BOOT0BOOT0BOOT095PB08PB08PB0896PB09PB09PB0997PE00PE00PE0098PE01PE01PE0199VSSVSSVSS100VDDVDDVDDJW

author: dietert1
author_rank: Super Contributor
timestamp: September 19, 2024, 09:52:50 am
content: 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

author: peter-h
author_rank: Super Contributor
timestamp: September 19, 2024, 11:39:00 am
content: 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.Thankswek- I did wonder

author: asmi
author_rank: Super Contributor
timestamp: September 19, 2024, 02:00:51 pm
content: 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).

author: peter-h
author_rank: Super Contributor
timestamp: September 19, 2024, 02:40:33 pm
content: 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

author: asmi
author_rank: Super Contributor
timestamp: September 19, 2024, 04:04:50 pm
content: Quote from: peter-h on September 19, 2024, 02:40:33 pmThe idea is that this amount of flash is enough for bootloader, while the main application is supposed to go to the external QSPI/Octo-SPI flash, which is MUCH cheaper than embedding more flash into the MCU. So it's a cost-saving measure. The new STM32H7R3/S3/R7/S7 have even less flash - only 64K, which is still plenty to configure external memory interfaces and launch the main application from external flash. These are very interesting parts - powerful 2.5D GPU, fast M7 core. I guess they figured you will have to have some sort of external memory anyway to store all those graphics assets, so you might as well use the same external memory for the main application code. I think it makes sense, so I've ordered a disco board to play around with it when I will have some spare time.Quote from: peter-h on September 19, 2024, 02:40:33 pmIf properly designed, they don't create many problems.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 19, 2024, 06:49:25 pm
content: A tiny SMPS contained within some square millimeters is going to be a much easier pass than any SMPS converting, say, 12V input into 5V or 3.3V or whatever you might have on your board edge. If you follow datasheet example layout and don't make some ridiculous loop stunt at the design, it's going to pass.

author: peter-h
author_rank: Super Contributor
timestamp: September 20, 2024, 06:48:09 am
content: Gosh you are right about them being cheaper - STM32H730VBT6 is under £4 1k+. That is about 1/2 the expected cost for a part with 1MB FLASH.The internal SMPS probably also solves the issues with power supply sequencing.

author: Datom
author_rank: Contributor
timestamp: September 20, 2024, 06:51:24 am
content: I think it's the difference between MPU, DMA, and Cache. My current project is using H743, which has multiple memory areas, so I need to pay attention to the memory that DMA can access. When using F429, I don't need to worry about these. Additionally, the differences in peripherals can be reduced through CubeMX and HAL.

author: peter-h
author_rank: Super Contributor
timestamp: September 20, 2024, 07:43:25 am
content: Does the H7 range have more flexibility on the alternate function mapping?For example in my project I wanted four UARTs, and to get that I had to (QFP100 package) lose SPI1, which seemed fine until I discovered much later that SPI1 can do 42MHz whereas SPI2 and 3 can do 21MHz, which is quite relevant if driving an 80MHz-capable SPI FLASH implementing a FAT file systemI could answer this Q by spending time with the many various data sheets but someone might know off hand if the pin muxes have more combinations...

author: Siwastaja
author_rank: Super Contributor
timestamp: September 20, 2024, 08:17:11 am
content: Quote from: peter-h on September 20, 2024, 07:43:25 amIn my opinion, not fundamentally, they still use the same design paradigm:1) List peripheral instances on the wall2) Write pin numbers on darts3) Organize well-being week for new summer trainees4) Make them blindfolded and throw darts facing away from the wall, over their shoulders5) Now you have Alternate Function mappingSo you need to look and hope for the best.Thankfully for H7 series they don't use this same paradigm for DMA channel mapping anymore. Any peripheral is accessible to any DMA stream (see DMAMUX).

author: dietert1
author_rank: Super Contributor
timestamp: September 20, 2024, 08:29:20 am
content: I think they don't care. "If you use more than 50 % of the pins you should get a larger package."By the way, i got the H730 digital video up and running. Now i need to connect the display and write the app. Using CubeMX and 300 MHz core clock it came out with only 1.1 V core voltage and runs completely cool. Maybe this time i can omit the external switcher.Regards, DieterEdit: With internal 1.1 V LDO supply is 60 mA from 3.3 V, with external switcher that drops to 30 mA.

author: Datom
author_rank: Contributor
timestamp: September 20, 2024, 08:33:48 am
content: Quote from: peter-h on September 20, 2024, 07:43:25 amPeripheral reuse may not be more flexible, but the H7 series has multiple UART, such as 9 UART in H743/H750, which may solve your problem

author: Siwastaja
author_rank: Super Contributor
timestamp: September 20, 2024, 09:25:03 am
content: Yeah, absolutely ridiculous number of peripherals helps with mapping problems.Instead of 9 UARTs it would have been cheaper and simpler to implement say 5 UARTs and add 4 more AF mappings for them for the same end result and some saved gates, but maybe "9 UARTs" sounds sexier on datasheet or marketing leaflet than "less crappy AF mapping than before".

author: peter-h
author_rank: Super Contributor
timestamp: September 20, 2024, 10:00:02 am
content: Very funny replies - thank youAFAIK the higher numbered peripherals are not accessible on say a QFP100. From vague memory, you can have ADC1 2 and maybe 3 and that's it. No way to access ADC6 (or whatever). You simply cannot map it.I solved the general expansion requirement with SPI3, which is supported with the RTOS with a mutex and dynamically re-initialised, so it is thread-safe. Amazingly, it works great. Some devices use a 650kHz clock, some 21MHz, some 10.5MHz, etc. But I found you need to use the same SPI mode for all (e.g. where clock is parked) and usually this works despite what data sheets say.

author: langwadt
author_rank: Super Contributor
timestamp: September 20, 2024, 10:09:42 am
content: Quote from: peter-h on September 20, 2024, 07:43:25 amor you just fire up STMcube make a dummy project and see what peripherals each pin can connect to and/or what peripherals gets a red cross when others are enabled

author: peter-h
author_rank: Super Contributor
timestamp: September 20, 2024, 01:05:30 pm
content: Cube MX, yes...