DFU support (Phase 1)

[kpfleming]

Implementation of #77.

• Adds "DFU Runtime" support while the application is in "HID" (normal) mode; this is controllable in user_config.h and defaults to 'off'. This allows a DFU tool to trigger a reboot into "DFU" mode.

• Adds "DFU" mode for the application, which avoids most normal setup steps and prepares the device for firmware/config upload or download. The board still stay in this mode for a maximum of 30 seconds, and will reboot if no successful DFU operation occurs within that time.

• Adds serial number reporting using the Pico SDK "unique_id" function which obtains the hardware serial number from the flash chip.

• Refactors usb_descriptors.c into dfu.c and hid.c for clarity.

• Adds DFU 'upload' mode, allowing the user to obtain the current firmware or runtime configuration from the device.

• Adds DFU 'download' mode, allowing the user to flash new firmware or configuration to the device. The device will automatically reboot after the flash operation.

Since this is 'phase 1', it only supports DFU operations against the board it is attached to (A or B), it does not support operations against the 'other' board over a single connection. This means that upgrading firmware must be done twice, connecting to each board.

[hrvach]

I'll test it a bit and play around with it, on first look it seems very well done. Thank you for contributing!

[kpfleming]

Thanks! I'm going to keep this in draft mode until it actually has some functionality that is useful :-)

(Edit: thoughts about cross-board communication removed)

[kpfleming]

More progress: it is now possible to use DFU to extract the firmware and config from a running board :-)

Example commands (while connected to board A; change 'a' to 'b' if connected to board B):

dfu-util -a board_a_fw -d 2e8a:107c -D firmware.bin
dfu-util -a config -d 2e8a:107c -D config.bin

In each case dfu-util will trigger the board to reboot into DFU mode and perform the transfer. The board will reset itself to normal mode 500ms after the transfer has been completed.

[kpfleming]

I have now successfully used this to upgrade firmware a half-dozen times. I'll write some docs for it tomorrow and then it will be ready for review/testing.

[kpfleming]

Also, apologies for the inconsistent code formatting... I've tried to follow the style in various source files but they aren't consistent with each other so it was challenging!

[kpfleming]

Documentation has been added and I've re-ordered the commits so that the first three are simpler to review (they don't include the DFU code).

[kpfleming]

Going back to draft mode; I need to do some more work on handling configuration data.

[kpfleming]

I spent some time trying to determine whether it made sense to build a simple 'transfer configuration over the UART link' mechanism, but decided that it does not make sense at this time as we'll eventually want to be able to transfer entire firmware binaries over that link too and the design will need to be done with both usages in mind.

Given that, I'm putting this back in 'ready to review' mode after updating DFU.md to demonstrate how to upload configuration data into both boards.

[kpfleming]

Before this can be merged, a second request will need to be made to the RPi team for a PID for the DeskHop to use while in 'DFU transfer' mode. This is primarily needed for Windows, since Windows assigns combinations of drivers to VID/PID combinations, and when the board goes into that mode it should not have any HID drivers attached to it, which would happen if the PID did not change.

[hrvach]

Haven't forgotten about this, don't worry - just been super busy. Thanks again for working on this, I'll take a look as soon as I can scrape some free time.

[kpfleming]

Closing this as the entire firmware upgrade/configuration process has been redesigned.