[glopesdev]

This adds firmware updates for the PIC32 coprocessor of the SoundCard, so the update command can write both processors of a SoundCard on any platform.

Harp.Toolkit.Core gains a client for the Microchip AN1388 serial bootloader on the PIC32, in the new Harp.Toolkit.Firmware.PIC32 namespace. It reads Intel HEX images record by record, and erases, programs and verifies application flash against a CRC computed from the image. A program frame is never resent, since flash cannot be programmed again without an erase. The SoundCard sequence in Harp.Toolkit.Firmware.SoundCard switches the serial port to the PIC32 bootloader through register 82, runs the update at 115200 baud, and clears the register so the coprocessor restarts on its own. The record that holds the application reset address is written last, so an interrupted update leaves the coprocessor in its bootloader rather than running an incomplete image.

The update command keeps its single firmware argument. When the image is for the SoundCard, the coprocessor image must sit next to it under the same name with a .PIC32 suffix after the device name, or the legacy .X, and the update writes the coprocessor first. Without the coprocessor image the update refuses to start, so both processors always run the same release, and a SoundCard can no longer be updated with its ATxmega image alone.

The CI workflow now downloads two SoundCard PIC32 release images, pinned by SHA-256, for tests that program a real image into an emulated bootloader.

An update from fw3.0 to fw2.2 completed on a hardware 2.2 SoundCard, including the CRC check of the coprocessor flash. The device does not report when the coprocessor application is running, so the update waits a fixed two seconds after clearing register 82.

Closes #9

[glopesdev]

Thanks @artursilva0 for trying this out independently.

A build of the v3.0 test firmware was written to a SoundCard with the update command from this pull request, and a sound played successfully afterwards. This confirms that the coprocessor application starts after the update, which is the one step the device cannot report by itself. Together with the fw3.0 to fw2.2 update described above, this covers both directions, so I will go ahead and merge.