Small USB HID bootloader for BluePill and other STM32F10X devices

Generic boards that are not Maple or Maple mini clones, and don't contain the additional USB reset hardware
User avatar
Squonk42
Posts: 551
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Squonk42 » Mon Feb 04, 2019 12:40 pm

RogerClark wrote:
Mon Feb 04, 2019 9:24 am
Maple mini should always have 128k, but of course vendors could just rebadge C6 MCU's as CB's :-(
Or C8s that are actually CBs 8-)
RogerClark wrote:
Mon Feb 04, 2019 9:24 am
One other thing that you may have already considered with the high memory bootloader is conflicts with the EEPROM library which also uses high memory.

Code: Select all

#ifndef EEPROM_PAGE_SIZE
	#if defined (MCU_STM32F103RB)
		#define EEPROM_PAGE_SIZE	(uint16)0x400  /* Page size = 1KByte */
	#elif defined (MCU_STM32F103ZE) || defined (MCU_STM32F103RE) || defined (MCU_STM32F103RD)
		#define EEPROM_PAGE_SIZE	(uint16)0x800  /* Page size = 2KByte */
	#else
		#error	"No MCU type specified. Add something like -DMCU_STM32F103RB to your compiler arguments (probably in a Makefile)."
	#endif
#endif
#ifndef EEPROM_START_ADDRESS
	#if defined (MCU_STM32F103RB)
		#define EEPROM_START_ADDRESS	((uint32)(0x8000000 + 128 * 1024 - 2 * EEPROM_PAGE_SIZE))
	#elif defined (MCU_STM32F103ZE) || defined (MCU_STM32F103RE)
		#define EEPROM_START_ADDRESS	((uint32)(0x8000000 + 512 * 1024 - 2 * EEPROM_PAGE_SIZE))
	#elif defined (MCU_STM32F103RD)
		#define EEPROM_START_ADDRESS	((uint32)(0x8000000 + 384 * 1024 - 2 * EEPROM_PAGE_SIZE))
	#else
		#error	"No MCU type specified. Add something like -DMCU_STM32F103RB to your compiler arguments (probably in a Makefile)."
	#endif
#endif
Which I think would mean the EEPROM library may overwrite the bootloader
Yes, good catch!

But why is the EEPROM library using hard-coded constants instead of using the linker-defined symbols to get the end of the Flash region?

EDIT: It looks like there is no PROVIDE in the linker script for the memory regions :(
Last edited by Squonk42 on Mon Feb 04, 2019 2:19 pm, edited 1 time in total.

User avatar
Squonk42
Posts: 551
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Squonk42 » Mon Feb 04, 2019 12:53 pm

The main idea with the high-memory bootloader is at least for the F1, to be able to compile a sketch that is compatible with most bootloaders (Serial, STLink, BMP. DFU could probably be converted too, but not Maple DFU, of course), based at the bottom of the Flash memory, provided you don't go too close from the maximum memory size. Otherwise, if the BL are placed in low-memory before the user sketch, you will need to generate one binary at each different offset, depending on the bootloader size.

It is less an issue for the F4 which has the DFU bootloader in ROM, and for which the main advantage is that the HID bootloader does not require a driver on the host side.

As per my PR, you can see that it is possible to now put the F1 HID BL wherever we want, and it is probably quite easy to do the same for the DFU one.

So I guess it is more a question if we want to keep a binary hardware compatibility for sketches across bootloaders, or if we only guarantee sketch compatibility at the source level.

User avatar
Vassilis
Posts: 480
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Vassilis » Mon Feb 04, 2019 4:24 pm

Squonk42 wrote:
Mon Feb 04, 2019 12:53 pm
The main idea with the high-memory bootloader is at least for the F1, to be able to compile a sketch that is compatible with most bootloaders (Serial, STLink, BMP.
That is a great advantage! One generic bin file that can be used with Serial, ST-Link and HID-BL.

People must know that burning a file with ST-Link to a device with HID Bootloader installed, will corrupt the HID Bootloader even if the bootloader is stored at the end of the flash.
Squonk42 wrote:
Mon Feb 04, 2019 12:53 pm
So I guess it is more a question if we want to keep a binary hardware compatibility for sketches across bootloaders, or if we only guarantee sketch compatibility at the source level.
In my opinion, binary hardware compatibility is more important.

User avatar
mrburnette
Posts: 3001
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by mrburnette » Mon Feb 04, 2019 4:29 pm

Squonk42 wrote:
Mon Feb 04, 2019 12:53 pm
...
So I guess it is more a question if we want to keep a binary hardware compatibility for sketches across bootloaders, or if we only guarantee sketch compatibility at the source level.
From time-to-time I have seen inquires in the forum regarding uploading binary blobs, in fact I wrote a Windows script many years ago to do the same: https://www.hackster.io/rayburne/avr-fi ... duplicator

But, my suspicions are that > 99% of users simply utilize the IDE to compile, link, upload.

There was a time in the dark ages of computers where "linked overlays" were utilized due to small main storage, but I have not heard of that technique being applied to microcontrollers based upon Harvard architecture.

I find the idea interesting, buy I am not generally a pro-bootloader kind of dude.


Ray

User avatar
Squonk42
Posts: 551
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Squonk42 » Mon Feb 04, 2019 8:25 pm

Vassilis wrote:
Mon Feb 04, 2019 4:24 pm
Squonk42 wrote:
Mon Feb 04, 2019 12:53 pm
The main idea with the high-memory bootloader is at least for the F1, to be able to compile a sketch that is compatible with most bootloaders (Serial, STLink, BMP.
That is a great advantage! One generic bin file that can be used with Serial, ST-Link and HID-BL.

People must know that burning a file with ST-Link to a device with HID Bootloader installed, will corrupt the HID Bootloader even if the bootloader is stored at the end of the flash.
Squonk42 wrote:
Mon Feb 04, 2019 12:53 pm
So I guess it is more a question if we want to keep a binary hardware compatibility for sketches across bootloaders, or if we only guarantee sketch compatibility at the source level.
In my opinion, binary hardware compatibility is more important.
OK, so if I understand you well, you are for having the maximum binary compatibility for sketches .bin among the different bootloaders? What about the F4, then?
Last edited by Squonk42 on Mon Feb 04, 2019 8:49 pm, edited 1 time in total.

User avatar
BennehBoy
Posts: 886
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by BennehBoy » Mon Feb 04, 2019 8:26 pm

Just what's the point of binary compatibility? Each bootloader has a different size so won't there be linker issues? Educate me.
-------------------------------------
https://github.com/BennehBoy

User avatar
RogerClark
Posts: 8416
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by RogerClark » Mon Feb 04, 2019 8:35 pm

I agree with Ray...

I don’t see any need for binary application compatibility either.

It’s generally only needed in closed source situations.

I don’t remember seeing any closed source Arduino firmware application files, or for that matter many Arduino open source applications which are distributed as binaries.


And with reference to Vassilis comment about people knowing that they will effectively render the HID bootloader useless if they upload via STLINK or Serial...

I think this a complex concept to explain to most people, and is most likely to be miss-understood.



This concept reminds me of the original Cyoress PSOC boards, which contained the bootloader in the preinstalled application that came with the board.
But if users failed to add the bootloader module to their applications... As soon as they had uploaded their first application, the board was effectively “bricked”, because the could no longer upload to it.

Cypress realised after a while that this was a problem and changed the hardware to include a built in upload interface akin to a STLINK

User avatar
Squonk42
Posts: 551
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Squonk42 » Mon Feb 04, 2019 8:36 pm

mrburnette wrote:
Mon Feb 04, 2019 4:29 pm
But, my suspicions are that > 99% of users simply utilize the IDE to compile, link, upload.
It is probably true for Arduino sketches where you get the sources and have free tools, but more debatable for other platforms, and in this case, binary compatibility would be a must.
mrburnette wrote:
Mon Feb 04, 2019 4:29 pm
There was a time in the dark ages of computers where "linked overlays" were utilized due to small main storage, but I have not heard of that technique being applied to microcontrollers based upon Harvard architecture.
Ray, I don't understand your point here: could you elaborate, please? Many years ago, I used overlays, but I don't understand the link with this bootloader stuff: overlays were used to load into main memory part of an application to perform some tasks, whereas a BL is just to ease flashing the main application.

(BTW, it was not so many years ago: I had to use overlays in a project involving a proprietary video processor with very limited memory capacity, where the application was sliced into distinct tasks loaded as overlays upon need).
mrburnette wrote:
Mon Feb 04, 2019 4:29 pm
I find the idea interesting, buy I am not generally a pro-bootloader kind of dude.
Using a bootloader that shares the usual link with the MCU (in this case, USB) is a nice convenience, rather than having to hook up additional wires for either JLink or Serial (bootloaders too in their own way :mrgreen: ) programming.

User avatar
Squonk42
Posts: 551
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Squonk42 » Mon Feb 04, 2019 8:43 pm

BennehBoy wrote:
Mon Feb 04, 2019 8:26 pm
Just what's the point of binary compatibility? Each bootloader has a different size so won't there be linker issues? Educate me.
If all binaries are based at the bottom of Flash memory and your linker script takes into account the bootloader size, then a binary that fits into Flash for the largest bootloader will also work as-is with the other (smaller) bootloaders.

User avatar
Squonk42
Posts: 551
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France
Contact:

Re: Small USB HID bootloader for BluePill and other STM32F10X devices

Post by Squonk42 » Mon Feb 04, 2019 8:49 pm

RogerClark wrote:
Mon Feb 04, 2019 8:35 pm
I don’t see any need for binary application compatibility either.

It’s generally only needed in closed source situations.

I don’t remember seeing any closed source Arduino firmware application files, or for that matter many Arduino open source applications which are distributed as binaries.
Despite this forum name and motto, there is some people here that do not only use the Arduino framework ;)
RogerClark wrote:
Mon Feb 04, 2019 8:35 pm
And with reference to Vassilis comment about people knowing that they will effectively render the HID bootloader useless if they upload via STLINK or Serial...
If they have STLINK or Serial programming skills, then they probably don't need the HID bootloader, or at least they are able to re-enable it if needed by reflashing it with these tools, no need to explain much.

Post Reply