Support for STM32F103C6?

[drnedm]

I have a blue pill board with STM32F103C6T6 instead of xC8T6. They are all over Aliexpress etc, you can either buy the board with the C8T6 or C6T6, C8 is 2-3 times the price.

As far as I can see from here: https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html they are very similar, 32/10 kB flash/ram vs 64/20 kB, and 2 UARTs instead of 3.

Judging from the binary size, DirtyJTAG should easily fit, but when flashed it does not enumerate as a USB device on a working board (verified by flashing STM32Duino and using serial via USB with it.

I'm willing to debug, and I could buy and donate a second one of those if it helps?

Here's the output of st-probe and st-flash:

#st-info --probe
Found 1 stlink programmers
 serial: 2d3804016215303030303032
openocd: "\x2d\x38\x04\x01\x62\x15\x30\x30\x30\x30\x30\x32"
  flash: 32768 (pagesize: 1024)
   sram: 10240
 chipid: 0x0412
 descr: F1 Low-density device

#st-flash --reset write dirtyjtag.bluepill.bin 0x8000000
st-flash 1.6.0
2021-08-24T21:46:24 INFO common.c: Loading device parameters....
2021-08-24T21:46:24 INFO common.c: Device connected is: F1 Low-density device, id 0x10006412
2021-08-24T21:46:24 INFO common.c: SRAM size: 0x2800 bytes (10 KiB), Flash: 0x8000 bytes (32 KiB) in pages of 1024 bytes
2021-08-24T21:46:24 INFO common.c: Attempting to write 8600 (0x2198) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08002000 erased
2021-08-24T21:46:24 INFO common.c: Finished erasing 9 pages of 1024 (0x400) bytes
2021-08-24T21:46:24 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2021-08-24T21:46:24 INFO flash_loader.c: Successfully loaded flash loader in sram
  9/9 pages written
2021-08-24T21:46:25 INFO common.c: Starting verification of write complete
2021-08-24T21:46:25 INFO common.c: Flash written and verified! jolly good!

and plugging that into the USB gives:

[45057.384431] usb 1-10: new full-speed USB device number 5 using xhci_hcd
[45057.590460] usb 1-10: device descriptor read/64, error -71
[45057.873445] usb 1-10: device descriptor read/64, error -71
[45058.161404] usb 1-10: new full-speed USB device number 6 using xhci_hcd
[45058.366459] usb 1-10: device descriptor read/64, error -71
[45058.650437] usb 1-10: device descriptor read/64, error -71
[45058.758436] usb usb1-port10: attempt power cycle
[45059.452411] usb 1-10: new full-speed USB device number 7 using xhci_hcd
[45059.479181] usb 1-10: Device not responding to setup address.
[45059.714225] usb 1-10: Device not responding to setup address.
[45059.918394] usb 1-10: device not accepting address 7, error -71
[45060.096405] usb 1-10: new full-speed USB device number 8 using xhci_hcd
[45060.123234] usb 1-10: Device not responding to setup address.
[45060.353163] usb 1-10: Device not responding to setup address.
[45060.558403] usb 1-10: device not accepting address 8, error -71
[45060.558436] usb usb1-port10: unable to enumerate USB device

What else can I provide?

[drnedm]

Ah, adapting the memory map makes it enumerate properly:

--- a/ld/bluepill.ld
+++ b/ld/bluepill.ld
@@ -1,7 +1,7 @@
 /* Generic linker script for STM32F103RBT6/STM32F103R8T6 */
 MEMORY {
-       rom (rx) : ORIGIN = 0x08000000, LENGTH = 128K
-       ram (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
+       rom (rx) : ORIGIN = 0x08000000, LENGTH = 32K
+       ram (rwx) : ORIGIN = 0x20000000, LENGTH = 4K
 }

Thats the values found in unicore-mx/lib/stm32/f1/stm32f100x6.ld

[jeanthom]

Good catch, I didn't think about the RAM size. Why choosing 4K for the RAM segment length if you have 10K?

[drnedm]

I found exactly this information in the unicore-mx/lib/stm32/f1/stm32f100x6.ld file, so I went with that. It was also set to a rom size of 128k, but the C8 has 64k I think?

I will try later today if jtag works, if yes I can play some more with those values. Maybe it would be nice if someone could verify on a C8 bluepill (actually I should receive one in the next weeks, so I can do it) if it works there with the settings for C6, then one could probably set it to the smaller settings in general, such that it will work on both chips. Or is it better to have a different platform to select in the makefile?

[gregorv]

Having a larger FLASH size configured in the linker script is usually not a problem, as long as the binary fits it should work (if you don't try any manual FLASH operations in your code that go outside the available FLASH, of course).

I have reduced the SRAM to 10k in pull request #113