Bootloader Source Code for Grand Central Board Moderators: adafruit_support_bill, adafruit

[Bhindhiya]

Hi All,

I am using the Adafruit Grand Central M4 board for a project.

I want to access the bootloader source code for Grand Central M4 Board.
Is there any way I will be able to access and modify the bootloader code?

Any guidance would be very useful.

Best Regards,
Bhindhiya Raja

[neradoc]

Hi, the UF2 bootloader used by Adafruit is hosted here: https://github.com/adafruit/uf2-samdx1
What specifically do you want to do with it ? Maybe we can help.

[Bhindhiya]

I have implemented support for firmware upgrade over ethernet for my board using Arduino OTA library.
Link for reference: https://github.com/JAndrassy/ArduinoOTA

This library loads the new firmware to a specific STORAGE LOCATION in Flash Memory. Then, it re-writes or copies the same new firmware to the APPLICATION REGION of the flash memory and does a reset.

However, if there is a power failure during this re-write, the operation is interrupted and does not complete. The application region does not have the complete code re-written and the system breaks. When I power ON the board again, it is unable to execute the new firmware and cannot rollback on to the old firmware either.

I want to implement a mechanism that protects the system from this kind of failure. I want to modify the bootloader such that it does the following checks before jumping to APPLICATION REGION directly:

Check if a valid firmware image is available in APPLICATION REGION?
Yes? => Jump to application region and run
No? => Check the STORAGE LOCATION in the flash for a valid new firmware?
- - - - - - Yes? => Copy to APPLICATION REGION and reset

Is there any way to check if the firmware is valid? Any in-built support in the bootloader to check the integrity of the firmware?
Any help, guidance or support to do the above mentioned steps by modifying the bootloader will be very useful.

[User_UMjT7KxnxP8YN8]

I don't have time to look right now, but IIRC the address at which execution starts after a reset (the system reset vector) is in the first page of flash.

Assuming that's correct, you could start your bootloader update by modifying the system reset vector to point to the new version of the bootloader in the "specific STORAGE LOCATION" flash memory, then copy the new version to the usual location starting with the 2nd page so that if the update is interrupted your system will still run the intact new version. When this has been successfully completed, then write the 1st page that includes the usual reset vector address.

There's still a window of vulnerability when you erase the first page to complete the update, but it's much smaller using this approach.