Add STM32C0x

[Apehaenger]

Add STM32C0x Summary:

• RCC
• Timer
• ADC
• Device driver Add STM32C0x devices modm-devices#112
• USART
• Examples

---

In relation to #1187, I tried to add STM32C011F6P6 support for a custom PCB.

Well, somehow hard for an ungifted to jump into the internals, who's intention was to use modm for his project ;-)
However, can't become more dumb by trying :-)

Unfortunately I got stuck after a couple of lines and don't know if I missed something to hack in modm or if I made something wrong with my minimal blink example :-/
If I chose a supported MCU it compiles well, but all supported MCU's I found, do also have a board, so...

This is what I get now:

jebeling@lt-je:~/Development/OpenMowerProject/xESC_YF_rev4-adapter/firmware/ext/modm/examples/stm32c0x1/blink$ lbuild build
>> modm: Recomputing device cache...

ERROR: In 'modm:build':

Traceback (most recent call last):
  File "/home/jebeling/Development/OpenMowerProject/xESC_YF_rev4-adapter/firmware/ext/modm/tools/build_script_generator/module.lb", line 251, in post_build
    all_rams = [m for m in linkerscript.get("memories") if "w" in m["access"]]
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'NoneType' object is not iterable

Any hints are welcome ;-)

[salkinium]

You were just missing a dependency on modm:platform:core. That pulls in the startup code etc. Now there is a bunch of compile errors with RCC macros, the modm:platform:rcc module needs to be fixed.

[rleh]

I just created a commit very similar to 89d75c1, but was 30 seconds too late pushing it here 😆

[Apehaenger]

Many thanks for your great help @salkinium and @rleh !!
Will go on trying to fix the compile errors ;-)

[salkinium]

I was kinda wondering why RCC even gets pulled in for your minimal example, and for some reason the modm:platform:gpio module depends on RCC but doesn't use it? It's only required for the delay boot frequencies:

arm-none-eabi/bin/ld: modm/build/stm32c0x1/blink/scons-release/modm/libmodm.a(delay_ns.o): in function `modm::delay_us(unsigned long)':
./modm/src/modm/platform/core/delay_ns.cpp:54: undefined reference to `modm::platform::delay_fcpu_MHz'
arm-none-eabi/bin/ld: ./modm/src/modm/platform/core/delay_ns.cpp:54: undefined reference to `modm::platform::delay_ns_per_loop'

So I defined them in the main.cpp file as a hack, just to get you unblocked for blinky. Would probably still be good to have the RCC module to go up to 48MHz and not stay at 16MHz boot frequency.

[salkinium]

Btw, you can check the dependency graph with lbuild dependencies | dot -Tsvg -Grankdir=BT -o dependencies.svg for the example.

[Apehaenger]

Quite thanks for your quick and helpful suggestions!!

But you're to fast for me or I'm to slow/untalented.

In between I got blinky compiled well but I'm still to unfamiliar with modm and go by the docs step by step.
I currently hang with the basics :-/ scons program https://modm.io/guide/custom-project/#generate-compile-and-upload which drops me "Error: Debug Adapter has to be specified, see "adapter driver" command".

For sure, I do know how to flash the elf file with OpenOCD by hand, but thought to go the modm way, before switching over to CMake and VSCode. So still searching ;-) Turns out that the official OpenOCD 0.12.x doesn't has C0x support. My fault ;-) ... it's running now.

Yes sure! Once I get code running on it, I will try to fix the RCC issues. I also need to adapt the modules/driver for timer, uart, ADC, because my PCB needs them ;-)

Also quite thanks for hinting me to the dependency SVG. Already built one before (during work through the docs), but was shocked in the first view :-) ... but I'm pretty sure once I get it running, it will be helpful!!

[salkinium]

Did you close this on purpose? If you want to add more changes to the PR, just push more commits to the branch, the PR will update automatically.

[Apehaenger]

Yes ;-) due to frustration...
But 1/2 hour later I felt as looser and reviewed where I stuck.
Now I'm on track again... don't know if it's the right one :-) but if it's a step forward, I'll reopen and push my findings ;-)

[Apehaenger]

Okay, hard time but more clever now :-) ... or more hacky :-/

• Got RCC compile errors fixed
• stripped down my blinky sample (renamed the folder to STM32C0x)
• removed @salkinium WIP hack

As I did not know anything about modm before, I'm pretty sure that I did it somehow wrong at some places.
I also do not know if it's running at 48MHz in real or still at 16MHz boot frequency.
So please be so kind and give me a hint what should be changed.

Some questions popped up during coding:

1. If I go on and get my required drivers running for C0x, then the overview page with the supported MCUs also need to get updated (by me). I already recognized the circle sign of untested features, but how's about internal stuff like non-tested external clock or the requirement for ST's OpenOCD variant? Does such info get written down somewhere or doesn't it matter?
2. During watching around whats up with my code, I saw that the board definitions do a couple of initialization. How is it with a custom PCB like mine. Do I need to do such initialization (in special sysclock) in my main or is there some kind of custom board definition possibility which I overlooked in the docs? Yes, found modules.md in boards section which cleanly answers this question
3. What's up with the CI errors. Are they reasoned by my changes? yes

[Apehaenger]

"c0" requires an empty array for not walking through %% for id in pll_ids in rcc.cpp.in.
Is [""] a correct option?

[Apehaenger]

Reverted a couple of previous RCC hacks (like hsi48) because I felt they're wrong.

Added a custom-board.hpp to the blinky sample because I had the impression that SysClock need to be enabled/activated as ref-docs say boot frequency is HSI (48MHz) divided by 4 which is 12MHz.

But failed in RCC with PLL definitions because I'm to unknown.
Have the impression that modm-devices doesn't parsed the PLL defines out of the CMSIS header correctly, as I couldn't find any PLL defines in stm32c0x header files.

Blinky is running with a 2 second delay (instead of 0.5s), which seem to be the 1/2 boot frequency of 48MHz.

Would be nice if someone can give me a hint ;-)

[salkinium]

I'll have a look next week in more detail when I'm on holiday, under the week I'm typically too mentally exhausted from work.

[Apehaenger]

In between I did some tries with STM32CubeMX together with STM32-VScode extension. This is not an option for me 👎
So I reverted back to my initial but wrong looking 'hsi48' hacks, because it work and also the delay look correct.

With this I can go on trying to get into my project and use modm for it 👍

So @salkinium, enjoy your holiday by reading a book or doing something funny, but don't with coding. My issue has time for somewhen after holiday!

[salkinium]

I ordered a NUCLEO-C031C6 dev board, will probably end of week. I also found a super cheap (~1.5CHF) STM32C011 barebone dev board on aliexpress, but that'll arrive later.

[Apehaenger]

Oh no, don't waste money for my dev issues.
I'm pretty happy at the moment and get step by step into modm. Trying all driver (and partly build examples) which I do need for my project.
All is working great at the moment. Also sysclock stuff is working as expected since I added the HsiSysDivider stuff.
The bigger question will be: If I made it right and if it fit to your code requirements ;-)

Edit:
Took me some time to realize that the C0x doesn't has a PLL. Since that got into my brain, I'm going forward without issues 👍

[salkinium]

It's more to have a device to run the modm unit tests on. The nucleo boards are super cheap, and I need at least one device per family anyways.

[salkinium]

Sorry for the delay, I've ported your examples to the NUCLEO-C031C6 board and they all work! Congrats and thanks for porting modm to STM32C0.

I'll do my review directly in form of commits, it's just way faster this way. Sorry for force pushing to your branch, it's just simpler that way.

[Apehaenger]

I'm proud to see that my PR isn't fully none-sense ;-)

Already recognized and partly viewed your last commits the last days. Interesting to see the code lines I wasn't able to find ;-)

I'm fully fine with your force-pushes!! Do it the way how it's easiest for you.
My primary objective is getting STM32C0x support into mainline modm, so that I can switch from my hacky fork to std. modm ;-)
(but there's no hurry!)

Quite thanks for your support!!

[salkinium]

Thank you very much!

The HAL compile all CI tests passed previously, I'm not running them again, since I didn't change anything HAL related again.

[chris-durand]

@salkinium According to the HAL matrix USB is supported, but TinyUSB doesn't seem to have C0 support yet. I guess it isn't then?

[salkinium]

Hm, that's cos the HAL matrix checks for the :platform:usb instead of the :tinyusb module. Not great. I'll review this PR again tomorrow otherwise I'm gonna miss more of these details.

[chris-durand]

TODO?

[Apehaenger]

Yes, AFAIR that comment was from me. Did not know how to test :-/

[salkinium]

Ah, sorry it's the examples/generic/delay code and then you would need to run this through the code in this blog post.

I've just done this on the Nucleo-C031C6 and the delay is comparable to other CM0(+) devices:

Device	Core Type	Cycles per Loop	Minimum Cycles at Boot/High Frequency	Minimum Delay at Boot Frequency	Minimum Delay at High Frequency
STM32C031	cm0+	3	15/17	1250ns @ 12 MHz	354ns @ 48 MHz
STM32F072	cm0	4	18/19	1125ns @ 16 MHz	395ns @ 48 MHz
STM32F091	cm0	4	18/19	1125ns @ 16 MHz	395ns @ 48 MHz
STM32G071	cm0+	3	16/18	1000ns @ 16 MHz	281ns @ 64 MHz
STM32L031	cm0	3	16/17	7629ns @ 2.097 MHz	531ns @ 32 MHz

~1.25us minimum delay on boot frequency is almost on the ideal line:

~400ns minimum delay at 48MHz:

Also no scaling error for longer delays:

[salkinium]

the HAL matrix checks for the :platform:usb instead of the :tinyusb module.

Turns out the :tinyusb module is always available whenever the :platform:usb module is available, we never encoded support from TinyUSB, so the information is not queryable from lbuild anyways. I'll fix this in a separate PR, since TinyUSB also released v0.17 and we should upgrade.