STM32C011 (WeAct) - first steps

[ag123]

oh and for stm32f103 the rtc and 'bluepill' (or 'maple mini') type boards, I've used the RTC running on VBAT with the on board external crystal.
I've got a defective chip for one, but that for a normal working stm32f103c8 chip, the RTC keeps time for a long time > 1 year on a single cr2032 lithium battery.
But that because I've got a lousy crystal, the rtc drifts over time. It turns out manual drift adjustments
https://github.com/rogerclarkmelbourne/ ... /RTCAdjust
can bring that in line to a under a single minute (sometimes just bunch of seconds) over several months, not too bad for an on chip RTC running on cheap 32 k crystals.
https://www.aliexpress.com/w/wholesale-32768.html

the RTC matters if you are using SD-Fat and want to timestamp the files accordingly, e.g. for loggers etc.
but that SD-Fat makes for a complex, large development. flash and sram matters, I managed to get that running just well on stm32f103c8 on 'roger's (libmaple) core'
for 'roger's (libmaple) core', you'd either need to use the *old arduino IDE* i.e. 1.8 java based one. or find some alternative IDE that doesn't use boards manager.
or use a makefile.
viewtopic.php?t=37
I'm using makefiles with eclipse IDE (normal eclipse with CDT, no other addons)
For a new project / sketch, copy that whole project into a new folder and edit the makefile.
the makefiles is linux based, on windows use WSL
https://learn.microsoft.com/en-us/windows/wsl/install

[STM32ardui]

oh and for stm32f103 the rtc and 'bluepill' (or 'maple mini') type boards, I've used the RTC running on VBAT with the on board external crystal.

I used the SimpleRTC.ino on STM32C011. With LSI it's absolutely worse!
With LSE I got 4 seconds less in 24 hours (at 24 ~ 25 °C).
Schematic of WeActStudio-board shows me, crystal should be NX3215SA-32.768K. And datasheet tells me it has ±20 ppm. That's a deviation of 1,72 seconds in one day.

I read about drift adjustment, but I'm using ArduinoIDE 2.3. and Win10 and the STM32-Core.

not too bad for an on chip RTC running on cheap 32 k crystals.
https://www.aliexpress.com/w/wholesale-32768.html

My experience with chinese dealers:
1. Normally they don't know, what they are selling (you see it always in the description, that looks like a lot of catchwords are mingled together).
2. Specs are at least exaggerated, sometimes simply wrong. Take - for example - a look at torches, what large luminous flux a small Cree LED should deliver. Often values are over the absoulte maximum ratings.
3. And they have big problems to confess, that goods are defected. If I buy something at eBay, I simply answers NO to stupid sugestions and wait 7 days, until I can involve arbitration board of eBay.

So if you want a good LSE-crystal, you should look at Digikey, Mouser etc.!
ECX-.327-CDX-1293: ±5 ppm at 25 °C and 12,5 pF load capacitance.
Price at Digikey for 10 pieces is 4,61 € (without tax) - the NX3215SA-32.768K is listed at Mouser 7,05 € for 10 pieces. So the crystal with poorer specs is more expensive!!!

ECX-.327-CDX-1293 is listed in AN2867 "Guidelines for oscillator design on ... and STM32 MCUs/MPUs" (page 39). It's compactible with "C0, F0, F3, L0, L4, L4+,L5, G0, G4, F7, H5, H7, WB, WB0, WBA, WL, MP1, MP2, U0, U5".

[STM32ardui]

the RTC matters if you are using SD-Fat and want to timestamp the files accordingly, e.g. for loggers etc.
but that SD-Fat makes for a complex, large development. flash and sram matters, I managed to get that running just well on stm32f103c8 on 'roger's (libmaple) core'

At the moment a temperature logger with 5 x DS18B20 and a Adafruit M0 Feather Adalogger (based on SAMD21) is running. It uses SdFAT for microSD-card and has also a I²C-display. Every day at midnight it opens a new file with "yyyymmdd" in it's name and it also uses callback funktion to have creation timestamp in file (I can see later in Windows explorer). Complex? Flash/SRAM problems? No.

[ag123]

I *think* SD Fat requires more sram than do the 'low end' chips offer.
I've tried an implementation running on stm32f103c8 20k sram, libmaple (roger's) core.

It works well for a pretty long time, then as the number of files accumulate, the directory list become more verbose.
Then one day I had a 'crash', it simply stalls. In particular, these days SD cards are at least gigabytes large, that probably made things worse.
I've not figured things out, but the same codes runs just fine on stm32f401 (again libmaple core) .
after that I kind of 'switched' to stm32f401 pill boards. stm32f103 is still good for 'simple' things.
but more sram/flash and better performing f4xx is 'less hassle' to work with.

oh about the aliX 'cheap' 32k crystals, I've 2 pieces that I patched on a 'maple mini' type board, they don't oscillate, It leaves me wondering if it is the crystal at fault or that I did not place load capacitors. I simply soldered them on the pins for OSC-32.
Then that there is one which oscillate but drifts, so I corrected that with that code.
But with HSE as you observed, RTC is quite stable, and I can make do with the corrected drift.
I've a strange feeling that connecting a 10 Meg resistor across the crystal may make it oscillate, but that if indeed the 'cheap' 32k crystal is a dud/fake, it may oscillate at a *wrong* frequency. I didn't bother to try that.
most 'blue pill' type boards has the 32k crystal on board, and I'd think it is better to get those if one wants to use the RTC.

[Kenjutsu]

I also got a couple of WeAct STM32C011F6P6 Core Boards to play with and was also wondering if I could flash them with openocd and a DAP Link/CMSIS-DAP device.

I saw that xpack-openocd is installed as part of Arduino Core STM32 which seemed promising. However, there is no stm32c0x.cfg file. After some Googling, I found a copy on github under espressif / openocd-esp32. I copied this file to:

Code: Select all

/Users/ZZZ/Library/Arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-1/openocd/scripts/target

I also copied cmsis-dap-v2.cfg to:

Code: Select all

/Users/ZZZ/Library/Arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-1/openocd/scripts/interface

Next, I modified boards.txt and added the following to Generic C011F6Px:

Code: Select all

GenC0.menu.upload_method.OpenOCDDAPLink=OpenOCD DAPLink
GenC0.menu.upload_method.OpenOCDDAPLink.upload.protocol=cmsis-dap-v2
#GenC0.menu.upload_method.OpenOCDDAPLink.upload.protocol=cmsis-dap
GenC0.menu.upload_method.OpenOCDDAPLink.upload.script=stm32c0x.cfg
GenC0.menu.upload_method.OpenOCDDAPLink.upload.tool=xpack-openocd
GenC0.menu.upload_method.OpenOCDDAPLink.upload.maximum_size=32768

Next, I modified platform.txt and added the following to Uploader tool:

Code: Select all

#
# OpenOCD DAP-Link
#

tools.xpack-openocd.cmd=openocd
tools.xpack-openocd.path={runtime.tools.xpack-openocd.path}
tools.xpack-openocd.upload.params.verbose=-d
tools.xpack-openocd.upload.params.quiet=
tools.xpack-openocd.upload.pattern="{path}/bin/{cmd}" -s {path}/openocd/scripts -f {path}/openocd/scripts/interface/{upload.protocol}.cfg -f {path}/openocd/scripts/target/{upload.script} -c init -c "program {build.path}/{build.project_name}.hex  verify reset exit"

I connected my WeAct C011F6P6 Core Board to a Wch.Link.W debugger (set to DAP mode) and uploaded the Blink example. Unfortunately, I was greeted with the following error:

Code: Select all

Sketch uses 5224 bytes (15%) of program storage space. Maximum is 32768 bytes.
Global variables use 840 bytes (13%) of dynamic memory, leaving 5304 bytes for local variables. Maximum is 6144 bytes.
/Users/ZZZ/Library/Arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-1/bin/openocd -s /Users/ZZZ/Library/Arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-1/openocd/scripts -f /Users/ZZZ/Library/Arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-1/openocd/scripts/interface/cmsis-dap-v2.cfg -f /Users/ZZZ/Library/Arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-1/openocd/scripts/target/stm32c0x.cfg -c init -c program /var/folders/tq/dqrghm993td49tz1pvg8psxm0000gn/T/arduino_build_191521/Blink.ino.hex  verify reset exit 
xPack Open On-Chip Debugger 0.12.0-01004-g9ea7f3d64-dirty (2023-01-30-17:05)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
Info : Using CMSIS-DAPv2 interface with VID:PID=0x1a86:0x8012, serial=5EAC36441ED1
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: JTAG supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 2000 kHz
Info : SWD DPIDR 0x0bc11477
Info : [stm32c0x.cpu] Cortex-M0+ r0p1 processor detected
Info : [stm32c0x.cpu] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for stm32c0x.cpu on 3333
Info : Listening on port 3333 for gdb connections
[stm32c0x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x0800439c msp: 0x20001800
** Programming Started **
Warn : Cannot identify target as an STM32G0/G4/L4/L4+/L5/U5/WB/WL family device.
Error: auto_probe failed
** Programming Failed **
shutdown command invoked

the selected serial port 
 does not exist or your board is not connected

To make a long story short, I realized that the openocd binary installed as part of Arduino Core STM32 does not support the STM32C0X. I also have ESP32 Arduino support installed, and copied the ESP32 openocd binary to the STMicroelectronics/tools/xpack-openocd/0.12.0-1/bin folder, and tried to upload again:

Code: Select all

Sketch uses 5224 bytes (15%) of program storage space. Maximum is 32768 bytes.
Global variables use 840 bytes (13%) of dynamic memory, leaving 5304 bytes for local variables. Maximum is 6144 bytes.
/Users/ZZZ/Library/Arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-1/bin/openocd -s /Users/ZZZ/Library/Arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-1/openocd/scripts -f /Users/ZZZ/Library/Arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-1/openocd/scripts/interface/cmsis-dap-v2.cfg -f /Users/ZZZ/Library/Arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-1/openocd/scripts/target/stm32c0x.cfg -c init -c program /var/folders/tq/dqrghm993td49tz1pvg8psxm0000gn/T/arduino_build_191521/Blink.ino.hex  verify reset exit 
Open On-Chip Debugger v0.12.0-esp32-20230921 (2023-09-21-13:27)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
Info : Using CMSIS-DAPv2 interface with VID:PID=0x1a86:0x8012, serial=5EAC36441ED1
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: JTAG supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 2000 kHz
Info : SWD DPIDR 0x0bc11477
Info : [stm32c0x.cpu] Cortex-M0+ r0p1 processor detected
Info : [stm32c0x.cpu] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for stm32c0x.cpu on 3333
Info : Listening on port 3333 for gdb connections
[stm32c0x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x0800439c msp: 0x20001800
** Programming Started **
Info : device idcode = 0x10006443 (STM32C01xx - Rev A : 0x1000)
Info : RDP level 0 (0xAA)
Info : flash size = 32 KiB
Info : flash mode : single-bank
Info : Padding image section 0 at 0x0800153c with 4 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x08001540 .. 0x080017ff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

This is obviously a crude hack, but it is a proof of concept that openocd with a DAP link/CMSIS-DAP device can be used to flash a STM32C011 MCU

[STM32ardui]

I also got a couple of WeAct STM32C011F6P6 Core Boards to play with and was also wondering if I could flash them with openocd and a DAP Link/CMSIS-DAP device.

Thank you for the detailed answer.

For myself I found a different way...

WeActStudio has two different debugger, one is a "DAPLink-APM32", the other one a "STLink-STM32". I ordered the STLink-version and test it now.

It's a really tiny board: 13,5 x 36,6 mm. USB-C connector on one side and JST-SH with 1,0 mm pin pitch on the other side. A plug with cables and DuPont female conncetors is also in the bag. You have to be careful when putting the plug into socket. One customer reported that he demolished the socket.

In Device Manager of Windows you will see:

WeActStudio-STLink-Serial.jpg (38.47 KiB) Viewed 241 times

There is a "ST Link virtual COM port" and also a USB-device "ST-Link Debug".
Uploading a sketch (ArduinoIDE 2.3.2, STM32 boards 2.7.1 and STMCubeProgrammer CLI) works fine and afterwards I can see output in Serial Monitor of ArduinoIDE.

Price is 4,54 € at the moment, so almost the sum of a normal ST Link and a USB/Serial-adapter. But you need only one USB-socket on your PC.