As of PlatformIO Registry STM32C011 support is listed.
But whatever I try, I’m to untalented to get support for it.
Whatever I do, I always get “UnknownBoard” error.
Also pio pkg exec --package "platformio/framework-arduinoststm32" -- pio boards doesn’t list any STM32C011 MCU 
Any suggestions?
There is indeed no board definition for it and the only issue about it was closed prematurely (https://github.com/search?q=repo%3Aplatformio%2Fplatform-ststm32+stm32c0+&type=issues).
Which C011 chip or board are we talking about exactly?
Quite thanks for replying!
Good to know that I didn’t missed to read some docs 
It’s a custom designed board with STM32C011F6P6 without external xtal/osc.
Assuming you’re running Windows, can I ask you to test this project?
It compiles for a generic STM32C011F6P6 with no clock requirements. I had to add an updated version of OpenOCD into it because PlatformIO’s 1 year old version did not have STM32C0x support. Albeit C++ (register) warnings from the STM32HAL, it compiles fine.
Hurray, quick as always!! Thanks a lot!!
Unfortunately I dropped Windows approx. 15 years ago 
.
However, it also compiles well on my Linux (debian 12.x) machine (with a lot warnings related to clock, HAL, …).
Unfortunately the board just get produced and I expect to receive it earliest next week. So I can’t test right now
BUT: Many thanks for your quick support!! I can go on now with development.
The warning about the clock were actually fixed some time ago https://github.com/stm32duino/Arduino_Core_STM32/commit/75bda51e7c6d79415326ac43a199ee36200d93a1, I tracked that down. But there hasn’t been a new stable release since then by STM32Duino.
This seems important, so I did just include the current git commit version manually and added a surpression for -Wregister warnings to not spam the output. Now it builds cleanly. (Git project updated)
The issues about -Wregister warnings were raised in
Thank you very much!! 
In between I received my custom boards with the STM32C011F6 and can confirm that it’s working well! 
However, I’ve a problem remapping PA9/PA11 and PA10/PA12 to get USART1 on pin 16 (TX) and 17 (RX). Already tried some stuff but need to confess that I miss some generic understanding.
What I tried/understood in general is, that I need to remap those pins, which I tried via:
SYSCFG->CFGR1 |= 0b11000; // Remap PA12 to PA10 and PA11 to PA9
and than expected to get usart1 i.e. via:
HardwareSerial hostSerial(PA10, PA9);
or
HardwareSerial hostSerial(PA12, PA11); ?!?
But my code always freeze at the moment where the handler get attached (but work flawless when using i.e. USART2).
Unfortunately I didn’t found any useful docs how the remapping is handled in stm32duino 
. Yes I know “code is doc” , but that’s the part where I need to admit my personal limits
Close! It should be
HardwareSerial hostSerial(PA10_R, PA9_R);
for the alternative (remapped) pins. That uses the int, int constructor. But you can also use the constructor with the PinName, PinName types, that would be
HardwareSerial hostSerial(PA_10_R, PA_9_R);
You can see that in list of available int type pins
that get remapped to PinName type pins by using them as index in this array
And then the peripheral info is retrieved by searching these arrays for an entry that has the matching PinName type pin
The pin_function specifically then detects that | PREMAP macro for specific pins and calls
Also, if the hostSerial is supposed to be the main Serial object, you can take advantage of the overridable macros that select the instance and pins for that because
So you can have
build_flags =
-DSERIAL_UART_INSTANCE=1
-DPIN_SERIAL_RX=PA10_R
-DPIN_SERIAL_TX=PA9_R
in the platformio.ini so it’ll just overwrite the defaults.
Close 
… is also off-target 
Quite cool!! That compiles and doesn’t freeze anymore. Need to get another USB/UART from downstairs to validate, but I’m pretty sure it will
Also quite thanks for your detailed description 
. Will try to understand and decide which solution is preferable for me.
Took some time to get downstairs . Checked remapped UART which work flawless!
Also checked your code explanations. Interesting 
and I can follow somehow… also might find another remap stuff which I probably need later
But I’m pretty sure, without your solution and your pointing finger, it has taken hours for me to find that by myself
So: Quite thanks one more for your quick support and detailed explanation!
Hi @maxgerhardt, I was able to use your (https://github.com/STMicroelectronics/STM32CubeC0) repository to build for the STM32C0, but I would like to use the stm32cube framework, io. arduino.
So I simply modified the platformio.ini file to framework = stm32cube but this yields following problems…
Processing genericSTM32C011F6 (platform: ststm32@17.4.0; board: genericSTM32C011F6; framework: stm32cube)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
KeyError: Traceback (most recent call last):
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\platformio\__main__.py", line 103, in main
cli() # pylint: disable=no-value-for-parameter
^^^^^
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\click\core.py", line 1157, in __call__
return self.main(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\click\core.py", line 1078, in main
rv = self.invoke(ctx)
^^^^^^^^^^^^^^^^
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\platformio\cli.py", line 85, in invoke
return super().invoke(ctx)
^^^^^^^^^^^^^^^^^^^
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\click\core.py", line 1688, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\click\core.py", line 1434, in invoke
return ctx.invoke(self.callback, **ctx.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\click\core.py", line 783, in invoke
return __callback(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\click\decorators.py", line 33, in new_func
return f(get_current_context(), *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\platformio\run\cli.py", line 147, in cli
process_env(
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\platformio\run\cli.py", line 210, in process_env
).process()
^^^^^^^^^
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\platformio\run\processor.py", line 81, in process
install_project_env_dependencies(
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\platformio\package\commands\install.py", line 132, in install_project_env_dependencies
_install_project_env_platform(project_env, options),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\platformio\package\commands\install.py", line 149, in _install_project_env_platform
PlatformPackageManager().install(
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\platformio\package\manager\platform.py", line 60, in install
p.configure_project_packages(project_env, project_targets)
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\platformio\platform\base.py", line 185, in configure_project_packages
self.configure_default_packages(options, targets or [])
File "C:\Users\pasca\.platformio\platforms\ststm32\platform.py", line 111, in configure_default_packages
return PlatformBase.configure_default_packages(self, variables,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\pasca\.platformio\penv\Lib\site-packages\platformio\platform\base.py", line 197, in configure_default_packages
self.packages[_pkg_name]["optional"] = False
~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'framework-stm32cubec0'
I think framework-stm32cubec0 needs to be added to packages.json, but I don’t know how… Could you please advise ?
I added
framework-stm32cubec0@https://github.com/STMicroelectronics/STM32CubeC0
to platformio.ini, and this is certainly a step forward, but the I get a new error
MissingPackageManifestError: Could not find one of 'package.json' manifest files in the package
You need to fork that https://github.com/STMicroelectronics/STM32CubeC0 repo and put a package.json in it, like
{
"name": "framework-stm32cubec0",
"title": "STM32Cube",
"description": "STM32Cube is a set of tools and embedded software bricks available free of charge to enable fast and easy development on the STM32 platform (STM32CubeC0 MCU Firmware Package)",
"keywords": [
"framework",
"hal",
"stm32c0",
"stm32",
"st"
],
"version": "1.4.0",
"homepage": "https://www.st.com/en/embedded-software/stm32cubec0.html",
"repository": {
"type": "git",
"url": "https://github.com/STMicroelectronics/STM32CubeC0"
}
}
then point to that forked repo in your platform_packages.
The original issue that should be pushed is
Platform forks and point wise fixes make no sense in the global context.
Ok, some progress, but still a problem :
The system cannot find the path specified: 'C:\\Users\\pasca\\.platformio\\packages\\tool-ldscripts-ststm32\\stm32c0':
If I checked the folder for tool-ldscripts-ststm32 and there is indeed no subfolder for the C0 family… Reinstalling the tool also did not solve it.
any hints ?
I think you just have to create the folder
C:\Users\pasca\.platformio\packages\tool-ldscripts-ststm32\stm32c0
the builder script wants this folder to exist.
It looks for for a <MCU name>_DEFAULT.ld or <MCU name>_FLASH.ld script inside there, but if it’s not there, it will just use a generic template to generate the linker script. This should work.
If creating it locally works, you can equally create a forked repo for the tool-ldscripts-ststm32 package and link it in platform_packages.
Thank you @maxgerhardt that worked.
I could get the correct STM32C011F6UX_FLASH.ld file from STM32CubeIDE and copied it to that folder.
I still needed to upgrade GCC because the .ld file contained READ_ONLY sections. I found some other thread from you explaining how to solve that.
Build is now successful. Still some linker warnings. I will look into those with a fresh mind tomorrow.