@kaspar030: If I remember correctly, you have some interest in using the full flash of the Bluepill. Would you mind to review?

Ping :-)

Ping?

I tested with

STM32F103C8_FLASH_HACK=1 PATH=~/opt/gnu-mcu-eclipse/openocd/0.10.0-11-20190118-1134-64/bin/:$PATH BOARD=bluepill make flash -C examples/gnrc_networking

GNU MCU Eclipse 64-bit Open On-Chip Debugger 0.10.0+dev-00462-gdd1d90111 (2019-01-18-11:37)

verified 65636 bytes in 0.985497s (65.041 KiB/s)

when it should fail since I have a 64 kB chip

(on master it shows Error: checksum mismatch - attempting binary compare)

With this PR it always says the flash size is 128kB not 64kB like on master.

Note: it fails correctly on this PR with the Open On-Chip Debugger 0.10.0+dev-00399-g09076d1 (2018-04-12-17:12) version of openocd

With this PR it always says the flash size is 128kB not 64kB like on master.

This is basically what the change does. If STM32F103C8_FLASH_HACK is set to 1, the flash size reported by the MCU is ignored by OpenOCD and it will just write up to 128KiB. This is something that might or might not work. It seems to me that the ST does not produce any STM32F103C8 (64KiB flash), but only STM32F103B8 (128KiB flash). The devices shipped as STM32F103C8 seem to have just some fuse blown.

I think the reasons for that are:

1. Only one production line is needed to manufacture two different MCUs
2. This allows ST to product binning. E.g. all MCUs with a broken flash can still be sold as STM32F103C8, provided that the first 64KiB flash is fully functional

I think you still need to edit cpu/stm32_common/stm32_mem_lengths.mk, only editing openocd.cfg gives me

/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: /home/benpicco/dev/RIOT/examples/gnrc_networking/bin/blackpill/gnrc_networking.elf section `.text' will not fit in region `rom'
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: region `rom' overflowed by 25840 bytes
collect2: error: ld returned 1 exit status

(.text is about 90 kiB)

@benpicco: Please check again after running export STM32F103C8_FLASH_HACK=1 ;-)

Oh sorry, I should read the contribution description till the end instead of just looking at the commits 😅

Could this also be achieved by

--- a/boards/common/stm32f103c8/Makefile.include
+++ b/boards/common/stm32f103c8/Makefile.include
@@ -3,6 +3,7 @@ export CPU = stm32f1
 STM32F103C8_FLASH_HACK ?= 0
 ifneq ($(STM32F103C8_FLASH_HACK),0)
   export CPU_MODEL = stm32f103cb
+  export OPENOCD_EXTRA_INIT += -c 'set FLASH_SIZE 0x20000'
 else
   export CPU_MODEL = stm32f103c8
 endif

so we avoid confusing OpenOCD if the hack is not to be applied? Sorry I can't test it right now, I only just realized that I need an external programmer for the blackpill and I don't have that with me right now.

@benpicco: That would be super nice, but it didn't work for me. I added now a modified OpenOCD config as openocfg-flash-hack.cfg and this is used instead of the default file if STM32F103C8_FLASH_HACK is used. This would be just as good to me, if this config could just source the standard OpenOCD config and add / overwrite based on that. However, I could not get source [find <FILE>] to work for files outside of OpenOCD's standard folder, so it contains a verbatim copy now :-/

I think this is better. Since the config should be Tcl, we should be able to use the source command without [find].

But I'd also find that bit of duplication acceptable. @MrKevinWeiss what do you think?

With the latest emails from @cladmi in the devel list in mind, I guess this PR could be integrated into th split of the bluepill board and the bluebill-128kib board. (And likewise for the blackpill.)