Stm32u0

[mickael868]

Detailed description

Add support for the STM32U0 targets (STM32U031, STM32U073, STM32U083).

Tested with a STM32U083 target: flash erasing, programing , debugging, and setting breakpoints work.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

[dragonmux]

When you look to fix the note we have left here, please would you review the contribution guidelines and alter your commit messages to match - we don't use hyphens but rather colons, as in (in this case) "stm32u0: ".

[ALTracer]

flash erasing, programing , debugging, and setting breakpoints work.

@mickael868 It is nice to hear that a separate driver is tested to provide flash erasing and programming. Normally debugging and hardware breakpoints are provided by Cortex-M and ADI v5 layers, but it's still the driver's responsibility to poke DBGMCU flags or override reset behaviour.

However, I've fetched your branch that is essentially one functional commit with three fixups not squashed into it (do not do anything about it just yet), and compiled locally for native and native-st-clones only to see reliably a +784 byte size-diff. This is before any option byte support, IIUC.
Have you considered reusing the stm32g0.c driver, and if yes, why not? Does it work (just like with STM32C0) if you only add part ID detection and maybe default option byte values? Of course I don't have a U083/U031 to test on. Refer to PR1408/PR1414 for that happy case.

In any case, I like how this stm32u0.c is written, and I am only a contributor, so you can ignore me -- a bigger, simpler but working driver can be better than a denser spagetti driver with edge cases.

~/g/b/blackmagic (feature/stm32u0)> arm-none-eabi-size build-native/blackmagic_native_firmware.elf.p/src_target_stm32g0.c.o 
   text    data     bss     dec     hex filename
   2514     112       0    2626     a42 build-native/blackmagic_native_firmware.elf.p/src_target_stm32g0.c.o
~/g/b/blackmagic (feature/stm32u0)> arm-none-eabi-size build-native/blackmagic_native_firmware.elf.p/src_target_stm32u0.c.o
   text    data     bss     dec     hex filename
    768       0       0     768     300 build-native/blackmagic_native_firmware.elf.p/src_target_stm32u0.c.o

i.e. native is tight on flash space (129492 used, 1580 free out of 131072), native-st-clones has more room.

Finally, what is stored at 0x1FFF6E50 (STM32U073/83xx), 0x1FFF3E50 (STM32U031xx) and can you hook these two UID_BASE to stm32_uid() common function? You already use FLASH_SIZE from Engineering bytes, might as well expose this, too. Of course, this is not mandatory.

[mickael868]

@ALTracer Indeed, the stm32g0 and the stm32u0 programming sequences look similar. I did not notice that before. IMHO, merging the u0 driver into the g0 driver is a good idea but I will not take the time to do this before late April.

Without this driver, uploading a firmware to a U0 chip using a BMP v2.3 board reports no errors (just the unknown IDCODE warning), but the compare-sections command lists the sections as mismatched.

I thought the commits squashing was performed during the merge, but maybe this is a gitlab option?

[dragonmux]

I thought the commits squashing was performed during the merge, but maybe this is a gitlab option?

It is a project choice. We never squash commits on merge as we actually value the development history and being able to roll things back and revert things if required + having blame work properly. We actually prefer PRs to be built of small atomic commits as a result rather than blob commits (though we ask contributors to use rebase to apply fixup commits to the commit they fixup so we have only buildable commits where possible and tidy up things like include order mistakes as those aren't so valuable to have as individual commits in the merged tree). We then use fast-forward or rebase merge to get the commits onto main.

You can read any of our PRs for examples of what this is like.

[mickael868]

@dragonmux Ok, I understand the squashing policy. If this is merged, I will squash because it is essentially one functional commit, as @ALTracer pointed out.

It is more likely that another PR integrating the U0 driver into the G0 driver will replace this one, no?

I just removed another unused static function and checked that this was the last one by temporarily adding the "-Wunused-function" compiler flag. The src_target_stm32u0.c.o size is now 756B.