How to differentiate between STM32H743 and H745 at runtime?

[CHild.1]

Is there any way to find out if the code is executed on a H743 (single core) or a H745 (dual core) MCU at runtime?

If I am not mistaken the DBGMCU_IDC (Identity code register) has the same value for both MCUs. Is there any other register which I could check?

If not, is there any other way to find out if there is a second M4 core from the application running on the M7 core?

[Tesla DeLorean]

Can't say I've checked or had a strong desire to write one code for both uses.

Perhaps check presence of HSEM, or other, peripheral present in one vs the other.

Code running on the M4 should be able to identify it's on that vs an M7. Should be possible for code in the second bank to start in the M4, and also communicate via RAM shared in common.

[CHild.1]

Thanks for the ideas

Unfortunately HSEM is present on both MCUs. Even more unfortunately the M7 coreID is = 3 for both mcus when locking one of the semaphores.

I also tried to read the CM4 boot address from the option byte registers with the hope that they might be different on the H743 but, they also have the H745 default value.

I could not figure out if there is any other peripheral which might be different enough to use it for device identification. Any ideas are welcome.

A different solution would be to use the debug infrastructure to scan for DAPs to identify the cores but, I did not find any info if it is even possible to access the DAPs without going through the jtag/swd interface.

If the M4 core boots I can either lock one of the semaphores or trigger the Sent Event Interrupt to make the M7 application aware of the second core. But, this will not work if the second core does not boot due to the option byte configuration. It would be greate to have a more general approach.

[waclawek.jan]

> How to differentiate between STM32H743 and H745 at runtime?

IMO you can't.

This is IMO the same case as with the "value line" variants - it's the same die, in no way differentiated, except that due to less extensive testing the "missing" features (which in fact are present and unmodified/unobstructed) are not guaranteed to work.

But you know what you've been using, so just program some identification mark (is there OTP or user-usable Option bytes in the 'H7?) during manufacturing.

I of course may be mistaken, I don't use the 'H7 and am not that interested in them either.

JW

[Tesla DeLorean]

The die was always designed to be multi-core, it took ST an extraordinary amount of time to work the bugs/issues out. The first EVAL had DSI too.

I'd say, without a doubt there are bits in one or more registers that could identify if the M4 is available/usable, basically stuck-at-zero/one. I'd sieve for obvious candidates, including in the Option Bytes

[Tesla DeLorean]

>>IMO you can't.

It would surprise me if it couldn't been determine programmatically..

Active measures were taken to disable the M4 cores, and scrub mention of it from the docs for 3 years or so.

[Tesla DeLorean]

Program and configure the chip as if it had TWO cores, if the CM4 starts on a H743 then bonus, wager it won't