STM32 without STM Libraries

[iMo]

There is more to life than STM32F103's.

Could you build an stm32F103 (BP) image for 128kB of flash, plz?

Done: plz let me know if you have any issues.

Cool!
I get following (flashed in with st-link):

Code: [Select]

ramfree . 19112 ok.
flashfree . -24692 ok.
free  (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

ok.

here . 536871820 ok.I think there is an issue with the results..

[wnorcott]

And now you have the very cheap and STM32F103 pin compatible GD32VF103  RISC-V chip from China. Sure you'll need new firmware but the peripherals are mostly the same as far as I can see at this point but I'm not 100% familiar with it yet.

GD32VF103 Literature package: https://sourceforge.net/projects/mecrisp/files/Target%20literature%20package%20for%20GD32VF103.tar.gz/download

What I've done with it so far: https://mecrisp-stellaris-folkdoc.sourceforge.io/gd32vf103.html#gd32vf103-longan-nano

The GD32VF103CBF6  is completely different, totally different architecture than the STM32F103 or the similarly named GD32F103CBF6 .
   
The Sipeed Longan Nano board a GD32VF103CBF6 dev board, is available from SeedStudio for $4.90 apiece including a micro SD card reader and a color OLED display on the board and even a form fitted plastic case.

https://www.seeedstudio.com/Sipeed-Longan-Nano-RISC-V-GD32VF103CBT6-Development-Board-p-4205.html

Despite the naming similarity, GD32VF103CBF6 RISC-V chip is 128KB Flash, 32KB SRAM  (not 20 KB) and runs at 108 MHz.    I am working with one of these feverishly now.  I have the Microsoft Visual Studio Code and PlatformIO and gcc entire toolchain installed and support for the Longan Nano board.  Also have Sigrok installed and running with a cheap Saleae clone.  Have a DS Logic on order. Running it on the Lenovo 14w laptop I just bought for $129, and running Manjaro Linux from a fast USB thumb drive. 

It is a bit of back and forth because I am working with a new laptop and a new operating system and having to install everything myself.

GD32VF103CBF6 is quite a learning curve but I think will be worth the time invested.   Despite 'pin compatibility' with STM32 the RISC-V chip is thoroughly modern chip one of the most modern on the market (< 6 month old?) and has the following:

two 12-bit ADCs with 16 channels each, two 12-bit DACs, 6 timers, three SPIs, two I2Cs, three USARTs, two UARTs, two I2Ss, two CANs, an USBFS, a CRC calculate unit. 

So far I got rudimentary understanding of  timers, interrupts and basic sleep mode somewhat figured out by reading the data sheet, searching for Github projects and judicious cut/paste code, reading RISC-V spec.  It's so new you really have to spend time just finding and gathering together the various guides online.   You burn firmware using the DFU interface that it understands, while the USB cable is connected to the PC.  There are also serial FTDI type programming option or through the JTAG port with a debugger, neither of which have I tried.   

Got it to sleep on timer and/or button press, interrupt routines on either, reads a bunch of H/W registers and displays on the OLED color display ever 3.5 seconds.  Reads and writes files to the SD card.   And of course does a blinky but it's an 8 colors blinking on one of the onboard LED, changes colors every 3.5 seconds when the timer fires.   Due to the sleep mode and the fact I can profile instruction counts, it is doing 771,000 instructions per second not 108 million, due to sleeping most of the time.  Have not measured current draw on the thing yet.

It uses a USB C connector but the way for power.

I have to the video working I got the SD card reader/writer working, got the H/W register code to fetch  the instructions executed count since startup (not sure if STM32 has this).   So it is pretty easy to compute actual instruction count for a loop or what have you.


I don't have the STM32 background myself and no MCU expert but bought several Blue Pill boards for $1.50 each on order to play with.  Going forward though my focus is on RISC-V and the Longan Nano board.

It is also available from Amazon Prime for less than $10.  I got one to start with and ordered another 10 from SeeedStudio to play with.

   One nice thing is you can program a Longan Nano board to be a debugger for other Longan Nano boards and just connect a ribbon cable to the already soldered JTAG headers.  That is kind of cool.  It also uses Altera USB Blaster or clones, or JLINK neither of which I have tried, and also an RV Link dedicated programmer from Seeed Studio I have one on order too just to keep handy that cost me $7.90.

[bingo600]

Just an info , not related to the RISC-V chip mentioned above , but the normal STM32 compatible GD32F103xxx

Remember the GD32F103C8F6  only have 64K as per the DS.
So some of the Code > 64K tricks that work on a "Normal" Bluepill wont work on a GD32 "Bluepill" unless it has a GD32F103CBF6 (128K) MCU on it

/Bingo

[bingo600]

There is more to life than STM32F103's.

Could you build an stm32F103 (BP) image for 128kB of flash, plz?

Done: plz let me know if you have any issues.

Cool!
I get following (flashed in with st-link):

Code: [Select]

ramfree . 19112 ok.
flashfree . -24692 ok.
free  (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

ok.

here . 536871820 ok.I think there is an issue with the results..

Technically the result is correct 
You have cheated and loaded 90K into an "official" 64K device , that gives ~ -24k

The Forth must be using the chip id (device) reported flash size , not the "nice gift from ST as in 2 x flash"

/Bingo

[iMo]

The Forth should return the correct results. Forth does not care about chip IDs..

[techman-001]

There is more to life than STM32F103's.

Could you build an stm32F103 (BP) image for 128kB of flash, plz?

Done: plz let me know if you have any issues.

Cool!
I get following (flashed in with st-link):

Code: [Select]

ramfree . 19112 ok.
flashfree . -24692 ok.
free  (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

ok.

here . 536871820 ok.I think there is an issue with the results..

Interesting!
What's the full chip part number and the board type etc ?

I used the STM datasheet specified location to obtain the Flash which on my Olimex P103 gives this result:

free (bytes)
FLASH.. TOTAL REPORTED: 131072 USED: 97028 FREE: 34044
RAM.... TOTAL PRESET: 20000 USED: 1456 FREE: 18544

This is correct for my chip, a STM32F103RBT6 so unless I have made a error somewhere, while it seems your chip does have 128KB Flash, it doesn't seem to be stating more than 64KB ?

30.1.1  Flash size register

        Base address: 0x1FFFF7E0
        Read only = 0xXXXX where X is factory-programmed

Bits 15:0 F_SIZE: Flash memory size

                This field value indicates the Flash memory size of the device in Kbytes.
                Example: 0x0080 = 128 Kbytes.

So all I do is read that register, mask out the upper 4  bytes and multiply by 1024 to get bytes:

$1FFFF7E0 @ $FFFF and 1024 * .    131072 ok.

What is the value you get now that you have a working Forth on that chip ?

[techman-001]

There is more to life than STM32F103's.

Could you build an stm32F103 (BP) image for 128kB of flash, plz?

Done: plz let me know if you have any issues.

Cool!
I get following (flashed in with st-link):

Code: [Select]

ramfree . 19112 ok.
flashfree . -24692 ok.
free  (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

ok.

here . 536871820 ok.I think there is an issue with the results..

Technically the result is correct 
You have cheated and loaded 90K into an "official" 64K device , that gives ~ -24k

The Forth must be using the chip id (device) reported flash size , not the "nice gift from ST as in 2 x flash"

/Bingo

That's correct, my Mecrisp-Stellaris Forth "free" word only reads the chip "Flash size register" according to the STM datasheet.

30.1.1  Flash size register
Base address: 0x1FFF F7E0
Read only = 0xXXXX where X is factory-programmed
This field value indicates the Flash memory size of the device in Kbytes.
Example: 0x0080 = 128 Kbytes.

Do you really think it's a gift ? Could it be that STM marked 64kB rather than 128kB on those chips because the second 64KB block failed their testing in some way that may not be apparent at room temperature etc  ?

[techman-001]

The Forth should return the correct results. Forth does not care about chip IDs..

Actually my "free" word *only* cares about the chip "Device electronic signature" and uses the "Flash size register" value to report the Flash Size.

People have asked me before "why not dynamically find the actual Flash value" and that's a good question.

1) STM already did that test and they have marked the Flash kB value in the chip "Flash size register".
2) To test the second 64 kB Flash I'd have to write it with a sequence of bit changes, but how many times do I do this, once, a hundred, a thousand times ?
3) It would fail the test if one bit failed to flash but even if it passed, it would only be at *your* local temperature and voltage and may fail at other temperatures etc.
4) Passing the test is no real guarantee it's all good.

Mecrisp-Stellaris Forth can do this as it can read and write Flash on the chip, from the chip.

Who wants a 64-128 kB Flash Test Word added to a bootable Bluepill usb image ?

[bingo600]

Do you really think it's a gift ? Could it be that STM marked 64kB rather than 128kB on those chips because the second 64KB block failed their testing in some way that may not be apparent at room temperature etc  ?

Rumours are that ST uses the same die for several models (saves production $$) , and all C8's i've met has 128K flash.
The STM32F101 used today in most of the ST-Link alu-clones doesn't even have USB , according to the DS.
But the Clones work 

I don't think it's rejects , just a (CB die) that reports a (C8) ID ...


Don't test the flashsize by writing to it , you'll wear it out - It's a "Public Secret" that the STM32F103C8 has 2 x flash 
Do you use the Flash for Forth program storage (aka are you writing to flash) ?
If yes , you might want to change your Forth to 128K if it's a C8 (same size as CB) , especially if you would not write to a device with negative flash left

NOTE: ST could change the die to a 64K at anytime for the C8 wo. breking specs in the DS , but i doubt they would change such an OLD die now.

/Bingo

[iMo]

I've been using BluePill 103C8.
Now the key message is following: all STM32F103C8 chips have got 2x more flash as advertised.
ALL stm's C8 we ever seen on stm32duino forum (last 5y) have got 128kB (fully working).

PS: those are not "rejects" - STM does not produce 64kB chips anymore.. That is a common practice today.. That is applicable for larger STM chips as well (!).

Thus the 64kB C8 has got 128kB flash. Your 128kB forth works fine here it seems:

Code: [Select]

ok.
compiletoram ok.
init-bignum ok.
: myfac fac bu. cr ; ok.
50 myfac 30414093201713378043612608166064768844377641568960512000000000000
ok.
see fac
00016BDA: F847
00016BDC: 6D04  ldr r4 [ r0 #50 ]
00016BDE: 2601  movs r6 #1
00016BE0: B500  push { lr }
00016BE2: F7FF  bl  000163F2  --> s>b
00016BE4: FC06
00016BE6: CF08  ldmia r7 { r3 }
00016BE8: 1C5B  adds r3 r3 #1
00016BEA: F847
00016BEC: 6D04  ldr r4 [ r0 #50 ]
00016BEE: B430  push { r4  r5 }
00016BF0: 2401  movs r4 #1
00016BF2: 001D  lsls r5 r3 #0
00016BF4: CF40  ldmia r7 { r6 }
00016BF6: 42AC  cmp r4 r5
00016BF8: D00A  beq 00016C10
00016BFA: 0023  lsls r3 r4 #0
00016BFC: F847
00016BFE: 6D04  ldr r4 [ r0 #50 ]
00016C00: 461E  mov r6 r3
00016C02: F7FF  bl  000163F2  --> s>b
00016C04: FBF6
00016C06: F7FF  bl  00016AFA  --> bu*
00016C08: FF78
00016C0A: 3401  adds r4 #1
00016C0C: 42AC  cmp r4 r5
00016C0E: D1F4  bne 00016BFA
00016C10: BC30  pop { r4  r5 }
00016C12: BD00  pop { pc }

Bytes: 58 ok.

see myfac
20000398: B500  push { lr }
2000039A: F646  bl  1FE46554
2000039C: 30DB
2000039E: F2C0  bl  202C03A4
200003A0: 0001
200003A2: 4780  blx r0
200003A4: F646  bl  1FE463EE
200003A6: 7023
200003A8: F2C0  bl  202C03AE
200003AA: 0001
200003AC: 4780  blx r0
200003AE: F242  bl  20242410
200003B0: 602F
200003B2: 4780  blx r0
200003B4: BD00  pop { pc }

Bytes: 30 ok.
hex ok.
here . 200003B8 ok.
see see
000147D2: B500  push { lr }
000147D4: F7EE  bl  00002D20  --> '
000147D6: FAA4
000147D8: F644  bl  FFE587DC
000147DA: 7000
000147DC: F2C2  bl  002D67E0
000147DE: 0000
000147E0: 6306  str r6 [ r0 #30 ]
000147E2: 6B06  ldr r6 [ r0 #30 ]
000147E4: 6386  str r6 [ r0 #38 ]
000147E6: CF40  ldmia r7 { r6 }
000147E8: F7FF  bl  00014750  --> seec
000147EA: FFB2
000147EC: F7ED  bl  0000262E  --> cr
000147EE: FF1F
000147F0: F7ED  bl  000026FA  -->  .' Bytes: '
000147F2: FF83
000147F4: 4207
000147F6: 7479
000147F8: 7365
000147FA: 203A
000147FC: F644  bl  FFE58800
000147FE: 7000
00014800: F2C2  bl  002D6804
00014802: 0000
00014804: 6B43  ldr r3 [ r0 #34 ]
00014806: 6B82  ldr r2 [ r0 #38 ]
00014808: 1A9B  subs r3 r3 r2
0001480A: F847
0001480C: 6D04  ldr r4 [ r0 #50 ]
0001480E: 461E  mov r6 r3
00014810: F7EF  bl  0000437E  --> .
00014812: FDB5
00014814: BD00  pop { pc }

Bytes: 68 ok.
What is needed is to forget the chip's IDs and to set the proper flash sizes such it shows good numbers

[techman-001]

Do you really think it's a gift ? Could it be that STM marked 64kB rather than 128kB on those chips because the second 64KB block failed their testing in some way that may not be apparent at room temperature etc  ?

Rumours are that ST uses the same die for several models (saves production $$) , and all C8's i've met has 128K flash.
The STM32F101 used today in most of the ST-Link alu-clones doesn't even have USB , according to the DS.
But the Clones work 

I don't think it's rejects , just a (CB die) that reports a (C8) ID ...

/Bingo

It's very curious, especially considering that STM themselves only use the STM32F103C8T6 in their Discovery Boards (SWD programmer section). I have a recent STM32L073 Nucleo here and it also uses a STM32F103C8T6 also.

While using the same die to save costs is a very logical and long used method, I can't help being suspicious of Chinese st-link clones in the same way I'm suspicious of Chinese "blue pills', namely their use of recycled e-waste as new parts.

[iMo]

Xilinx does the same with 20x more expensive chips..

[techman-001]

Do you really think it's a gift ? Could it be that STM marked 64kB rather than 128kB on those chips because the second 64KB block failed their testing in some way that may not be apparent at room temperature etc  ?

Rumours are that ST uses the same die for several models (saves production $$) , and all C8's i've met has 128K flash.
The STM32F101 used today in most of the ST-Link alu-clones doesn't even have USB , according to the DS.
But the Clones work 

I don't think it's rejects , just a (CB die) that reports a (C8) ID ...


Don't test the flashsize by writing to it , you'll wear it out - It's a "Public Secret" that the STM32F103C8 has 2 x flash 
Do you use the Flash for Forth program storage (aka are you writing to flash) ?
If yes , you might want to change your Forth to 128K if it's a C8 (same size as CB) , especially if you would not write to a device with negative flash left

NOTE: ST could change the die to a 64K at anytime for the C8 wo. breking specs in the DS , but i doubt they would change such an OLD die now.

/Bingo

Then I must be the only one around with 12 bonafide STM32F103C8T6 units ?

This attempted flashing of my recent eb13e308316527be6a8963098c7291d5.bin (90240 bytes) results in the errors below. It flashes fine with a < 64KB binary.

** Programming Started **
auto erase enabled
Info : device id = 0x20036410
Info : flash size = 64kbytes
Warn : no flash bank found for address 8010000
wrote 65536 bytes from file ./eb13e308316527be6a8963098c7291d5.bin in 2.032206s (31.493 KiB/s)
** Programming Finished **
** Verify Started **
Error: checksum mismatch - attempting binary compare
diff 0 address 0x08010000. Was 0xff instead of 0x00
...

[techman-001]

Do you really think it's a gift ? Could it be that STM marked 64kB rather than 128kB on those chips because the second 64KB block failed their testing in some way that may not be apparent at room temperature etc  ?

Rumours are that ST uses the same die for several models (saves production $$) , and all C8's i've met has 128K flash.
The STM32F101 used today in most of the ST-Link alu-clones doesn't even have USB , according to the DS.
But the Clones work 

I don't think it's rejects , just a (CB die) that reports a (C8) ID ...


Don't test the flashsize by writing to it , you'll wear it out - It's a "Public Secret" that the STM32F103C8 has 2 x flash 
Do you use the Flash for Forth program storage (aka are you writing to flash) ?
If yes , you might want to change your Forth to 128K if it's a C8 (same size as CB) , especially if you would not write to a device with negative flash left

NOTE: ST could change the die to a 64K at anytime for the C8 wo. breking specs in the DS , but i doubt they would change such an OLD die now.

/Bingo

Then I must be the only one around with 12 bonafide STM32F103C8T6 units ?

This attempted flashing of my recent eb13e308316527be6a8963098c7291d5.bin (90240 bytes) results in the errors below. It flashes fine with a < 64KB binary.

** Programming Started **
auto erase enabled
Info : device id = 0x20036410
Info : flash size = 64kbytes
Warn : no flash bank found for address 8010000
wrote 65536 bytes from file ./eb13e308316527be6a8963098c7291d5.bin in 2.032206s (31.493 KiB/s)
** Programming Finished **
** Verify Started **
Error: checksum mismatch - attempting binary compare
diff 0 address 0x08010000. Was 0xff instead of 0x00
...

I wrote this up on my doc site for anyone interested to see the proofs:-

STM32F103C8T6, 2 x 64kB flash ? https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103c8t6-128kb.html#stm32f103c8t6-128kb

[bingo600]

Then I must be the only one around with 12 bonafide STM32F103C8T6 units ?

This attempted flashing of my recent eb13e308316527be6a8963098c7291d5.bin (90240 bytes) results in the errors below. It flashes fine with a < 64KB binary.

** Programming Started **
auto erase enabled
Info : device id = 0x20036410
Info : flash size = 64kbytes
Warn : no flash bank found for address 8010000
wrote 65536 bytes from file ./eb13e308316527be6a8963098c7291d5.bin in 2.032206s (31.493 KiB/s)
** Programming Finished **
** Verify Started **
Error: checksum mismatch - attempting binary compare
diff 0 address 0x08010000. Was 0xff instead of 0x00
...

Could those be very old chips ?

As in before ST switched to "one die rules them all" 


WRT: Chip id for a 128K C8 , that programs ~90K wo. probs , you can see my BMP post here
https://www.eevblog.com/forum/microcontrollers/stm32-without-stm-libraries/msg2823454/#msg2823454

*** SNIP ***

blackmagic/src$ st-flash --flash=0x20000 write bmp-combined-dfu-bin.bin 0x8000000
st-flash 1.5.1-50-g3690de9
2019-12-10T19:49:45 INFO common.c: Loading device parameters....
2019-12-10T19:49:45 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-12-10T19:49:45 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
Forcing flash size: --flash=0x00020000
2019-12-10T19:49:45 INFO common.c: Attempting to write 90196 (0x16054) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08016000 erased
2019-12-10T19:49:47 INFO common.c: Finished erasing 89 pages of 1024 (0x400) bytes
2019-12-10T19:49:47 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-12-10T19:49:47 INFO flash_loader.c: Successfully loaded flash loader in sram
 89/89 pages written
2019-12-10T19:49:53 INFO common.c: Starting verification of write complete
2019-12-10T19:49:54 INFO common.c: Flash written and verified! jolly good!


What IMHO was surprising for me , was that imo mentioned he used st-link for programming , if that also included using "st-link util" from ST.
Then even ST allows programming > 64K in a F103C8  , where i'd have expected ST programs to use same method as your forth .. And "barf"

/Bingo

Ps: The GD32F103C8F6 uses another flash implementation , and follows the DS, having "just" 64K

[bingo600]

I wrote this up on my doc site for anyone interested to see the proofs:-

STM32F103C8T6, 2 x 64kB flash ? https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103c8t6-128kb.html#stm32f103c8t6-128kb

Just reread your article above.

I think OOCD is playing nice as your Forth is , using the flashsize reported by the chip.
You prob need to "tame" OOCD, and not use the probed value.

/Bingo

[iMo]

GD32F103 is a flash-less chip. There is only sram on the their arm chip (64kB+20kB for C8).
They store the binary on an external standard 64kB 8pin SPI flash die, bonded on the flash-less arm die.
Thus there are 2 chips inside the package.
GD32 boots off the external flash into the sram upon reset, and executes the binary off the sram.
Most probably all GD32F and GD32V mcus work that way (GigaDevices company is the major serial flash memory manufacturer there).

FYI - an info from early 2016: https://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices

PS: and yes, I flashed both 128kB mecrisp forth and 128kB BMP with stlink (the clone) via stm's stlink utility (win7 64b) into my 5y old BluePill (c8) with no problem.

PPS: based on an analysis done at stm32duino forum years back (I cannot find the thread today) the stm is producing only 128kB and 512kB F103 chips. Therefore 64kB and 128kB are all 128kB, and 256kB and 512kB are all 512kB (any package sizes).

[techman-001]

I wrote this up on my doc site for anyone interested to see the proofs:-

STM32F103C8T6, 2 x 64kB flash ? https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103c8t6-128kb.html#stm32f103c8t6-128kb

Just reread your article above.

I think OOCD is playing nice as your Forth is , using the flashsize reported by the chip.
You prob need to "tame" OOCD, and not use the probed value.

/Bingo

Bingo, one of my 12 STM32F103C8T6 boards with a reported 64kB Flash is now running a 90kB binary

free (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

Ok, I'm now officially convinced that the STM32F103C8T6 probably has a second 64kB laying around. I modified the OpenOCD config to ignore the reported Flash Size and the 90kB binary flashed no problem.

** Programming Started **
auto erase enabled
Info : device id = 0x20036410
Info : ignoring flash probed value, using configured bank size
Info : flash size = 128kbytes
wrote 91136 bytes from file ./eb13e308316527be6a8963098c7291d5.bin in 4.948380s (17.986 KiB/s)
** Programming Finished **
** Verify Started **
verified 90240 bytes in 1.311107s (67.214 KiB/s)
** Verified OK **
** Resetting Target **
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020 (STMicroelectronics), part: 0x6410, ver: 0x1)
shutdown command invoked

I think it's time to make a "64KB reported, second 64kB block found and tested" Forth Word I think.

Thanks, Bingo!

[bingo600]

Bingo, one of my 12 STM32F103C8T6 boards with a reported 64kB Flash is now running a 90kB binary

free (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

Ok, I'm now officially convinced that the STM32F103C8T6 probably has a second 64kB laying around. I modified the OpenOCD config to ignore the reported Flash Size and the 90kB binary flashed no problem.

Thanks, Bingo!

Remember to update your article 

Now you just got 12 more testboards 

Btw: I even think a (CB) image would run fine on a (C8) , was that what you tried ?

/Bingo
/Bingo

[bingo600]

PS: and yes, I flashed both 128kB mecrisp forth and 128kB BMP with stlink (the clone) via stm's stlink utility (win7 64b) into my 5y old BluePill (c8) with no problem.

Interesting that even ST is allowing st-util to program more than 64K on a C8 , might be a "good hint".
Did you have to override something ?? , or set an ignore error flag or

/Bingo

[techman-001]

Bingo, one of my 12 STM32F103C8T6 boards with a reported 64kB Flash is now running a 90kB binary

free (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

Ok, I'm now officially convinced that the STM32F103C8T6 probably has a second 64kB laying around. I modified the OpenOCD config to ignore the reported Flash Size and the 90kB binary flashed no problem.

Thanks, Bingo!

Remember to update your article 

Now you just got 12 more testboards 

Btw: I even think a (CB) image would run fine on a (C8) , was that what you tried ?

/Bingo
/Bingo

"Remember to update your article " <--- Done !

I'm reflashing my other 11 boards right now. No problems so far.

I loaded a CB image which does have a compilation config informing Mecrisp-Stellaris Forth that 128kB of Flash is available so when Flash is low it can warn the user.

Other than that, the image is identical to a 64kB Mecrisp-Stellaris Forth which warns when Flash is low near 64kB usage.

Cheers!

[iMo]

PS: and yes, I flashed both 128kB mecrisp forth and 128kB BMP with stlink (the clone) via stm's stlink utility (win7 64b) into my 5y old BluePill (c8) with no problem.

Interesting that even ST is allowing st-util to program more than 64K on a C8 , might be a "good hint".
Did you have to override something ?? , or set an ignore error flag or

/Bingo

No.