Heterogeneous multi-core MCUs

[NorthGuy]

See attached image for stm32h757. Three seperate (interconnected) bus domains...

This is just the way they design things and is not specific to dual core chips. Look at STM32H730 - same three bus domains, but a single core.

[John Celo]

See attached image for stm32h757. Three seperate (interconnected) bus domains...

This is just the way they design things and is not specific to dual core chips. Look at STM32H730 - same three bus domains, but a single core.

What do you think is the reasonable assumption here?

1. They apriori make overengineered, overcomplicated weird busses for single core parts.

2. OR H730 and H750 is simply stm32h757 dual-core design with the m4 core removed (read: disabled), but with all the mess intact.

What do you think?

Other stm32 cortex m7 don't necessarily have this complexity btw.

See attached image for bus matrix of say stm32f72xxx  or stm32f73xxx.

(admittedly, there might be valid reasons to split the bus in multiple domains even for a single core part, but the rationale here isn't instantly obvious).

[NorthGuy]

What do you think is the reasonable assumption here?

1. They apriori make overengineered, overcomplicated weird busses for single core parts.

2. OR H730 and H750 is simply stm32h757 dual-core design with the m4 core removed (read: disabled), but with all the mess intact.

What do you think?

I cannot tell that. I suspect the dies are different because there's no parts with small pin count in STM32H757 family.

D1, D2, and D3 are power domains. The reason for their existence is the ability to turn them on and off as needed. That is why they draw them as three separate bus matrices.

When there's no power domains they draw a single bus matrix, regardless whether this is a single bus or multiple buses.

[Siwastaja]

See attached image for stm32h757. Three seperate (interconnected) bus domains...

This is just the way they design things and is not specific to dual core chips. Look at STM32H730 - same three bus domains, but a single core.

What do you think is the reasonable assumption here?

1. They apriori make overengineered, overcomplicated weird busses for single core parts.

2. OR H730 and H750 is simply stm32h757 dual-core design with the m4 core removed (read: disabled), but with all the mess intact.

Neither. It's just that after certain clock speed, and certain physical size (~ complexity), multiple clock domains and segmented buses become a physical necessity. And being configurable is highly important for MCU power consumption, performance and flexibility, all huge sales arguments. If the complexity was there "just for fun", everyone would use the same init/configuration, but that's not the case. Every application needs different clock tree / peripheral enable / bus matrix config.

It doesn't matter whether the high clock speed and large size come from CPU cores or peripherals. Peripherals are fundamentally the same as CPU - things that connect to the bus, consume silicon area and power, work at a certain clock speed, and do useful things. Peripherals are just fixed function. DMA peripheral, for example, could be described as a hardware version of memcpy().

So being complicated is not just for fun, it's somewhat a necessity (ST however has a track record of adding a tad more than absolutely necessary by reusing their earlier IP in weird mixes with little planning: for example the H750 you mention combines two different kinds of DMA peripheral, one borrowed from their lowest-end series, another borrowed from their mid-to-high range series; I don't think anyone has been able to figure out why.)

I am 99.99% certain H750 does not have a disabled another core in it. The "mess" you describe is not related to having multiple CPU cores, after all.

[John Celo]

D1, D2, and D3 are power domains. The reason for their existence is the ability to turn them on and off as needed. That is why they draw them as three separate bus matrices.

When there's no power domains they draw a single bus matrix, regardless whether this is a single bus or multiple buses.

There is a performance cost for this, though, right?

The M4 (if present on D2) can access and do things faster in that domain (and that's the domain with direct access to peripherals ABP1/ABP2), than the M7 core that isn't directly connected to D2.

Neither. It's just that after certain clock speed, and certain physical size (~ complexity), multiple clock domains and segmented buses become a physical necessity. And being configurable is highly important for MCU power consumption, performance and flexibility, all huge sales arguments. If the complexity was there "just for fun", everyone would use the same init/configuration, but that's not the case. Every application needs different clock tree / peripheral enable / bus matrix config.

Some nxp imx rt1010/1060 parts go up to high clock speeds, I don't think they have the bus split in 3 power domains, and while still pretty sophisticated, the bus doesn't appear to have the same complexity.

I am 99.99% certain H750 does not have a disabled another core in it. The "mess" you describe is not related to having multiple CPU cores, after all.

I would not make this claim unless all (atleast most) cortex m7 single core designs with high clock rate (480mhz+) happen to be stuck with same or similar "mess".

I'm wholly unconvinced that given bus matrix of h750 makes as much sense as it does in case of h757 where D2 has M4 connnected to it. They share almost exactly the same bus topology with very few minor differences. And apparently they use same silicon die (albeit with different config).

[NorthGuy]

D1, D2, and D3 are power domains. The reason for their existence is the ability to turn them on and off as needed. That is why they draw them as three separate bus matrices.

When there's no power domains they draw a single bus matrix, regardless whether this is a single bus or multiple buses.

There is a performance cost for this, though, right?

The M4 (if present on D2) can access and do things faster in that domain (and that's the domain with direct access to peripherals), than the M7 core that isn't directly connected to D2.

There are multiple buses in every domain, and the access speed will depend on how exactly they're connected. The bus topology does matter, but power domains most likely don't, only to the extend that they affect bus topology. Certainly, the way it is drawn on the picture in RM doesn't affect anything.

At any rate, they could've created a multi-core design without power domains just as easily.

[Siwastaja]

I would not make this claim unless all (atleast most) cortex m7 single core designs with high clock rate (480mhz+) happen to be stuck with same or similar "mess".

I'm wholly unconvinced that given bus matrix of h750 makes as much sense as it does in case of h757 where D2 has M4 connnected to it. They share almost exactly the same bus topology with very few minor differences. And apparently they use same silicon die (albeit with different config).

Oh, sure the design of H750 could be simpler. All I'm saying is that there being multiple cores is irrelevant. There are simpler multi-core MCUs, and more complex single-core MCUs. A core in itself can just sit next to another core on the AXI bus, for example. It doesn't mandate having multiple AHB/APB buses, configurable clock ratios / power domains or whatever complexity is there. P in the APB bus literally comes from peripheral which should be a decent hint where the complexity is already coming. All the complexity is to enable the designer to optimize power use and performance with a huge number of different peripherals. Like, LPUART / LPTIM "low power" versions of UART and timer peripherals, and the RTC (battery-backed) power domain are perfect examples of this complexity which originates from heterogenous fixed-function peripherals, not CPU cores.

Whether that complexity is excessive or easy/difficult to use is another discussion, and other manufacturers might have used less complexity and still get nearly the same flexibility.

[Jeroen3]

There are more reasons to have power domains. To switch off areas with defects, this increases yield.

[John Celo]

Oh, sure the design of H750 could be simpler. All I'm saying is that there being multiple cores is irrelevant.

Considering there bus matrix of h757 and h750 are almost exactly the same. (and allegedly shares the same die).

There are two possible scenarios:
1. H757 was result of taking design of H750 and adding second M4 core to it.
2. OR H750 was a result of a design made specifically for dual core H757, but with a second M4 core disabled/removed from it.

If It's (2), then the bus complexity isn't irrelevant and accidental, but makes sense:
1. You can disable D1 domain, and make only M4 core do the work.
2. You can disable D2 domain and M4, and have only M7 core run.
3. D3 is the actual low-power backup domain.

The development process for H750 and H757 is - in lots of ways - very similar, after all it has exactly the same bus, with
more or less the same peripherals accessed in almost exactly the same way.

I doubt that the bus complexity on H750 was summoned accidentally, instead of being downstream from design tailor made for a dual core H757 part.

I don't have 100% conclusive evidence for (2) over (1) however.

Attachment: bus matrix of NXP i.mx rt1170.

[Siwastaja]

Oh, sure the design of H750 could be simpler. All I'm saying is that there being multiple cores is irrelevant.

Considering there bus matrix of h757 and h750 are almost exactly the same. (and allegedly shares the same die).

There are two possible scenarios:
1. H757 was result of taking design of H750 and adding second M4 core to it.
2. OR H750 was a result of a design made specifically for dual core H757, but with a second M4 core disabled/removed from it.

H750 and H757 were indeed released at the same time so it's well possible they share the die or even the M4 core would be just disabled from the H750, that depends entirely on the batch sizes they manufacture and how well they sell (similarly how CPUs have always been labelled differently based on manufacturing yield and market demand).

But my point is, H750 is nearly identical to H743 with less flash, and the H743 came two years earlier; I used it in a design when it was ST's brand new flagship MCU. At that time, no dual-CPU-core version was available. And the H743 had the exact same internal bus design than the H750; the two are almost fully code-compatible.

So that's why I'm quite certain dual-core didn't motivate the H743's bus, power domain and clock domain design. It's of course possible they had a dual-core version in mind even though it took over two more years to release, but the complex bus design is internally coherent already with just the fixed-function peripherals, and ST's track record of making some overcomplicated decisions (partially from design reuse fixation).

[Jeroen3]

If I look at the datasheets of the H570 and H575 the major changes are the amount of RAM and the JPEG decoder and the SMPS.
I suspect it's a cost down release of the same die. Less royalties perhaps.
It then also inherits some features that appear excessive, but are required for the fully featured one.

I know from having worked there that the NXP LPC18 and LPC43 also were the same die. They were really proud of this. But it required many silicon revisions.

[Unixon]

OK, how does a bus architecture affect programming of those MCUs?
Memory mapping of functional blocks to each core could be different and direct accessibility depends on if that peripheral is mapped or not mapped.
What about bridges between buses? Does this only affect access times or should such access be manually managed?

[Siwastaja]

OK, how does a bus architecture affect programming of those MCUs?
Memory mapping of functional blocks to each core could be different and direct accessibility depends on if that peripheral is mapped or not mapped.
What about bridges between buses? Does this only affect access times or should such access be manually managed?

Memory-mapped things "just work", it's not like accessing things behind a bridge would require special instructions if you mean that, but at least two catches come to mind:

(1) initial configuration of clock speeds, power enables etc. Some segment might not be running at all by default (to save energy) and needs to be enabled, and/or you need to figure out clock multipliers/dividers to get the different parts of the chip to operate at speeds that satisfy your needs, and are legal.
(2) in some special cases you may want to guarantee order of operations to different parts (through different bridges / clock domain synchronizers) of the chip, and that requires special operations, like reading back what you just write to ensure the write landed before you go to the next line of code.

[hans]

You can extract info about die IDs/versions from STM32Cube databases.
 https://github.com/esden/stm32cube-database/blob/master/db/mcu/STM32H730VBHx.xml

STM32H723 = DIE483
STM32H730 = DIE483
STM32H747 = DIE450
STM32H750 = DIE450
STM32H757 = DIE450

(and yes the STM32H7x0 parts often only have 64K flash cutting the price in half. But share the same die as their 1-2MB variants)

It of course does not say if ST had put extra features on DIE483 and left them out.. maybe because it was broken or because the sales team decided they did not need to offer the upgraded 550MHz M7 together with a M4 core.. (and thus the D1/D2/D3 was left behind)

ST is very good in incremental refreshes to their line up. Especially the H7 makes various jumps in product numbering, where the H72x/H73x is a newer part which also includes a OctoSPI/HyperBus peripheral. On the other hand, the H757 had some MIPI interfaces which was never to be seen on other parts again (afaik?).

I do believe a combination is about pushing the PDK further to unlock the higher frequency parts. But their position in MCU land is already quite strong, so if they can postpone certain feature sets to a future part/family, then why not. It won't make them any more or less money if they sell all their parts anyway.

If you dive deeper at peripheral RTL then actually STM32s are 90%+ Ctrl+C Ctrl+V jobs. They may refresh a SPI or UART peripheral once every 10-15 years, but once you have generic drivers for them that talk a similar API for your BSPs, then you can easily hop between all families of parts.
And if you don't want to write them, look at frameworks like Zephyr (C/C++) or Embassy (Rust) as they handled a big chunk of work already.
 Usually the ADC/DAC/RCC is specific for a certain family.

The other day I was rapid prototyping some serial adapter. I started out with a STM32F4, built a proof of concept with a STM32L432 nucleo (a slim PCB with enough RAM), but ended up building the adapter module around a STM32F7 (because future scope). All that was needed to hop between these families was the RCC initialization. GPIOs, (LP)UART, I2C, timers, interrupts, etc. operated identically..

Begs the question why some lock themselves into achiac approach of using ST's family-specific HAL. It results in the firmware project locking in to a certain STM32 MPN, while it may very well be an agnostic application (since digital peripherals are identical). Yet parts become slowly more expensive over time... $ $ $ .. excellent supply chain management, ST!
For some reason Microchip PICs are seen as compatible much more often. Perhaps because people still wrote bare metal code and see for themselves that the 4-5 MSSP registers are indeed copy-paste from other PICs..
But I digress.

[paulca]

Th only dual core MCU I have used was the ESP32.  I believe those are near identical cores though.  Same thing however.  Assign roles to each.  Like let the Wifi default to core 0 and you put your audio stuff on Core 1.

So, a lot simplier than, say, a preemtively scheduled general purpose core affinitiy, context switch migration and all that stuff.

[John Celo]

So I did a little bit more reading.

And the reason for 2 buses is simply because Arm Cortex M7 has two bus interfaces:
1. The old AHB bus protocol - I presume many of the peripherals and IP blocks and older designs still use this protocol (or APB bridged through AHB?).
2. And AXI - newer with much higher throughput (and other features).

You could (in theory?) create M7 design that mainly only uses the older AHB interface or only AXI...

But ultimately this isn't a case of ST overengineering and overcomplicating things here for no reason other than to add second core... the two bus interfaces are inherent part of cortex M7.

And M4 can't be connected to same AXI bus as M7 directly, because it simply doesn't have that bus interface.

If you stare at those reference manuals long enough, eventually it all makes sense.

[Unixon]

I'd like to steer this discussion a little bit in direction discussing differences in setting up tools and configuration of project and probably changes to workflow.
Let's say I have one of dual-core STM32H7 on my desk.

Can I use SWD or should I use JTAG? STM32H7 provides one interface of each type.
Can I use OpenOCD and what changes (other than selecting MCU type) should I make to its configuration?
Should there be one or two instances of OpenOCD running?
Can I use GDB to debug a dual-core MCU via OpenOCD?
Should there be two instances of GDB running?

Should I compile and link firmware into two binaries for each core separately or one binary (joint FLASH image) for entire MCU?
Can still use st-link utility? Should I select a target core or just change base address of FLASH?
How else uploading the binaries changes in dual-core configuration?

[Jeroen3]

iirc you need two gdb sessions on one openocd host. One of them connects with the running host.
You should not have the "slave core" flash binaries as that will most certainly reset the first debug session.
Link to a single binary blob.

This was awfully complicated in uvision, I image this being somewhat easier with open source tools today.

The part being dual core should have no effect on flash loading.

[Unixon]

Link to a single binary blob.

The RM for H745 tells me that while two FLASH banks have adjacent address spaces, but the size of each bank is less than reserved address space for some MCU variants.
How should this be addressed at link stage? Can a binary image be sparse, i.e. contain multiple non-adjacent/non-continuous blocks?

[paulca]

This was awfully complicated in uvision, I image this being somewhat easier with open source tools today.

So when you are in a debugger and you hit "Pause" with "Pause all threads" ticked... you don't get multiple stack frames to analyse like on "big iron"?

Oh.  That would makes things tricky.

I recall being very confused when that box got unticked unintentionally.  Although in many cases it is necessary.  ie.  allow the consumer thread to run while you capture the instance spawned off it.

[aeg]

The RM for H745 tells me that while two FLASH banks have adjacent address spaces, the size of each bank is less than reserved address space for some MCU variants.
How should this be addressed at link stage? Can a binary image be sparse, i.e. contain multiple non-adjacent/non-continuous blocks?

Binary image no
Intel hex yes
S-record yes

[Jeroen3]

A .bin cannot skip regions. But a .hex can, in fact it does that all the time. For example, all the empty space (0xFF's) can be skipped.
This is how, for example, you can put OTP/fuses memory in the .hex to be flashed in production.

See the srecord tool for things you can do with .hex files.

[Unixon]

For a single core MCU I have this line in STM32 project to produce Intel HEX image:

Code: [Select]

arm-none-eabi-objcopy -Oihex $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_FILE).hex

I guess at this stage addresses are already hardcoded to a linked binary (elf).
Quick search reveals I can't simply concatenate .hex images but there's a number of 3rd party tools (srecord included) to merge Intel HEX images.
Is this a right way to go?

Will st-link handle this sparse image correctly?

[Jeroen3]

You don't have to work with the hex outputs... You can link the secondary core output as a library project into the primary core.
Or have them both as library into a container project. Then you can link whatever you want using standard linkers.

[Unixon]

I've been also thinking about another related thing.
Many of these complex MCUs have a number of different memories.
This requires special attention to where a compiler puts code and data structures.
At least with memory allocation for variables etc I saw people declaring sections in linker files and using compiler attributes in C/C++ sources to bind data structures to particular memory sections.
Is there a good way to do this multi-section memory management so that sources wouldn't look too hairy?