STM32 without STM Libraries

[techman-001]

[Cortex M3 CPUs] suck in comparison to the Cortex-M0

Actually, I find it quite the opposite.
Cortex-M0 doesn't support the 32bit "Thumb-2" instructions, which means that many of your traditional ARM instructions are completely missing (divide), or have severe limitations (no "AND/OR/EOR" with immediate values, LDR/STR indexed-with-offset limited to offsets <32, more.)  It's a PITA to program in assembly language, and the code produced by even good compilers is frequently big, slow, and ugly (compared to the CM3.)

Now, it does seem that CM3 has largely lost vendor interest in favor of CM4 (and CM0); I don't quite understand why that's the case - I suspect it has more to do with hardware licensing and implementation details than CPU architectural issues.  (Doesn't the M0 have a flat-rate license fee, rather than a royalty-based scheme?)

I'm quite fond of the M0 and as you have observed I'm not the only one. The wide range of easy to configure peripheral mix, speed and low cost are perfect for me, I love the hardware side of it.

I'm not particularly fond of the Cortex-M0 ISA as my first love was Motorola 6800 assembly, and what can compare to ones first love ?

Whilst it does have some limitations which are not in any way "severe" to me, none of them are a problem for Forth, which easily works around them in a quite transparent way.

For example:

Code: [Select]

registerliteral, ( x Register - - )
Generate shortest possible sequence to get x into given low Register.
On M0: A movs-lsls-adds… sequence
M3/M4: movs / movs-mvns / movw / movw-movt
Thumb 16 bit code does save about 2/3 the Flash space compared to 32 bit ARM code, according to ARM, who also state that internally, the same 32 bit instructions are still run. The code space saving is the reason Thumb exists from my reading of the docs.

I have been coding for both the STM32F051 and the STM32F103 lately and I'll take the F051 over the F103 any day.

Note: I'll still happily take a M3 over anything AVR or older.

[iMo]

I am a big fan of Forth. Worked a bit with amforth (atmegas), flashforth (pic18/24/dspic33), mecrisp(stm, ice40).
The major "issue" with Forth I see is, except it is "write only language" , the community (extremely limited in size) does not share code ("libraries") as it is with, say, arduino community.
Be warned.. 

Every language can be "write only" it depends how badly (or cleverly) one writes their code.

There isn't really a Forth  'community', rather thousands of Forth users doing their own thing with their own Forth and their own disparate hardware from 6502's to ARM cpu's.
But ... because Forth probably runs on more hardware than any other OS, most code isn't compatible.
Libraries ... do you mean piles of definitions and functions/methods stacked together ? ;-)
We have plenty of those.
Here is one of mine, it's freely available to anyone. Of course they'd need to use it on a STM32Fxx and modify the code for a different clock speed.
https://mecrisp-stellaris-folkdoc.sourceforge.io/systick-library.html#systick-library

I think you have described the problem perfectly!
Usually the STM32Fxx is just a small piece of your "solution", you may have a dozen of other external chips and subsystems connected, doing something useful.

[techman-001]

I am a big fan of Forth. Worked a bit with amforth (atmegas), flashforth (pic18/24/dspic33), mecrisp(stm, ice40).
The major "issue" with Forth I see is, except it is "write only language" , the community (extremely limited in size) does not share code ("libraries") as it is with, say, arduino community.
Be warned.. 

Every language can be "write only" it depends how badly (or cleverly) one writes their code.

There isn't really a Forth  'community', rather thousands of Forth users doing their own thing with their own Forth and their own disparate hardware from 6502's to ARM cpu's.
But ... because Forth probably runs on more hardware than any other OS, most code isn't compatible.
Libraries ... do you mean piles of definitions and functions/methods stacked together ? ;-)
We have plenty of those.
Here is one of mine, it's freely available to anyone. Of course they'd need to use it on a STM32Fxx and modify the code for a different clock speed.
https://mecrisp-stellaris-folkdoc.sourceforge.io/systick-library.html#systick-library

I think you have described the problem perfectly!
Usually the STM32Fxx is just a small piece of your "solution", you may have a dozen of other external chips and subsystems connected, doing something useful.

I should hope so, it would be a waste of a perfectly good Forth otherwise. This is exactly what people have been doing since digital electronics first appeared.

[exe]

And yes, I agree the STM32F103, although very popular for some reason (a bit like the old Atmega's), is a poor choice these days. There's now myriads of better MCUs from STM. Don't neglect the L4 series also, for those aiming for lower power stuff.

I buy STM32F103 for aliexpress and they cost very cheap. I think I bought a development board less than 3euro delivered. (although I don't know if they are genuine or not, but so far worked in my projects)

Of course there are better MCUs, but are they in the same price range ($0.8 or even less)? Of course if it's for production it's unlikely someone will buy from aliexpress, buy for home use why not?

[techman-001]

And yes, I agree the STM32F103, although very popular for some reason (a bit like the old Atmega's), is a poor choice these days. There's now myriads of better MCUs from STM. Don't neglect the L4 series also, for those aiming for lower power stuff.

I buy STM32F103 for aliexpress and they cost very cheap. I think I bought a development board less than 3euro delivered. (although I don't know if they are genuine or not, but so far worked in my projects)

Of course there are better MCUs, but are they in the same price range ($0.8 or even less)? Of course if it's for production it's unlikely someone will buy from aliexpress, buy for home use why not?

They are far cheaper than new units from American factory resellers, so even if they're genuine, they're not new. I think they are e-waste recycles, and that's cool too but only if the reseller advertises it.

In any event, I think that the STM32F103 sales from China have been astronomical and perhaps they're running low on stock now, hence the 'rise of the clones' ;-)

No experienced and certified company would EVER touch these chips for production because they break every rule of QA, starting with traceability.

[exe]

I dunno where they get them in such quantities and what's inside, but it would be interesting to know. I'd expect it to be GD32F103 (or rejects of). But the thing is, it works, and they are well supported in software, and bugs already known.

Interesting thing, compare prices for, say STM32F103C8T6, on mouser and lcsc. It's 5.6euro+VAT (that is $6) vs $1.7. Nuff said.

[techman-001]

I dunno where they get them in such quantities and what's inside, but it would be interesting to know. I'd expect it to be GD32F103 (or rejects of). But the thing is, it works, and they are well supported in software, and bugs already known.

Interesting thing, compare prices for, say STM32F103C8T6, on mouser and lcsc. It's 5.6euro+VAT (that is $6) vs $1.7. Nuff said.

Based on my feedback from https://mecrisp-stellaris-folkdoc.sourceforge.io/f1-usb.html#stm32f1-usb, there are a few odd MCU's in Blue Pills.

[iMo]

The "original STM32F103" on BluePill board works fine and I never had any problem with it. BP is a cheapo board, people buy 10+ pieces for their hobby designs. All people I know report 128kB flash so a good buy.

There are GD32F103 and CS32F103 clones. Those are Chinese chips, not related to STM, afaik.

The GD32 are flash-less, using external flash put inside its package. There were some tests with GD32 done in past and the chips basically work, it could be there are some minor differences related to settings of the clocks, etc. The GD32 are faster than the STM32 due to missing on-chip flash. Also do not expect 128kB of flash with GD/CS.

I would not be bashing those "odd" chips, however. We have to master them simply, when interested in cheapo solutions, that is all

[chickenHeadKnob]

I dunno where they get them in such quantities and what's inside, but it would be interesting to know. I'd expect it to be GD32F103 (or rejects of). But the thing is, it works, and they are well supported in software, and bugs already known.

Interesting thing, compare prices for, say STM32F103C8T6, on mouser and lcsc. It's 5.6euro+VAT (that is $6) vs $1.7. Nuff said.

Compare your Lcsc stm32f103C to Lcsc stm32f302C8  $1.69 single $1.25 qty(10)
This is a cortex m4 with 64K Rom,16K RAM and USB and better peripherals all round.

Count me in the camp that doesn't get why hobbista's are fixated with the F103 or cortex M0 mcu's or even more limited things like those PADUAK
That said, ST's large processor portfolio and weird pricing complicates selection and you need to invest a lot of time to familiarize.

[exe]

Count me in the camp that doesn't get why hobbista's are fixated with the F103 or cortex M0

Another point is software support, e.g., arduino, embed.org, chibios, etc (unless one wants to use cubemx). Things getting better over time, but still.

[techman-001]

I dunno where they get them in such quantities and what's inside, but it would be interesting to know. I'd expect it to be GD32F103 (or rejects of). But the thing is, it works, and they are well supported in software, and bugs already known.

Interesting thing, compare prices for, say STM32F103C8T6, on mouser and lcsc. It's 5.6euro+VAT (that is $6) vs $1.7. Nuff said.

Compare your Lcsc stm32f103C to Lcsc stm32f302C8  $1.69 single $1.25 qty(10)
This is a cortex m4 with 64K Rom,16K RAM and USB and better peripherals all round.

Count me in the camp that doesn't get why hobbista's are fixated with the F103 or cortex M0 mcu's or even more limited things like those PADUAK
That said, ST's large processor portfolio and weird pricing complicates selection and you need to invest a lot of time to familiarize.

I can answer why I like STM32F051's. I bought 480 of them in 2014 from Avenet for $0.56 each. They are bonafide STM chips in UFN32 with 64KB Flash and 8KB ram, they have 33 peripherals and clock at 48Mhz. I've run one for over a year at 96 MHz just to see if it was going to die and I'm still using it right now.

I use Forth, so 64KB flash is massive for what I do, which is small embedded controllers. I don't do IoT or USB etc.

This mcu is pretty much at the bottom of the pecking order of STM32 offerings but is still a universe away from old devices like AVR's and 16 bit PIC's.

A STM32F302 would be total overkill for me as I barely use the full capability of the STM32F051.

[chickenHeadKnob]

I can answer why I like STM32F051's. I bought 480 of them in 2014 from Avenet for $0.56 each. They are bonafide STM chips in UFN32 with 64KB Flash and 8KB ram, they have 33 peripherals and clock at 48Mhz. I've run one for over a year at 96 MHz just to see if it was going to die and I'm still using it right now.

I use Forth, so 64KB flash is massive for what I do, which is small embedded controllers. I don't do IoT or USB etc.

This mcu is pretty much at the bottom of the pecking order of STM32 offerings but is still a universe away from old devices like AVR's and 16 bit PIC's.

A STM32F302 would be total overkill for me as I barely use the full capability of the STM32F051.

Well if you are buying 480 mcu's at a crack I would put you beyond the hobby class of people.  I once worked for cheapskate boss that forced me to squeeze the most out of a M6805, I for sure wouldn't do that for fun on my own time. For small time hobby people it can make the most sense to standardize on a processor that will conceivably do everything  they might want to and thus simplify programming and also reduce their lab inventory of parts without worrying about optimizing other criteria like price.

[JohnnyBerg]

You could have a look on my Github repo, it allows you to code, flash and debug devices like an Arduino, without using the Arduino IDE.
The repo uses Visual Studio Code as a IDE. It is not based on existing solutions like PlatformIO.

[mac.6]

Cortex-M0+ are a bit so-so, they have great power figure due to the low die size, some very nice debug capabilities (ETM trace buffer) but are crippled in debug by their 2 hw breakpoints only.

Bare metal programming is still a thing with these little MCU, just be sure to not reinvent the wheel or at least reinvent only once!
What you should really focus on is the development environment, be able to setup your own build/debug system out of vendor related IDE/tools is a nice thing to have, be it based on makefile/cmake/whatever. Also know to split your code between generic code and porting layers is a big plus, nothing worse that code that mix hardcoded hw and generic code.

[MT]

I have been coding for both the STM32F051 and the STM32F103 lately and I'll take the F051 over the F103 any day.
Note: I'll still happily take a M3 over anything AVR or older.

Okileydokely, so you luve F0 before F3 but "how" do you luve M0+ over M0 and M3?
For example the G071 beats the crap of a F051 for meager cents in pricing.

Like 30 years ago i once tried to try FORTH on a 68HC11 but it was so backwardish, inverse, upsidedown, right to left so i didnt understand anything ending coding the 68HC11 in assembler instead.

[techman-001]

I have been coding for both the STM32F051 and the STM32F103 lately and I'll take the F051 over the F103 any day.
Note: I'll still happily take a M3 over anything AVR or older.

Okileydokely, so you luve F0 before F3 but "how" do you luve M0+ over M0 and M3?
For example the G071 beats the crap of a F051 for meager cents in pricing.

Like 30 years ago i once tried to try FORTH on a 68HC11 but it was so backwardish, inverse, upsidedown, right to left so i didnt understand anything ending coding the 68HC11 in assembler instead.

I bought 480 stm32F051's in 2014 for $0.56 each. UFN32, 64KB flash, 8kB ram. It's a lifetimes supply of luve!

For what I do, the M0 is TONS more than need. I also have a L073 which is more complex, mainly in the low power area, I'm still playing with it.

Right now I'm using Forth on a GD32VF103 RISC-V  "longan-nano" board. There is more to life than STM32F103's.

Code: [Select]

free (bytes)
FLASH.. TOTAL REPORTED: 131072 USED: 83308 FREE: 47764
RAM.... TOTAL PRESET: 32767 USED: 13675 FREE: 19092

Code: [Select]

id
UNIQUE_ID[31:0]  0x3641294D | 6 A ) M
UNIQUE_ID[63:32] 0x00123736 | . . 7 6
UNIQUE_ID[95:64] 0xFFFFFFFF | . . . .

Code: [Select]

gpioa.
GPIOA_CTL0 (read-write) $44444444
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0


GPIOA_CTL1 (read-write) $444444A4
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 1 0 1 0 0 1 0 0


GPIOA_ISTAT (read-only) $0000A4FF
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 0 1 1 1 1 1 1 1 1


GPIOA_OCTL (read-write) $0000A000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0


GPIOA_BOP (write-only) $00000000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


GPIOA_BC (write-only) $00000000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


GPIOA_LOCK (read-write) $00000000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

 ok.
"ending coding the 68HC11 in assembler" ... you say that as tho it's a bad thing ?

One of my most fun era's was programming the HC11 in Assembly. It was smooth as silk, the code flowed from my fingertips like beer from a keg at a Australian pub!

[MT]

"ending coding the 68HC11 in assembler" ... you say that as tho it's a bad thing ?

One of my most fun era's was programming the HC11 in Assembly. It was smooth as silk, the code flowed from my fingertips like beer from a keg at a Australian pub!

No i didnt say assembler is a bad thing rather that at that point in time i didnt understand the concepts of "FROTH"
(beer) on a 68HC11, thats all. 68HC11 was a neat device back then we used to shoehorn in things in 2k of EEPROM.

[iMo]

There is more to life than STM32F103's.

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

[profdc9]

I use the STM32F103CBT6, and the main reason is that I am trying to produce projects with longevity.  It has some quirks and bugs due to errata that are quite annoying, however, it more-or-less works and is so cheap and common is hard to imagine it won't be around for decades to come.  Of course, if I didn't care about that, I could use STM32F4, but if a project is going to last a long time, it should be made with parts that are super common and available.  I've been burned by parts not being that available with the consequence they become quite expensive and rare. 

[techman-001]

There is more to life than STM32F103's.

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

No problem, what do you want in it ?

[iMo]

The Forth above.. Such it uses 128kB of flash (and 20kB of ram)..

[techman-001]

I use the STM32F103CBT6, and the main reason is that I am trying to produce projects with longevity.  It has some quirks and bugs due to errata that are quite annoying, however, it more-or-less works and is so cheap and common is hard to imagine it won't be around for decades to come.  Of course, if I didn't care about that, I could use STM32F4, but if a project is going to last a long time, it should be made with parts that are super common and available.  I've been burned by parts not being that available with the consequence they become quite expensive and rare.

Rumor has it that STM32F103CBT6 and the clones will still be available at the heat death of the universe.

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

[jhpadjustable]

And now you have

Not until I can easily buy 4 or 480 bare chips at a competitive price, I don't.  The GD32VF103 does promise to be a leading choice once they're generally available at a reasonable price. Or am I just looking in the wrong places?

I bought 480 stm32F051's in 2014 for $0.56 each. UFN32, 64KB flash, 8kB ram. It's a lifetimes supply of luve!

If you can't be with the one you luve, luve the one you're with. 

[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.

https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/bluepill-128kb-usb.tar.gz/download

[bingo600]

There is more to life than STM32F103's.

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

EDIT: Totally missed techman's reply above ... And that imu asked for for Forth for a Bluepill     Well here's the BMP (BlackMagic Probe) guide anyway & a DIY from src

Please direct any BMP related replies to this thread , i have asked Dave to move this post there too.
https://www.eevblog.com/forum/microcontrollers/make-a-blackmagic-probe-out-of-a-stm32-bluepill/msg2823502/#msg2823502




I just "pulled" the latest git 30 min ago , and built it for a bluepill (attched)
driver - contains udev/inf files , bmp .. the binaries.

**** git version ****
From https://github.com/blacksphere/blackmagic
   8a07f44..0b6f393  master     -> origin/master
Updating 8a07f44..0b6f393


***** PIN Defs *****

See here for STM BMP Pin defs
https://github.com/blacksphere/blackmagic/blob/master/src/platforms/swlink/platform.h

/* Hardware definitions... */   - SWLINK
#define TMS_PORT   GPIOA
#define TCK_PORT   GPIOA
#define TDI_PORT   GPIOA
#define TDO_PORT   GPIOB
#define JRST_PORT   GPIOB
#define TMS_PIN      GPIO13
#define TCK_PIN      GPIO14
#define TDI_PIN      GPIO15
#define TDO_PIN      GPIO3
#define JRST_PIN   GPIO4

#define SWDIO_PORT    TMS_PORT
#define SWCLK_PORT    TCK_PORT
#define SWDIO_PIN   TMS_PIN
#define SWCLK_PIN   TCK_PIN


You could use any STM programming sw as a replacement for st-link  (ie. if you have windows)
Only problem is if the programming sw honours the chips reported 64k , and refuses to program more than that.

st-flash --flash=0x20000  - overrides the 64k reported , and tells it to use 128k

I use linux , don't know if st-flash exists for windows (it might)
Edit: There's a v1.3.0 here  - It might work , i use 1.5.1-50 (linux) SVN
https://github.com/texane/stlink/releases/tag/1.3.0

You might be able to program via serial/uart w. stm32flash , and it seems like Tormod made it use 128K for a stm32f103c8
https://sourceforge.net/projects/stm32flash/
There's a 64-bit win exe here
https://sourceforge.net/projects/stm32flash/files/


Edit: Seems line imu is using STM's st-link to program 90k Forth into a 64K device wo. problems , that means the BMP combined might be progra,med w. st-link too.
That ought to make life easier for a M$ user.

Programmer
----------------------
I use a cheap st-link "usb alu stick" clone , and SWD for programming the bluepill.


***** st-link for "easy" programming  else use oocd *****
Try to install via your distro's install first


else build from source

git clone https://github.com/texane/stlink
cd stlink
make
cd build/Release
make
make install
(make sure /usr/local/lib/ is in some .conf file in /etc/ld.so.conf.d)
ldconfig





********  Program the Bluepill w. the combined dfu & binary in the attached zip *****

st-flash erase
** Now disconnect & reconnect the BMP

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!


************ DONE *******************


DIY

BMP project recommends swlink as probe target for a bluepill

git clone --recursive https://github.com/blacksphere/blackmagic.git
cd blackmagic
make
cd src
make clean
#make PROBE_HOST=stlink
make PROBE_HOST=swlink




***** st-link for "easy" programming  else use oocd *****
Try to install via your distro's install first


else build from source

git clone https://github.com/texane/stlink
cd stlink
make
cd build/Release
make
make install
(make sure /usr/local/lib/ is in some .conf file in /etc/ld.so.conf.d)
ldconfig





********  Program the Bluepill dfu & then upgrade *****

Requires that you have build from source (DIY).


st-flash erase

blackmagic/upgrade$ sudo st-flash erase
st-flash 1.5.1-50-g3690de9
2019-12-10T19:54:20 INFO common.c: Loading device parameters....
2019-12-10T19:54:20 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-12-10T19:54:20 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
Mass erasing

** Now disconnect & reconnect the BMP

Flash the dfu bootloader
st-flash --flash=0x20000 write blackmagic_dfu.bin 0x8000000

Now the dfu bootloader is programmed
** Now disconnect & reconnect the BMP




dfuutil will fail if the binary is larger than 64KB , on a stm32f103c8 device.
It honours the flashsize reported from the c8 , even if it "has" 128KB


But there is a "trick" ....
 
If blackmagic DFU is installed on the BMP you can use the blackmagic_upgrade executable to upgrade the BMP
The blackmagic_upgrade is included as source in the upgrade dir.


First build blackmagic_upgrade
----------------------------------
If you are in the src dir , then cd ../upgrade , then :
make

Now blackmagic_upgrade should be there.

sudo ./blackmagic_upgrade   

Will upgrade the target w. a  blackmagic.bin from ../src     -- use sudo


/blackmagic/upgrade$ sudo ./blackmagic_upgrade
[sudo] password for bingo:       

Black Magic Probe -- Firmware Upgrade Utility -- Version 1.0
Copyright (C) 2011  Black Sphere Technologies Ltd.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

Resetting device in firmware upgrade mode...
Found device at 003:006
All operations complete!

/blackmagic/upgrade$


*********** DONE ******************