Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add STM32C0x #1188

Merged
merged 2 commits into from
Sep 26, 2024
Merged

Add STM32C0x #1188

merged 2 commits into from
Sep 26, 2024

Conversation

Apehaenger
Copy link
Contributor

@Apehaenger Apehaenger commented Jul 12, 2024

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
Copy link
Member

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
Copy link
Member

rleh commented Jul 12, 2024

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

@Apehaenger
Copy link
Contributor Author

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

@salkinium
Copy link
Member

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
Copy link
Member

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

dependencies

@Apehaenger
Copy link
Contributor Author

Apehaenger commented Jul 12, 2024

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

@Apehaenger Apehaenger closed this Jul 13, 2024
@salkinium
Copy link
Member

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
Copy link
Contributor Author

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 Apehaenger reopened this Jul 13, 2024
@Apehaenger
Copy link
Contributor Author

Apehaenger commented Jul 13, 2024

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

properties["bdcr"] = "CSR" if target.family in ["l0", "l1"] else "BDCR"
properties["pll_ids"] = ["1", "2", "3"] if target.family in ["h7", "u5"] else [""]
properties["bdcr"] = "CSR1" if target.family in ["c0"] else "CSR" if target.family in ["l0", "l1"] else "BDCR"
properties["pll_ids"] = ["1", "2", "3"] if target.family in ["h7", "u5"] else [] if target.family in ["c0"] else [""]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@Apehaenger
Copy link
Contributor Author

Apehaenger commented Jul 14, 2024

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
Copy link
Member

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
Copy link
Contributor Author

Apehaenger commented Jul 15, 2024

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
Copy link
Member

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
Copy link
Contributor Author

Apehaenger commented Jul 16, 2024

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
Copy link
Member

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.

@Apehaenger Apehaenger marked this pull request as ready for review August 12, 2024 20:47
@salkinium salkinium mentioned this pull request Aug 17, 2024
@salkinium salkinium added the ci:hal Triggers the exhaustive HAL compile CI jobs label Sep 21, 2024
@salkinium
Copy link
Member

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.

@salkinium salkinium force-pushed the feature/STM32C0x1 branch 6 times, most recently from 060af9f to f23a774 Compare September 22, 2024 17:45
@Apehaenger
Copy link
Contributor Author

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 salkinium added ci:hal Triggers the exhaustive HAL compile CI jobs and removed ci:hal Triggers the exhaustive HAL compile CI jobs labels Sep 22, 2024
@salkinium salkinium added the ci:hal Triggers the exhaustive HAL compile CI jobs label Sep 22, 2024
Copy link
Member

@salkinium salkinium left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

@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
Copy link
Member

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.

@@ -57,6 +57,7 @@ def build(env):
# (cycles per loop, setup cost in loops)
tuning = {
"g4": (3, 4), # CM4 tested on G476 in RAM
"c0": (3, 4), # CM0+ TODO: Test
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@salkinium salkinium Sep 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

salkinium commented Sep 22, 2024

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.

@salkinium salkinium merged commit a7cfe65 into modm-io:develop Sep 26, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
advanced 🤯 ci:hal Triggers the exhaustive HAL compile CI jobs feature 🚧
Development

Successfully merging this pull request may close these issues.

4 participants