search

DelfiSpace / DelfiPQcore

0 stars 1 forks source link

SoftwareUpdate: Add failure of FRAM to bootloader #26

Closed CasperBroekhuizen closed 4 years ago

CasperBroekhuizen commented 4 years ago

FRAM needs to be available for bootloader. Add fallback if it's not available (either not on board or stopped working).

related to https://github.com/DelfiSpace/DelfiPQcore/issues/25

CasperBroekhuizen commented 4 years ago

Added a FRAM->ping in https://github.com/DelfiSpace/DelfiPQcore/commit/bb94cfcd0eb6ec10c1dfe3ac5802b40d39ffb66e

StefanoSperetta commented 4 years ago

What happens in case the FRAM is not available?

I see the log message being sent but I do not understand exactly what are the consequences, system-wise.

CasperBroekhuizen commented 4 years ago

No target-slot can be realised from the FRAM. The bootloader 'skips' the jump functionality so a regular boot in SLOT0 will be resumed.

Meaning, if the FRAM breaks, the system will fallback onto Slot0. If the FRAM is permanently broken, the system can also not perform any reprogramming.

StefanoSperetta commented 4 years ago

Great!

If we switch to some kind of error correction system on the FRAM, we can also clean the FRAM and re-initialize it with default data. But in the future...

StefanoSperetta commented 4 years ago

This issue seems more or less solved by now, with the ping() function being called. We might argue the ping() is not a super-secure method but for now, it has to stay like this.

In the future, we can think about adding error correction (we might add an issue but I would put it for software v2)...