Re: PIC32MZ: How do you encrypt/validate hex file to update firmware?
In my bootloader code which I’ve used on PIC24 and PIC32, I use a modified AES block encryption algorithm, which allows me to send a series of blocks each fitting neatly into a USB HID packet.
I distribute the firmware as an encrypted blob .bin file with an CRC embedded in it in an absolute place at the end of flash memory.
I write and commit the data to flash as it comes in, I do not validate it against a CRC at this stage.
When the device boots, it always goes into the initial booloader anyway before handing over to the applkcation. Before it hands over to the application, it does the CRC flash check. If the flash CRC check fails, it simply doesn’t enter the application and sits in the bootloader waiting to be reflashed.
Here are a few back doors to keep it in the bootloader too, such as unmanaged exceptions, a hardware reset that isn’t a POR, a software reset from the application and a watchdog timeout.
With tens of thousands of devices out in the field, not once have I had one bricked because of a bad firmware upload.