stm32h5 chip and nucleo-stm32h563zi board support

[metebalci]

It seems there is no support for STM32H5 yet. Is it currently being worked on ? If not, and if I can, I am considering to add it with the board nucleo-stm32h563zi. I see there is an stm32 folder and also other folders for some series (e.g. stm32h7). Is this a historical difference or is there a reason behind ? To where is it preferred to add stm32h5 support, under stm32 or its own folder stm32h5 ?

[raiden00pl]

stm32 will definitely not be good for stm32h5 because it's Cortex-M33, stm32 holds Cortex-M3/M4 chips. We have stm32l5 and stm32u5 which are Cortex-M33, so most likely stm32h5 could share a directory with these. Personally, I think there is no point in duplicating the stm32 code (almost identical peripherals between families), but I see that others don't really care about it, so you can create a separate folder for stm32h5 and there wont' be a problem.

[alandeassis]

@raiden00pl @metebalci maybe stm32l5, stm32u5 and stm32h5 could be merged in a single stm32h5l5u5 just like we have stm32f0l0g0. What you think? I remember in the past Greg suggest us to create separated directories because stm32 (f1, f2, f4, etc) has many different versions of peripherals then we final code has many #ifdefs and it is had to follow!

[raiden00pl]

I'm not too familiar with C-M33 from ST, but I predict that they use the same versions of peripherals (or almost identical), so combining l5,u5 and h5 into one probably makes sense (the same for stm32wl5 and stm32wb). For stm32 directory, if we remove l1 and f1 (the oldest chips from the stm32 series) everything else is quite similar to each other. Moving all stm32 families into separate directories would result in huge code duplication, which is also a bad solution. Reorganizing support for stm32 is a lot of work that I doubt anyone would want to do (especially for free). The more ST families we support, the bigger the mess will be and I don't really see any chance of fixing it unless there is someone who really, really wants to fix it. I used to have such ambitions, now I don't care too much ;)

[metebalci]

Does it make more sense to work on a standalone H5 support first (and then think about a merge), or work on a merged H5L5U5 support directly ? I am not familiar with L5/U5 to say something about how different they are from H5 but I also dont think there is a major difference that makes it more reasonable to have totally different code for each of these families.

[davids5]

The same core is not the only factor to consider. Take the stm32F7 and stm32H7 are both M7 but have very deferent IP. I think you have to come at this by comparing the IP and register sets. (svd files) If all the IP is the same AND has the same register definition (with only a few changes) it is not a problem to merge this SoC with the others. But if you are going to have to #ifdef h and c file for this chip all over the place do it as a separate directory. If it only adds new IP that is can live in the same directory.

[metebalci]

I will try to compare H563, L552 and U5A5 from their svds. I see the svds of H5 and U5 at ST but not sure about L5 yet.

[davids5]

I will try to compare H563, L552 and U5A5 from their svds. I see the svds of H5 and U5 at ST but not sure about L5 yet.

You can check here https://github.com/cmsis-svd/cmsis-svd-data/tree/main/data

[metebalci]

So I wrote a simple difference taking tool, looking to some obvious things, comparing two svds. I am looking at H563 and U5A5 at the moment. My initial impression is there are all kinds of differences, besides the peripherals that exists only in one as expected, there are peripherals with everything same in both, but also with differences in one or a combination of the following:

• interrupt number
• base address
• number of registers
• register reset value

If I did not make a mistake, these differences happen in most common peripherals, the same ones are rare, like GPIO. What is exactly the redline here, what would definitely indicate these two families should be handled separately ? I did not look into the register fields yet, that is the next thing to do.

[metebalci]

I will try to compare H563, L552 and U5A5 from their svds. I see the svds of H5 and U5 at ST but not sure about L5 yet.

You can check here https://github.com/cmsis-svd/cmsis-svd-data/tree/main/data

Thanks. Someone from ST replied (on ST forums) and said the latest release of SVD files (for L5) can be found here https://www.keil.arm.com/packs/stm32l5xx_dfp-keil/devices/ and I checked it contains a newer version than the one in cmsis-svd repo (1.5 vs. 1.1).

[davids5]

So I wrote a simple difference taking tool, looking to some obvious things, comparing two svds. I am looking at H563 and U5A5 at the moment. My initial impression is there are all kinds of differences, besides the peripherals that exists only in one as expected, there are peripherals with everything same in both, but also with differences in one or a combination of the following:

• interrupt number

Not a reason to add a new directory see https://github.com/apache/nuttx/tree/master/arch/arm/include/stm32h7

• base address

Not a reason to add a new directory see https://github.com/apache/nuttx/blob/master/arch/arm/src/stm32h7/hardware/stm32_memorymap.h

• number of registers

If only new complete IP blocks - Not a reason to add a new directory

• If small changes to an IP block this can be ifdef-ed in at the file level.
• If large changes to an IP block this can be ifdef-ed in at the include level i.e https://github.com/apache/nuttx/blob/master/arch/arm/src/stm32h7/hardware/stm32_gpio.h

• register reset value

Needs to be scrutinized

If I did not make a mistake, these differences happen in most common peripherals, the same ones are rare, like GPIO. What is exactly the redline here, what would definitely indicate these two families should be handled separately ? I did not look into the register fields yet, that is the next thing to do.

[metebalci]

I skipped the differences for things like interrupt number, base address etc. Now mostly looking at registers and fields. I attached two files, these list a peripheral if both MCUs contain the peripheral but there is a difference in corresponding SVDs. The difference can be different registers (only names checked), or the same registers contain different fields (not names but bit size, width and access if specified).

It looks to me like H563 is more similar to U5A5 (but it might be due to this particular L5 MCU, I am not familiar with its features).

Many of the differences seem to be due to how SVD is created even though they look same (the fields of registers are grouped/named differently) or due to bit position/size differences (for example CRS_CR.TRIM is 1 bit larger in H563).

I did not look in detail and not familiar with all the peripherals but still I think it makes sense to combine or at least try to combine these, H5/U5/L5.

The format of the files:

PERIPHERAL
        REG: 1-2: FIELD-bits

1-2 means the register exists in both MCUs but the fields are different, 1-2=MCU 1 comparing to MCU 2, and 2-1 vice versa. 1 or 2 means the register only exists in MCU 1 or MCU 2.

H563_vs_U5A5.txt H563_vs_L552.txt

[davids5]

If the SVD format is an issues. It my be good to compare them in the reference manual pages for the IP blocks. There is a summary page called the "register map" for each IP block. Right away you can see if it is a differing versions of IP or if a reserved bit in one chip is now used in another.

Here is an example of a different version of IP.

F7 ADC

H7 ADC

We took an approach to try to version IP (in other architectures as well). Some vendors take a "less transistors" approach NXP where we have to abstract the feature with a \HAS\ flag. Or worse each GPIO is configured off of 5 different register bases and none are regular, in fact different ports may be off of different bases. HW complexity low. SW complexity is high and error prone.

Whereas others vendors take a regular register set approach. With ST All the GPIO's registers are in the same order, grouped together and the only change a different base address per port. HW complexity slightly higher SW complexity is low.

The HAS abstraction and IP versioning methods reduces ifdef rash and allows sharing versions of IP blocks across chips with out having to add that chip to a long line of ifdefs in each drivers .h and . c files.

There is one '#if defined(STM32_HAS_yada)' and any chip that supports a yada just defines it in it chip.h or Kconfig. files.

[metebalci]

The SVDs look OK to me other than the issues I mentioned. I can see similar information like I am looking to register maps and it is easier to see this by comparing SVDs (and it is mostly not manual).

I saw and like the versioned IP approach but I did not look in detail (dont know exactly the differences). I think after comparing SVDs or register maps the next step is to look in detail and do something like this. Maybe for someone more familiar with the MCUs and the codebase it might be better to directly combine them while adding H5 support, but I will try to add H5 first.

[acassis]

@metebalci yes, follow the safe path! If in the future someone more familiar with these MCUs differences decide to merge it, he/she will do so.

[stbenn]

Has there been any progress on this recently? @kywwilson11 and I starting work on porting the H5. Should we post in this issue or create a new one?

[metebalci]

@stbenn I worked on it a bit but then had to work on other things. So, no progress from me.

[acassis]

@metebalci I suggest you to share what you did and maybe @stbenn and @kywwilson11 could use it as base

[metebalci]

@acassis I dont have something to be used as base.