What main gotchas are there going STM32F4xx to STM32H7xx

[asmi]

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

The 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.

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

If properly designed, they don't create many problems.

[Siwastaja]

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.

[peter-h]

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.

[Datom]

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.

[peter-h]

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 system

I 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...

[Siwastaja]

Does the H7 range have more flexibility on the alternate function mapping?

In my opinion, not fundamentally, they still use the same design paradigm:
1) List peripheral instances on the wall
2) Write pin numbers on darts
3) Organize well-being week for new summer trainees
4) Make them blindfolded and throw darts facing away from the wall, over their shoulders
5) Now you have Alternate Function mapping

So 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).

[dietert1]

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, Dieter

Edit: With internal 1.1 V LDO supply is 60 mA from 3.3 V, with external switcher that drops to 30 mA.

[Datom]

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 system

I 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...

Peripheral 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

[Siwastaja]

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".

[peter-h]

Very funny replies - thank you

AFAIK 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.

[langwadt]

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 system

I 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...

or 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

[peter-h]

Cube MX, yes...