Small USB HID bootloader for BluePill and other STM32F10X devices

[RogerClark]

I amended the PR to @serasidis with the changes to put the HID bootloader in high-memory for the STRM32F1xx:
https://github.com/Serasidis/STM32_HID_ ... der/pull/7

Will the core's need to be updated ?

Since the application code will need to have its start address (of the vector table), at 0x800000

Or do you think that the cores may generate position independent code ?
( My guess is that the code is not guaranteed to be position independent)


BTW.

I remember that @jcw aka JeeLabs write a serial bootloader that resided in high memory, but I think he abandoned it for some reason (but perhaps he is still using it and developing it).
You could PM him, as he used to be active on the forum several years ago

[Squonk42]

Use of the reserved vectors is an interesting idea.

My only concern is that adding code to read the data in the reserved vector, may make the bootloader bigger, beyond a flash page boundary.

But I suppose that since its now in high memory, then the size trade off for increase flexibility is probably worthwhile.

Using the latest GCC 8.2.1 from ARM Ltd. (Version 8-2018-q4-major Linux 64-bit), the bootloader size is currently 1924 bytes in high-memory, plus 8 bytes for the initial MSP and PC in low-memory, so there is 124 bytes left in high-memory before reaching the 2KB (2048 bytes) page boundary, which should be more than enough.

[Squonk42]

[Will the core's need to be updated ?

Since the application code will need to have its start address (of the vector table), at 0x800000

Or do you think that the cores may generate position independent code ?
( My guess is that the code is not guaranteed to be position independent)

The HID bootloader contains a ZIP file to patch your core, and this PR contains a new updated one, and @BennehBoy send a PR to integrate it into the STM Core:
https://github.com/stm32duino/Arduino_C ... 2/pull/415

Basically, this patch replaces the "board.txt", "platform.txt" to add the HID bootloader, includes the "usb_serial.cpp" with the DTR + magic word, and adds the linker scripts to match the bootloader memory organization.

It would be great to update your core, but maybe wait a little bit more until the HID bootloader is more stable?

I don't think the core will need to generate PIC, but having a different file for each bootloader is a pain. We could take @BennehBoy and @fpiSTM idea and perform linker script preprocessing in the "platform.txt" file:

Code: Select all

# preprocess linker file
preprocld.name=preproc.ld
preprocld.filepath={build.path}/{preprocld.name}
preprocld.flags=-DLD_MAX_SIZE={upload.maximum_size} -DLD_MAX_DATA_SIZE={upload.maximum_data_size}
recipe.hooks.linking.prelink.1.pattern="{compiler.path}{compiler.c.cmd}" -x c -E -P {preprocld.flags} {compiler.c.flags} {build.info.flags} {compiler.c.extra_flags} {build.extra_flags} {compiler.arm.cmsis.c.flags} "{build.variant.path}/{build.ldscript}" -o "{preprocld.filepath}"

The linker script for the Bluepill can then become:

Code: Select all

RAM (xrw)      : ORIGIN = 0x20000000, LENGTH = LD_MAX_DATA_SIZE
FLASH (rx)      : ORIGIN = 0x8000000, LENGTH = LD_MAX_SIZE

It should be possible to define some new tags in the "board.txt" and "platform.txt" to accomodate for the different bootloader configurations: low/high memory and user sketch/bootloader size and generate a linker script on the fly after cpp preprocessing.

Anyway, the HID bootloader being in high-memory, the sketch base address is now compatible with the STLink, JLink, serial and OCD bootloaders, and this technique could well be applicable to the DFU bootloader too.

[RogerClark]

Can I merge this PR before your PR to the bootloader is merged?

BTW. I think I may need to manually merge platform.txt as Ive just changed platform.txt to fix a bug with stlink uploads.

Edit.

I got confused, I thought the PR was for my core, but when I looked in detail, I saw its the STM core.

So I'll need to find the zip file you referenced, to see what the patch does


Edit.

Where is this zip

Can you post a link ?

Edit

I found it

https://github.com/rogerclarkmelbourne/ ... 202_01.zip

[RogerClark]

I've added and updated the files in the tools folder.

Note. The Mac binary was not marked as executable, so I've changed it to executable on my Linux machine. But this does not guarantee the permissions will work on the Mac. I'd need to pull the repo onto my mac and confirm this, but perhaps someone who regularly uses a mac can check this

[Squonk42]

I am Linux only, I asked @serasidis to update the tools and fix the permission problem too.

[RogerClark]

I am Linux only, I asked @serasidis to update the tools and fix the permission problem too.

I have Windows, Linux and OSX machines, but I hardly ever use OSX, I only have OSX to do builds for work clients.

I'll manually merge the changes to boards.txt and platform.txt using my Windows (7) PC later today.

[BennehBoy]

Looking at the github repo, all but the maple_mini version appear to be geared toward 64KB flash.

For now I guess this means that those with 32KB or 128KB flash devices will need to be capable of editing/supplying the correct linker script, modifying the makefile, and re-compiling.

Are pre-compiled binaries for the above on the roadmap?

I'm just thinking of how noobies might hit issues that high mem introduces.

[RogerClark]

Maple mini should always have 128k, but of course vendors could just rebadge C6 MCU's as CB's

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

[Vassilis]

https://github.com/Serasidis/STM32_HID_ ... der/pull/7

I revert the previous HID-BL version on Github because we first need to talk about what we want from this Bootloader for all MCU devices that we want to support and how to handle the best code strategy to do that.

For example, the F40x and F41x devices have 128kB at the last sector. That means, we sacrifice a lot of flash memory for the bootloader.