4 years, 1 month ago.

when the online compiler will be updated ?

the last mbed-os version on github include new boards, example the BluePill. https://github.com/ARMmbed/mbed-os/tree/master/hal/targets/hal/TARGET_STM/TARGET_STM32F1

When the online compiler will be updated and we can choose the new boards ?

I was a little afraid that Bluepill will never be on the online version. And the branch that you see is only for ofline compilation. Bluepill does not meet the standard Mbed because it has no mechanism to write the program as a virtual drive, like all other STM32 boards available in the online compiler.

Another thing is this mbed code you show is a bug that caused trouble to the use of xtal embedded in Bluepill.
If you need to use Bluepill on mbed online is currently working solution:
https://developer.mbed.org/users/hudakz/code/STM32F103C8T6_Hello/

posted by Nothing Special 27 Aug 2016

Thanks for the link, let me have some question:

- there is many online resurce explain that many bluepill have 128kB flash, because ST produce many C8 cpu whit 128kB, so we can test it whit a big program for know witch mcu we have

- instead of a nucleo it is posdible use the cheap usb stlinkv2 clone

- the stm32duino project write a bootloader for usb upload programming, is it possible use\port it to mbed ?

- my bluepill link is merged in the master branch, is there an issue opened for the xtal problem that you tell ?

- when we export from online compiler, we receive a project whit mbed object library, which is the way for replace it whit the github mbed-os so we have sourcecode inside project ?

posted by Testato Testato 28 Aug 2016

1 Answer

4 years, 1 month ago.

Testato Testato wrote:

- the stm32duino project write a bootloader for usb upload programming, is it possible use\port it to mbed ?


Solutions using bootloader saved to FLASH, necessarily require that the user code (including own vector table etc.) was offset from the beginning of the FLASH (depending on size of the area which is the bootloader).
Mbed online compiler generates code from the beginning of FLASH. For this it is impossible (for now ;) ).


Testato Testato wrote:

- my bluepill link is merged in the master branch, is there an issue opened for the xtal problem that you tell ?


This vulnerability (HSE on board xtal) is affects not only Bluepill or even F103. For most (all?) Mbed STM32 is a problem in mbed library, on using the library HAL (version 1.4.4 and later). In short, the reason is the change in the function HAL_RCC_OscConfig.
The result is incorrect system clock initialization (clocked 64MHz from HSI instead of quartz precise 72MHz), despite xtal connected to the STM32. This defect makes it impossible to use of USB in the project or other precise timing applications, for example.

But the majority of the official mbed boards STM uses a clock from an external source (ST-Link MCO) or HSI. Therefore, the problem is not so visible.



Testato Testato wrote:

- instead of a nucleo it is posdible use the cheap usb stlinkv2 clone

Without any problem. Only a little less comfortable.
Bluepill can also be programmed without any programmer. Just RS232 adapter and Flash Loader Demonstrator.

Accepted Answer

Quote:

Solutions using bootloader saved to FLASH, necessarily require that the user code (including own vector table etc.) was offset from the beginning of the FLASH (depending on size of the area which is the bootloader). Mbed online compiler generates code from the beginning of FLASH. For this it is impossible (for now ;) ).

For fun, I just put together a USB DFU bootloader that can run mbed binaries without requiring any offset.

It doesn't do any delays at startup, so to upload code again, the application does need to implement a USB DFU runtime to support switching to the bootloader, but it is possible to use binaries from the online compiler.

See here for an example program:

Import programSTM32F103C8T6_USBDFU

Blinky example with USB Device Firmware Upgrade (DFU) detach support for use with a no-offset bootloader

posted by Devan Lai 29 Aug 2016

I know this solution. It is interesting, but rather for specific applications (eg., "In the field" firmware upgrade, etc.). For programming work it seems to me personally to be quite complicated and uncomfortable. It is better to use DFU on the newer STM32 then F103 where DFU bootloader is in the system memory. And can be used quite normal binaries, without any special requirements.

posted by Nothing Special 29 Aug 2016