Hi Pito, that was very handy and it worked.
After flashing bootloader I tried to program a sketch using upload method set to STM32duino bootloader.
The Arduino IDE then complained then dfu-util could not work.
Searching around it was 64 bit and the 32 bit I was running my Ubuntu 14.04 on.
So rebuilt it using the instructions here:viewtopic.php?f=27&t=466&hilit=dfu+util%3A+cannot+execute+binary+file%3A+Exec+format+error&start=10#p4549
It turns that had some problems - build_dfu-util.sh had a syntax error.
sudo apt-get install build-essentials should read sudo apt-get install build-essential
for my system.
Anyway generated the dfutils, moved the old ones to a separate directory and put in the new ones.
And that workd with the stbee image built with 12MHz.
On booting up the board through USB, I could upload a sketch with upload method set to STM32duino bootloader.
But after that I could not program it with another sketch.
Putting CPU into DFU mode by setting Boot0 to High, and pressing reset did not work.
Even STLink became unresponsive.
But then I managed to get STLink to work again by putting CPU into DFU mode and then programming using STLink.
I programmed the board a couple more times with stbee image, and tried to upload a sketch.
Always the first time is OK but second time onwards not OK.
Its as if the CPU could not be booted back into same mode like it gets to after it is flashed with the binary bootloader if something like blinky was programmed once by the Arduino IDE.
Wading through the bootloader code I can see #ifdef XTAL12M is where it gets its speed set up ( in hardware.c )
Then I checked the USB enumeration code and its different to what I was expecting.
The code I thought would be yanking PB9 to get the PC to re-enumerate the USB but instead its
now turning the USB peripheral on the chip on and off presumably for the same effect - though I can't see
how it implements all the details - I assume it done through call back functions.