search

modm-io / modm

modm: a C++23 library generator for AVR and ARM Cortex-M devices
https://modm.io
Mozilla Public License 2.0
748 stars 132 forks source link

Add STM32C0x #1188

Closed Apehaenger closed 3 weeks ago

Apehaenger commented 3 months ago

Add STM32C0x Summary:

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 commented 3 months ago

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 commented 3 months ago

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

Apehaenger commented 3 months ago

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

salkinium commented 3 months ago

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 commented 3 months ago

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

dependencies

Apehaenger commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

In between I did some tries with STM32CubeMX together with STM32-VScode extension. This is not an option for me :-1: 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 :+1:

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 commented 3 months ago

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 commented 3 months ago

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 :+1:

salkinium commented 3 months ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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!!

chris-durand commented 3 weeks ago

@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 commented 3 weeks ago

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.

salkinium commented 3 weeks ago

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.