Idea for an "end user" bootloader (mass storage device)

In my synth-project thread (I’m sure nobody follow it, expect Victor ) I wrote about an idea about a “drag&drop – mass storage device bootloader”:

This is an old idea of mine, while playing with the Nucleo boards: The (onboard) ST-Link v2.1 connect to the PC as “mass storage device” You just drag&drop the *bin file for upload. This must be an (quiet) easy solution for a “drag&drop” bootloader. So this special bootloader can be uploaded as a “final step” on a finished product (Maybe this functionality is an exchange for the “perpetual bootloader” ).
I believe many of us will not only working for ourselves but making projects for family, friends or even commercial. So this end-user can easily upload a new firmware via a drag&drop bootloader without installing anything. Should be possibly – or?

madias wrote:I’m sure nobody follow it, expect Victor

I have read it too. I remember this way of uploading of the Nucleo.

So this end-user can easily upload a new firmware via a drag&drop bootloader without installing anything. Should be possibly – or?

I live a very simple life with the Maple Mini clone. Does the world need a drag&drop bootloader? Is not all of the magic done on the host machine? That is: editor, compiler, linker, and finally the use if a custom utility to upload the binary HEX to the attached microcontroller board. Other than the “cutness”, why introduce s manual operation… unless one intends on only posting binary giles?

If I am missing the obvious, I apologize, but I am old and my 34 year old daughter thinks I am crotchety.

Ray

mrburnette wrote:but I am old and my 34 year old daughter thinks I am crotchety.

Madias, check this thread I just started, I found a project that implements a mass storage device in a sketch:
http://www.stm32duino.com/viewtopic.php?f=13&t=585

May be even better than implementing it in the bootloader. If you can implement MIDI and the USB Storage at the same time in the sketch, one would only need to write a certain file to the mass storage to update the fw.

I wonder how whether the bootloader size would be larger than the DFU version?

I guess the benefit of this would be for web based development e.g. like mbed and also what the BBC in the UK are doing with their new board for schools “BBC Mico bit” (I think thats its name)

Personally I’m not a fan of online IDE’s as they tend to be clunky and slower than local IDE’s, but it does appear to be the way things are going for educational dev systems, and other dev systems for possible less tech minded people e.g. Spark Photo use an online dev env I think.

I think, there is a little misunderstood related to my idea:
This bootloader should only be useable for “end user”. As example: Ok, I finished my synthesizer project and build about 5-10 prototypes. I would sold them on a local internet market to finance my next project. But the synth-firmware is still in progress (bugfixes, new features…). None of the people who bought the synth are able (or willing) to install several drivers/IDE’s/toolchains.
So they only need to download the new firmware on internet, getting the synth into upload mode (perpetual bootloader) and drag&drop the new firmware from PC into the synth.
Including this upload routine into the main code would be very dangerous: Just a little mistake, broken cable, wrong binary and the synth would be bricked and can only be reanimated with USB-ttl, ST-Link, etc.

For developers this bootloader would be … mostly useless

I don’t like online IDE too but maybe it is the best choiche for teaching purpouse since the maintenance is much simple and all students have the same compiler. I don’t believe that all schools that use Arduino have the 1.6.5 IDE, for example.

madias,
maybe this bootloader can be used for remote upload.

madias wrote:I think, there is a little misunderstood related to my idea:
This bootloader should only be useable for “end user”. As example: Ok, I finished my synthesizer project and build about 5-10 prototypes. I would sold them on a local internet market to finance my next project. But the synth-firmware is still in progress (bugfixes, new features…). None of the people who bought the synth are able (or willing) to install several drivers/IDE’s/toolchains.
So they only need to download the new firmware on internet, getting the synth into upload mode (perpetual bootloader) and drag&drop the new firmware from PC into the synth.
Including this upload routine into the main code would be very dangerous: Just a little mistake, broken cable, wrong binary and the synth would be bricked and can only be reanimated with USB-ttl, ST-Link, etc.

For developers this bootloader would be … mostly useless

Maybe using the serial port programming is a good solution for firmware updating your project.
That approach gives you the safety you want to avoid the stm32 brick.
Moreover, the only additional hardware you need is a cheap usb-to-serial converter.

The software for programming the stm32 seams very simple and compact. I have not tested it yet.
https://github.com/MightyDevices/STBootLib/releases

After a second thought, the sequence of pressing the reset and boot0 buttons is not very user-friendly way to do a firmware update.

Anyway, it is up to you what you finally choose. Every uploading method has advantages and disadvantages.

Looks ok, but Windows only (ok, compiling should be possible for other OS)
Drawback: Nearly all USB-TTL converter need at least under Windows a additional driver.
For my project I can manage it to upload the firmware via MIDI All you need is time and a coffee. So getting via sysex the new firmware, writing it to my 4-mb flash (next to the original firmware) and then update it via software. Another method could be: Just put the firmware on SD card.

Another possibility is to do the opposite : having some USB OTG Mass Storage where end-user simply plug an USB dongle where the new firmware has been uploaded/copied, then the firmware can access to the USB Storage, see that new firmware is present, and offer choice to upgrade thru LCD menu or Serial menu.

madias wrote:Looks ok, but Windows only (ok, compiling should be possible for other OS)
Drawback: Nearly all USB-TTL converter need at least under Windows a additional driver.
For my project I can manage it to upload the firmware via MIDI All you need is time and a coffee. So getting via sysex the new firmware, writing it to my 4-mb flash (next to the original firmware) and then update it via software. Another method could be: Just put the firmware on SD card.

victor_pv wrote:
If you are including a 4Mb flash, and have enough space, what I probably do is include the mass storage in your sketch.
If the user writes a file there, the sketch saves it to a reserved area of the 4Mb flash (checking a checksum or something to confirm is all good).
If it is good, then it sets a flag somewhere to indicate new FW is available in the spi flash.

Then in your bootloader, on boot up, just check if there is a new fw in the spi flash, if it is, copy it to the mcu flash (skipping the bootloader area) and clear the flag.

For the user, is as simple as write update file to the mass storage device, reboot device. Done.

As for presenting the masstorage to the computer, it does not need to be there all the time, but only if you press a certain button during boot up, or select an option in a menu. Then the device presents itself as a storage device and waits for the right file to be written to it.

So the user intervention would be such as:
1.-Press certain button or select fw update in menu.
2.-Write fw update file to the mass storage device.
3.-Reboot and let it update.
4.-Reboot again with updated fw.

Only if the STM32 has a flag to avoid the copy of the internal flash. Otherwise you can decompile the algorytm or run it in a emulator.

zoomx wrote:Only if the STM32 has a flag to avoid the copy of the internal flash. Otherwise you can decompile the algorytm or run it in a emulator.