Blinky example with WebUSB Device Firmware Upgrade (DFU) detach support for use with a no-offset bootloader.
Fork of STM32F103C8T6_USBDFU by
This is an experimental sample program demonstrating support for reprogramming an mbed-compatible device using WebUSB instead of the traditional drag'n'drop step. It is in the early stages of development and is currently very user-unfriendly.
This example currently has some very particular requirements:
- You must have Chrome 54 or later, which has experimental WebUSB support enabled on select sites through origin trials.
- Only one target board is currently supported, the STM32F103C8 "bluepill" board.
- The target board must be initially flashed with a custom bootloader that has WebUSB support and doesn't require a linker offset for the application.
There are three main components to this example:
- A WebUSB-enabled USB DFU bootloader that can accept and flash new firmware over USB
- The main application with USB DFU support that can receive a USB command to switch into DFU mode (aka, this example program)
- A website with WebUSB support that can send USB DFU commands to approved USB devices.
Workflow without mbed integration
This workflow effectively takes the normal USB DFU upgrade process and enables the user to use a browser instead of a native program like dfu-util. Note that this is still fully compatible with dfu-util.
During normal operation, the bootloader runs the main application, just like any other program. When the user wants to reprogram the board, the following steps occur:
- The user plugs the board in over USB
- The main application declares USB DFU and WebUSB support as part of the USB enumeration process. As part of declaring WebUSB support, the device also presents a whitelist specifying exactly which https origins can access it.
- Chrome detects WebUSB support and prompts the user to visit the corresponding website
- After navigating to the website, the site requests access to the board, which the user can grant or deny.
- To enable flashing new firmware, the website can send a DFU detach command to switch into the DFU bootloader
- Because the bootloader appears as a different USB device, the user must also approve access to the board in bootloader mode
- The user can select a local file from disk and download it to the board over DFU
- After successfully flashing the firmware, the bootloader resets and the new application runs.
After the user grants access to the board, the approval popup in steps 4 and 6 should no longer appear.
Workflow with some mbed integration
The mbed compile API allows access to remotely build mbed programs. This can be used to enable a user to authenticate with mbed, and then build and download mbed programs directly from the browser.
The steps are similar to above, but with a different webpage that uses the mbed compile API to build a program and uses the compiled output as an input to the DFU download instead of selecting a previously built local binary.
It currently only supports HTTP basic auth, so credentials must entered every time. There's also no way to enumerate which programs / target boards the user has, so the program and target board must be manually specified. Right now, the program is hard-coded to this example program and the STM32F103 target board.
Instead of using a WebUSB-enabled DFU bootloader (which I used only because I already had a DFU bootloader lying around), the mbed HDK CMSIS-DAP/DAPLink firmware could be extended to add a new WebUSB interface. The website could then talk to the mbed HDK chip to flash the firmware onto the target board. This would allow any mbed-enabled board to flash firmware via WebUSB without any changes to the target program (and without requiring native USB support).
The end-goal, of course, would be to integrate WebUSB support into the official mbed IDE (or at least a reasonably functional demo-equivalent) to allow the user to flash boards directly from the online IDE without going through the extra drag'n'drop step