CKS32: Support for CKS32F103C8T6 #756

VictorLamoine · 2019-01-03T13:09:08Z

Programmer/board type: Stlink/v2
Programmer firmware version: STSW-LINK007 2.27.15
Operating system: Kubuntu 18.04
Stlink tools version: 358a913 (compiled in release mode)
Stlink commandline tool name: st-flash
Target chip (and optional board): CS32F103C8T6, Blue-Pill (https://www.aliexpress.com/item/Free-Shipping-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-Forarduino/32525208361.html?spm=a2g0s.9042311.0.0.27424c4deFqZ4c)

I am trying to upload the bootloader from the STM32duino project.

Info about the device:

$ sudo st-info --version
v1.4.0-56-g358a913
$ sudo st-info --flash
0x20000
$ sudo st-info --sram
0x5000
$ sudo st-info --descr
F1 Medium-density device
$ sudo st-info --pagesize
0x400
$ sudo st-info --chipid
0x0410
$ sudo st-info --serial
303030303030303030303031
$ sudo st-info --hla-serial
"\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x31"
$ sudo st-info --probe
Found 1 stlink programmers
 serial: 303030303030303030303031
openocd: "\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x31"
  flash: 131072 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

Output:

$ sudo ./st-flash write $HOME/libraries/STM32duino-bootloader/binaries/generic_boot20_pc13.bin 0x8000000
st-flash 1.4.0-56-g358a913
2019-01-03T14:08:37 INFO common.c: Loading device parameters....
2019-01-03T14:08:37 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-01-03T14:08:37 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2019-01-03T14:08:37 INFO common.c: Attempting to write 21140 (0x5294) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08005000 erased
2019-01-03T14:08:37 INFO common.c: Finished erasing 21 pages of 1024 (0x400) bytes
2019-01-03T14:08:37 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-01-03T14:08:37 ERROR flash_loader.c: unknown coreid, not sure what flash loader to use, aborting! coreid: 2ba01477, chipid: 410
2019-01-03T14:08:37 WARN flash_loader.c: Failed to write flash loader to sram!
2019-01-03T14:08:37 ERROR common.c: stlink_flash_loader_init() == -1
stlink_fwrite_flash() == -1

The text was updated successfully, but these errors were encountered:

VictorLamoine · 2019-01-03T13:16:35Z

I think the only problem is that the coreid is not known. I will try to understand the code and allow stlink to upload like on a STM32F103C8T6.

I have successfully uploaded the bootloader using ST-Link on Windows, but I'd like to be able to do the same from Linux :)

xor-gate · 2019-01-03T20:11:16Z

Thanks!

rvowles · 2019-01-10T11:11:23Z

@xor-gate is there a release timeframe for this? I'm on a Mac and I see the last release was in September and I'm having the same problem...

VictorLamoine · 2019-01-10T12:09:13Z

There are instructions provided on how to compile from sources: https://github.com/texane/stlink/blob/master/doc/compiling.md

rvowles · 2019-01-11T05:17:29Z

@VictorLamoine does yours now work? Mine now stops as per issue #607

VictorLamoine · 2019-01-11T13:54:59Z

Yes I have flashed more than 8 device using the modifications, all device were from the same provider so they were exactly the same.

As for you problem, I'm afraid I cannot help! Good luck

eugenesia · 2019-01-13T04:43:26Z

It appears I have the same CS32F103C8T6 microcontroller from the same seller "Wavgat" on Aliexpress. Fix #757 has resolved the issue for me.

After some digging around I think the CS32 microcontroller is made by China Key System, a company based in Wuxi, China: http://www.cksic.com/en/about/217.html

Here's a Chinese user manual for a development board making use of the CS32 microcontroller, from another of CKS's websites (CKS Cup, an electronics competition for university students) http://www.ckscup.com/upload/yonghushouce.pdf

Someone else on the EevBlog forum encountered a similar issue https://www.eevblog.com/forum/beginners/unexpected-idcode-flashing-bluepill-clone/

Lenbok · 2019-02-20T10:34:22Z

Since #757 has been reverted (see #761 (comment) ), can this please be re-opened to track official support for this chip?

xor-gate · 2019-02-24T17:10:47Z

Reopening it now.

VictorLamoine · 2019-03-06T15:26:08Z

These chips are NOT legitimate copies of the STM32 so avoid buying them:
https://www.stm32duino.com/viewtopic.php?p=53661#p53661

xor-gate · 2019-03-09T09:48:19Z

Thanks @VictorLamoine, the aim of the texane/stlink project is to support legitimate programmers and chips. So I will close this issue. Thanks all.

LukaGiorgadze · 2019-04-01T17:22:04Z

Same error on macOS Mojave.
Hardware: Blue Pill STM32F103C8T6 (CS32F103C8T6)
ST Link v2

2019-04-01T21:18:05 WARN flash_loader.c: Failed to write flash loader to sram!
2019-04-01T21:18:05 ERROR common.c: stlink_flash_loader_init() == -1
stlink_fwrite_flash() == -1
make: *** [flash] Error 255

VictorLamoine · 2019-04-01T18:20:33Z

git revert 3295ab4e5cf05cb546856414f1d40b5deedcf219, compile and install from source and you are good.

⚠️ Beware that this WILL prevent you from uploading on other targets: #761.

LukaGiorgadze · 2019-04-05T16:31:17Z

git revert 3295ab4e5cf05cb546856414f1d40b5deedcf219, compile and install from source and you are good.

⚠️ Beware that this WILL prevent you from uploading on other targets: #761.

Thank you! But to get work properly, you need to remove definition STM32_FLASH_BASE and STM32_SRAM_BASE in includes/stlink.h:

// line 62
// #define STM32_FLASH_BASE 0x08000000
// #define STM32_SRAM_BASE 0x20000000

eugenesia · 2019-07-27T17:56:22Z

It seems that #805 was merged which enables support for the CS32 Blue Pill clone. I just compiled the latest version on the master branch v1.5.1-31-g625f4cd, commit 625f4cd5 and it appears that CS32 MCU support has been re-enabled.

Successful flash to CS32 MCU:

$ st-flash --version
v1.5.1-31-g625f4cd

$ st-info --probe
Found 1 stlink programmers
 serial: 563f6f06513f52481953253f
openocd: "\x56\x3f\x6f\x06\x51\x3f\x52\x48\x19\x53\x25\x3f"
  flash: 0 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

$ st-flash write generic_boot20_pc13.bin 0x8000000
st-flash 1.5.1-31-g625f4cd
2019-07-27T18:43:38 INFO usb.c: -- exit_dfu_mode
2019-07-27T18:43:38 INFO common.c: Loading device parameters....
2019-07-27T18:43:38 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-07-27T18:43:38 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2019-07-27T18:43:38 INFO common.c: Attempting to write 21140 (0x5294) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08005000 erased
2019-07-27T18:43:38 INFO common.c: Finished erasing 21 pages of 1024 (0x400) bytes
2019-07-27T18:43:38 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-07-27T18:43:38 INFO flash_loader.c: Successfully loaded flash loader in sram
 21/21 pages written
2019-07-27T18:43:39 INFO common.c: Starting verification of write complete
2019-07-27T18:43:39 INFO common.c: Flash written and verified! jolly good!

I encountered other connection issues with the CS32 Blue Pill clone and have documented some fixes on my blog: http://eugenesia.co.uk/2019/07/cs32-blue-pill-clone-connection-problems/

-> CKS devices with Core ID 0x2ba01477 (Closes #756 #757 #761 #766 #769 #805)

Nightwalker-87 · 2020-03-23T20:37:33Z

I'll take a look at this now with the following environment:

Debian Bullseye
stlink tools v1.6.0
STlink-v2 Programmer (clone) [CKS32F103C8T6]
CKS32F103C8T6 Bluepill-Board labeled as "STM32F103C8T6"

Nightwalker-87 · 2020-03-24T02:04:36Z

st-info --probe

Found 1 stlink programmers
serial: 3f70050132124647524b4e00
openocd: "\x3f\x70\x05\x01\x32\x12\x46\x47\x52\x4b\x4e\x00"
flash: 65536 (pagesize: 1024)
sram: 20480
chipid: 0x0410
descr: F1xx Medium-density

st-flash write /$PATH$/Blinker.bin 0x8000000

st-flash 1.6.0-87-ge3c76aa
2020-03-24T02:44:36 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in 1 KiB pages.
2020-03-24T02:44:36 INFO common.c: Attempting to write 3520 (0xdc0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000c00 erased
2020-03-24T02:44:36 INFO common.c: Finished erasing 4 pages of 1024 (0x400) bytes
2020-03-24T02:44:36 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-03-24T02:44:36 INFO flash_loader.c: Successfully loaded flash loader in sram
4/4 pages written
2020-03-24T02:44:36 INFO common.c: Starting verification of write complete
2020-03-24T02:44:36 INFO common.c: Flash written and verified! jolly good!

So far this all looks good, but I haven't verified the core-id yet (seen it via openOCD previously, as far as I can remember). I'd be surprised if this was not a fake chip...

Nightwalker-87 · 2020-03-24T17:42:01Z

After figuring out how to start the stlink-gui, I can now confirm that the device has the core ID:

compared to #define CS32_CORE_ID 0x2ba01477 from the reverted PRs #757, #805 and #848.

Thus it appears verifiable that STM32 clones with this core ID are working with the st-link toolset without the need for a change in the codebase.

For further investigation I'll also test with older releases. Maybe we can figure out if something else (accidentally) caused the problems somewhere in the code history.

Nightwalker-87 · 2020-03-29T12:41:07Z

@eugenesia: I'm still working out the history of this feature request throughout the code (which was not so easy though), but as far as I can see this is what happened so far:

2019-01-03 (#767) [1st feature request, this ticket]
2019-01-03 7651d21 (#757) --> 1st implementation
2019-01-14 (#761) Ticket for bug from 1st implementation STM32F2/F4/L4 (Regression 1)
2019-01-28 (#766) Ticket for bug from 1st implementation STM32F401 Nucleo-64 (Regression 2)
2019-02-12 3295ab4 --> reverts #757, fixes #761, #766 (Regression)
2019-06-06 84f63d2 (#805) --> 2nd implementation, but insufficient description in the changelog
2019-09-15 (#833) [2nd feature request]
2019-09-16 8562e9c (#834) --> 2nd attempt for 1st implementation (revoked PR)
2020-02-20 -- Release v1.6.0 --
2020-02-21 6692fdc Revival of 1st implementation, by mistake) (Regression 1 & 2 reintroduced)
2020-02-27 f5d0454 --> Reverts commit 6692fdc (Regression 1 & 2 finally fixed)

So this is likely to have been originally resolved with PR 805 already, implying Release v1.6.0 shipped with a functional implementation.
I haven't had a look on your blog on this topic yet though, which I'll do soon...

eugenesia · 2020-03-29T14:52:09Z

Hey @Nightwalker-87 thanks for following up on this. Apologies for my lack of updates as I haven't touched anything STM32-related for a while due to work.

The last time I checked in July 2019, #805 had fixed the issue. My blog post merely documents some other quirks and workarounds for the CS32 chip, a clone chip made by China Key System from Wuxi, China, so is unlikely to be useful to you.

I'll try out the latest update and see if it still works for the CS32 chip.

Nightwalker-87 · 2020-03-29T15:09:20Z

Hey there.

The last time I checked in July 2019, #805 had fixed the issue. My blog post merely documents some other quirks and workarounds for the CS32 chip, a clone chip made by China Key System from Wuxi, China, so is unlikely to be useful to you.

Indeed it is, as I have one of these as well. Also this is the chip targeted by this issue as CS32F103 and CKS32F103 seem to be the same chip manufactured by the mentioned company.

I'll try out the latest update and see if it still works for the CS32 chip.

To me it would be most helpful if you verified with 84f63d2, c492e1d and finally with the v.1.6.0 tag, because that would let this whole topic go to the correct Release milestone including related PRs, I could mark all of these as resolved and verified and can update/correct the changelog.

Referring to your blogpost, it would also be good to know if detection works without holding down Reset now. Talking about my setup, this is the case.

eugenesia · 2020-03-29T17:02:51Z

Hi @Nightwalker-87 I have verified as requested (due to Covid I have some time on my hands 😂). All the versions you asked me to test worked.

Before testing each version I pulled out the ST-Link v2 programmer from my USB port and plugged it back in, together with the CS32F103C8T6 MCU.

After each test, the program I uploaded worked as the LED was blinking.

Latest master `f5d0454`

$ st-info --version
v1.6.0-31-gf5d0454

$ st-info --probe
Found 1 stlink programmers
 serial: 563f6f06513f52481953253f
openocd: "\x56\x3f\x6f\x06\x51\x3f\x52\x48\x19\x53\x25\x3f"
  flash: 131072 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

$ st-flash write miniblink.bin 0x8000000
st-flash 1.6.0-31-gf5d0454
2020-03-29T17:39:08 INFO common.c: Loading device parameters....
2020-03-29T17:39:08 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-03-29T17:39:08 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2020-03-29T17:39:08 INFO common.c: Attempting to write 688 (0x2b0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-03-29T17:39:08 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-03-29T17:39:08 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-03-29T17:39:08 INFO flash_loader.c: Successfully loaded flash loader in sram
  1/1 pages written
2020-03-29T17:39:08 INFO common.c: Starting verification of write complete
2020-03-29T17:39:08 INFO common.c: Flash written and verified! jolly good!

Commit `84f63d2`

$ st-info --version
v1.5.1-30-g84f63d2

$ st-info --probe
Found 1 stlink programmers
 serial: 563f6f06513f52481953253f
openocd: "\x56\x3f\x6f\x06\x51\x3f\x52\x48\x19\x53\x25\x3f"
  flash: 131072 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

$ st-flash write miniblink.bin 0x8000000
st-flash 1.5.1-30-g84f63d2
2020-03-29T17:42:11 INFO common.c: Loading device parameters....
2020-03-29T17:42:11 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-03-29T17:42:11 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2020-03-29T17:42:11 INFO common.c: Attempting to write 688 (0x2b0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-03-29T17:42:11 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-03-29T17:42:11 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-03-29T17:42:11 INFO flash_loader.c: Successfully loaded flash loader in sram
  1/1 pages written
2020-03-29T17:42:11 INFO common.c: Starting verification of write complete
2020-03-29T17:42:11 INFO common.c: Flash written and verified! jolly good!

Commit `c492e1d`

$ st-info --version
v1.5.1-36-gc492e1d

$ » st-info --probe
Found 1 stlink programmers
 serial: 563f6f06513f52481953253f
openocd: "\x56\x3f\x6f\x06\x51\x3f\x52\x48\x19\x53\x25\x3f"
  flash: 131072 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

$ st-flash write miniblink.bin 0x8000000
st-flash 1.5.1-36-gc492e1d
2020-03-29T18:01:58 INFO usb.c: -- exit_dfu_mode
2020-03-29T18:01:58 INFO common.c: Loading device parameters....
2020-03-29T18:01:58 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-03-29T18:01:58 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2020-03-29T18:01:58 INFO common.c: Attempting to write 688 (0x2b0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-03-29T18:01:58 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-03-29T18:01:58 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-03-29T18:01:58 INFO flash_loader.c: Successfully loaded flash loader in sram
  1/1 pages written
2020-03-29T18:01:58 INFO common.c: Starting verification of write complete
2020-03-29T18:01:58 INFO common.c: Flash written and verified! jolly good!

Tag v1.6.0 `393310f`

$ st-info --version
v1.6.0

$ » st-info --probe
Found 1 stlink programmers
 serial: 563f6f06513f52481953253f
openocd: "\x56\x3f\x6f\x06\x51\x3f\x52\x48\x19\x53\x25\x3f"
  flash: 131072 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

$ st-flash write miniblink.bin 0x8000000
st-flash 1.6.0
2020-03-29T17:46:12 INFO common.c: Loading device parameters....
2020-03-29T17:46:12 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-03-29T17:46:12 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2020-03-29T17:46:12 INFO common.c: Attempting to write 688 (0x2b0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-03-29T17:46:12 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-03-29T17:46:12 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-03-29T17:46:12 INFO flash_loader.c: Successfully loaded flash loader in sram
  1/1 pages written
2020-03-29T17:46:12 INFO common.c: Starting verification of write complete
2020-03-29T17:46:12 INFO common.c: Flash written and verified! jolly good!

I didn't have to use the Reset button to trigger MCU detection in the above tests. Did you do something that fixed it?

The last time I had detection problems, I overwrote the boot loader or did something similar. I will try to do a more thorough test for this later on, by recreating the detection issue, and checking to see if the latest Stlink version fixes it.

Nightwalker-87 · 2020-03-29T17:40:57Z

@eugenesia: Thank you so much for verifying this. 🥇

I didn't have to use the Reset button to trigger MCU detection in the above tests. Did you do something that fixed it?

No, so it must be either a result from the oldest commit you tested or any earlier change not specifically related to this board type. I don't really know, but nothing to bother about really.

The last time I had detection problems, I overwrote the boot loader or did something similar. I will try to do a more thorough test for this later on, by recreating the detection issue, and checking to see if the latest Stlink version fixes it.

You can if you wish to do so. Talking about my demand - I'm absolutely fine and satisfied with the results you've just presented. 👍

Nightwalker-87 · 2020-03-29T18:19:24Z

Resolved by #805.

VictorLamoine mentioned this issue Jan 3, 2019

CKS32: Add support for CKS32 micro-controller #757

Merged

xor-gate closed this as completed in #757 Jan 3, 2019

xor-gate added this to the Next milestone Jan 3, 2019

xor-gate reopened this Feb 24, 2019

xor-gate closed this as completed Mar 9, 2019

xor-gate added question status/wont-fix status/resolved labels Mar 9, 2019

yanfali mentioned this issue Jul 1, 2019

Add generalised support for stm32 f103 to simplify bluepill based boards qmk/qmk_firmware#5669

Closed

13 tasks

Nightwalker-87 removed question status/resolved status/wont-fix labels Feb 19, 2020

Nightwalker-87 added a commit that referenced this issue Feb 20, 2020

Restored support for STM32-Clones

6692fdc

-> CKS devices with Core ID 0x2ba01477 (Closes #756 #757 #761 #766 #769 #805)

Nightwalker-87 mentioned this issue Feb 21, 2020

GD32F303VGT6: unknown coreid / stlink_flash_loader_init() == -1 #769

Closed

5 tasks

Nightwalker-87 removed this from the General milestone Feb 21, 2020

Nightwalker-87 changed the title ~~Support for CS32F103C8T6~~ CKS32: Support for CS32F103C8T6 Mar 17, 2020

Nightwalker-87 linked a pull request Mar 19, 2020 that will close this issue

CKS32: Add support for CKS32F103C8T6 #805

Merged

Nightwalker-87 added the priority/high label Mar 19, 2020

Nightwalker-87 self-assigned this Mar 20, 2020

Nightwalker-87 mentioned this issue Mar 23, 2020

CKS32: Unable to flash STM32F103C8T6 with stlink 1.5.1 #833

Closed

Nightwalker-87 linked a pull request Mar 23, 2020 that will close this issue

CKS32: added CKS32F103C8T6 a stm32f103c8t6 clone with coreid 0x2ba01477 #834

Closed

Nightwalker-87 added target/cks32f1 os/macOS labels Mar 23, 2020

Nightwalker-87 removed the priority/high label Mar 24, 2020

Nightwalker-87 changed the title ~~CKS32: Support for CS32F103C8T6~~ CKS32: Support for CKS32F103C8T6 Mar 24, 2020

Nightwalker-87 added the needs/issuer-feedback label Mar 25, 2020

Nightwalker-87 added status/resolved status/resolved-verified and removed needs/issuer-feedback labels Mar 29, 2020

Nightwalker-87 modified the milestones: v1.6.1, v1.6.0 Mar 29, 2020

Nightwalker-87 closed this as completed Mar 29, 2020

Nightwalker-87 assigned xor-gate and VictorLamoine Mar 29, 2020

Nightwalker-87 mentioned this issue Apr 1, 2020

[code-structure] Add all STM32 Core-IDs to the codebase for MCU identification #903

Closed

stlink-org locked as resolved and limited conversation to collaborators Apr 23, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CKS32: Support for CKS32F103C8T6 #756

CKS32: Support for CKS32F103C8T6 #756

VictorLamoine commented Jan 3, 2019 •

edited

VictorLamoine commented Jan 3, 2019 •

edited

xor-gate commented Jan 3, 2019

rvowles commented Jan 10, 2019

VictorLamoine commented Jan 10, 2019

rvowles commented Jan 11, 2019

VictorLamoine commented Jan 11, 2019

eugenesia commented Jan 13, 2019 •

edited

Lenbok commented Feb 20, 2019

xor-gate commented Feb 24, 2019

VictorLamoine commented Mar 6, 2019

xor-gate commented Mar 9, 2019

LukaGiorgadze commented Apr 1, 2019

VictorLamoine commented Apr 1, 2019

LukaGiorgadze commented Apr 5, 2019 •

edited

eugenesia commented Jul 27, 2019 •

edited

Nightwalker-87 commented Mar 23, 2020 •

edited

Nightwalker-87 commented Mar 24, 2020

Nightwalker-87 commented Mar 24, 2020

Nightwalker-87 commented Mar 29, 2020 •

edited

eugenesia commented Mar 29, 2020

Nightwalker-87 commented Mar 29, 2020

eugenesia commented Mar 29, 2020 •

edited

Nightwalker-87 commented Mar 29, 2020

Nightwalker-87 commented Mar 29, 2020

CKS32: Support for CKS32F103C8T6 #756

CKS32: Support for CKS32F103C8T6 #756

Comments

VictorLamoine commented Jan 3, 2019 • edited

VictorLamoine commented Jan 3, 2019 • edited

xor-gate commented Jan 3, 2019

rvowles commented Jan 10, 2019

VictorLamoine commented Jan 10, 2019

rvowles commented Jan 11, 2019

VictorLamoine commented Jan 11, 2019

eugenesia commented Jan 13, 2019 • edited

Lenbok commented Feb 20, 2019

xor-gate commented Feb 24, 2019

VictorLamoine commented Mar 6, 2019

xor-gate commented Mar 9, 2019

LukaGiorgadze commented Apr 1, 2019

VictorLamoine commented Apr 1, 2019

LukaGiorgadze commented Apr 5, 2019 • edited

eugenesia commented Jul 27, 2019 • edited

Nightwalker-87 commented Mar 23, 2020 • edited

Nightwalker-87 commented Mar 24, 2020

Nightwalker-87 commented Mar 24, 2020

Nightwalker-87 commented Mar 29, 2020 • edited

eugenesia commented Mar 29, 2020

Nightwalker-87 commented Mar 29, 2020

eugenesia commented Mar 29, 2020 • edited

Latest master f5d0454

Commit 84f63d2

Commit c492e1d

Tag v1.6.0 393310f

Nightwalker-87 commented Mar 29, 2020

Nightwalker-87 commented Mar 29, 2020

VictorLamoine commented Jan 3, 2019 •

edited

VictorLamoine commented Jan 3, 2019 •

edited

eugenesia commented Jan 13, 2019 •

edited

LukaGiorgadze commented Apr 5, 2019 •

edited

eugenesia commented Jul 27, 2019 •

edited

Nightwalker-87 commented Mar 23, 2020 •

edited

Nightwalker-87 commented Mar 29, 2020 •

edited

eugenesia commented Mar 29, 2020 •

edited

Latest master `f5d0454`

Commit `84f63d2`

Commit `c492e1d`

Tag v1.6.0 `393310f`