(via a github issue https://github.com/rogerclarkmelbourne/ … /issues/45 )
Which includes a USB Mass Storage Device bootloader.
Note however.
These bootloaders appear to be closed source, and only free for personal / educational use. 
And it is HUGE: 12KB!
Also closed source, I found this one which occupies only 4KB:
https://www.elektroda.pl/rtvforum/topic3212595.html
Don’t tell anybody, but my secret goal while working on the HID bootloader was to reduce its size in order to make room for an MSD version 
The HID bootloader is now down to less than 2KB, and modular enough. I also have almost ready the MSD/SCSI command parser and a pseudo-FAT that are both tiny and that should fit within 4KB total with the USB driver taken from the HID bootloader.
And of course, I will realease this as open source 
I’m not that surprised about the size of that bootloader as it has to implement a fake FAT32 file system, and it seems to support both writing and reading of the application.
I have seen some smaller MSD bootloaders, but they don’t implement a fake FS, and only work in block mode with special programs like win32imager.
(So are even less useful)
Some people may find it useful, but I don’t see any point in integrating it into the libmaple upload tools, as MSD is a bit of a pain to automate, because the uploader has to enumerate the drives that are attached and find the one with the correct name etc.
I guess 12kb would be fine for F4, but I’m happy to wait and see what squonk42’s looks like
[RogerClark – Mon Jan 28, 2019 6:42 am] –
I should have pointed out its 12kI’m not that surprised about the size of that bootloader as it has to implement a fake FAT32 file system, and it seems to support both writing and reading of the application.
I have seen some smaller MSD bootloaders, but they don’t implement a fake FS, and only work in block mode with special programs like win32imager.
(So are even less useful)Some people may find it useful, but I don’t see any point in integrating it into the libmaple upload tools, as MSD is a bit of a pain to automate, because the uploader has to enumerate the drives that are attached and find the one with the correct name etc.
Implementing a fake FAT FS does not take 12 KB, I suspect thay are using the bloated STM USB Device driver.
You just have to handle 512B block R/W operations and provide a fixed answer to boot sector (sector 0), FATs (sectors 1 and 2) and root directory (sector 3) requests, all the other ones belong to your pseudo files. The only trick if you want to use it to flash is that 512B writes are not necessarily ordered, so that you have to maintain a 64 or 128-bit bitmap of 1KB flash sectors (2x FAT sectors) to erase beforehand.
Here is my attempt to it as an application (not a bootloader yet!), that enumerates as a FAT12 disk on Linux, but not under Windows yet, due to a descriptor problem I have to solve:
https://github.com/Squonk42/STM32_MSC_Bootloader
Right now I only expose a single “FIRMWARE.BIN” file, but the idea to expose all Flash, RAM and an HTML file to redirect to instructions is a good idea.
[zoomx – Mon Jan 28, 2019 8:39 am] –
MSD is useful especially for a third person that can update an STM32 device in a simple way without any tools. OR update an STM32 in place without any tools.
The “fun” is in the design & implementation of MSD but in STM32 uC land, end-user firmware upgrade via drag & drop just blows my mind as the USB-MSD Implementation implies a uC device tethered to a PC by a physical cable. Maybe 5 or 7 years ago, but the current state of the art is toward web-hosted implementations.
Espressif example: log into the web page hosted by the ESP, select firmware upgrade, the java script in the local PC browser will open a small file explorer window, navigates to new firmware, upload commences, ESP reboots with new image. Alternately a TFTP session can provision too.
There are some consumer devices that can be removed from their useful physical location, transported to the home PC, connected to PC with a USB cable, powered-up, and the firmware upgrated. But in the shadows of Google and Amazon, consumers expect their devices to be wirelessly upgraded via a web interface running on their tablet or smartphone. A few years from now, a household may not own a USB cable.
Ray
[mrburnette – Mon Jan 28, 2019 4:14 pm] –[zoomx – Mon Jan 28, 2019 8:39 am] –
MSD is useful especially for a third person that can update an STM32 device in a simple way without any tools. OR update an STM32 in place without any tools.The “fun” is in the design & implementation of MSD but in STM32 uC land, end-user firmware upgrade via drag & drop just blows my mind as the USB-MSD Implementation implies a uC device tethered to a PC by a physical cable. Maybe 5 or 7 years ago, but the current state of the art is toward web-hosted implementations.
Yes, and the standard is UF2 by Microsoft, and it is indeed based on the MSD:
https://github.com/Microsoft/uf2
Or there is also WebUSB/WebDFU:
https://wicg.github.io/webusb/
https://github.com/devanlai/webdfu
[Squonk42 – Mon Jan 28, 2019 4:43 pm] –
…
Yes, and the standard is UF2 by Microsoft, and it is indeed based on the MSD:
…
Great to know the direction of the approach; let the coding begin.
One of the things I miss in this forum is the articulation of the end game; the design/architectural statement on the current state and the ultimate goal with the checkpoints identified along the way.
Ray
[mrburnette – Mon Jan 28, 2019 9:26 pm] –
One of the things I miss in this forum is the articulation of the end game; the design/architectural statement on the current state and the ultimate goal with the checkpoints identified along the way.
Come on, this makes things too easy 
[Squonk42 – Mon Jan 28, 2019 4:43 pm] –
Yes, and the standard is UF2 by Microsoft, and it is indeed based on the MSD:
https://github.com/Microsoft/uf2Or there is also WebUSB/WebDFU:
https://wicg.github.io/webusb/
https://github.com/devanlai/webdfu
I haven’t tried this myself, but this UF2 bootloader claims to weigh in at 16KiB. It also has support for a lot of other stuff, including WebUSB, but I’m not sure if those build configurations all fit in 16KiB, as I have not actually tried building it:
https://github.com/lupyuen/bluepill-bootloader
[mrburnette – Mon Jan 28, 2019 4:14 pm] –
a uC device tethered to a PC by a physical cable.
You can use a smartphone with USB OTG.
The ESP8266 way is better!
You still have microcontrollers that do not need to communicate but should last forever on non-rechargeable batteries, some others with an ultra low-power proprietary ISM RF (average power consumption with regular RX/TX < 10µA), and chips that communicates with standard RF networks like Bluetooth or Wi-Fi, both of them not being considered as low-power (even BLE) to my eyes, as they require rechargeable batteries. I know there is inductive charging, but this means that these devices needs a manual operation and cannot be left unattended for years.
For the first category, FOTA is not an option and will not be in the near future, and programming using a cable will still be there for years. Look: we are still using UARTs even if there are no more RS232 on PCs for at least 10 years 
STM32s are definitely in this first category, although not the lowest power ones (EFM32s are much better in this regard), but they are cheap and full of peripherals and lots of GPIOs, so they have still their place in the sun, even if they have long teeth. Same for 555 or AVRs, isn’t it?
[BennehBoy – Tue Jan 29, 2019 9:16 pm] –
Ray is an architect don’t forget, forever blue skies
Now, now …my skies have clouds, too. But, only if I design ’em into the project.
[Squonk42 – Tue Jan 29, 2019 9:07 pm] –
…
For the first category, FOTA is not an option and will not be in the near future, and programming using a cable will still be there for years. Look: we are still using UARTs even if there are no more RS232 on PCs for at least 10 years
…
STM32s are definitely in this first category, although not the lowest power ones (EFM32s are much better in this regard), but they are cheap and full of peripherals and lots of GPIOs, so they have still their place in the sun, even if they have long teeth. Same for 555 or AVRs, isn’t it?
My last project still used a few (very few) discrete components. We are not discussing long-in-the-tooth components here; the topic is firmware installation into a uC. In considering this need, the prime assumption is re-programming by end-users: as such, there is a legitimate need to keep the process simple and error-free. My point earlier is simple: the mass market has already set the expectation for this need (Alexa, Google Assistant, iPhone, Android, Kindle) and that customer expectation does not (generally) require the use of a USB cable.
It is only smart business to leverage the mass market knowledge to ride the wave of acceptance. Of course, this only applies to commercial products, prototypes, and the occasional prototype sent to family or friends. The more we shadow the market momentum the less resistance to adoption & the simpler the role of user support.
From a forum prospective, the ideal solution is to provide a bootloader which can work exactly the same across all PC platforms: Linux, macOS, Windows. The ideal bootloader would need no driver installation on the host OS. That ideal bootloader would also consume a minimum of uC resources: flash and SRAM – and the SRAM should be left “free” immediately before the jump to the user program. Common upload methods for STM32DUINO and now the HID bootloader.
For we hobbiests, do what you want, no justification is needed if you use a bootloader or silicon serial or ST Link.
Ray
