search

DelfiSpace / DelfiPQcore

0 stars 1 forks source link

Software update: continue a previously started upload #22

Closed StefanoSperetta closed 4 years ago

StefanoSperetta commented 4 years ago

If the update process in partially completed and the CPU is rebooted, the whole slot must be erased and re-programmed. There should be a way to continue a previously interrupted session.

CasperBroekhuizen commented 4 years ago

https://github.com/DelfiSpace/DelfiPQcore/commit/6c544dbcd6eeb7a53c29cc1541a1e3935361472a

The update 'state' is now loaded in the FRAM. this means the update can be resumed after a reboot. to resume the update, start update as one would normally but include the continue flag (e.g. 18 1 0 1 1)

Todo, automatically try to continue update when a CRC or dataBlock is passed to the update service.

StefanoSperetta commented 4 years ago

what do you mean with "automatically try to continue update when a CRC or dataBlock is passed to the update service"?

CasperBroekhuizen commented 4 years ago

When the device reboots during an update, all the update progress parameters in RAM are lost and when you send a new CRC block after reboot you'll get an Error that no Update is Active. Using the 'Start OTA' command, one can re-obtain the update progress parameters from FRAM to continue update.

A consideration now is, that if someone sends a CRCBlock, but the update is not active, it could check the FRAM automatically to see if it can resume an update. This would make the 'Start OTA' command to resume update unnecessary.

StefanoSperetta commented 4 years ago

I understand the point but I am a little afraid of a spurious packet triggering an update... personally, I would be in favour of not allowing an automatic start.

Once we will have the full ground update application, as soon as we receive an error on a CRC packet, we can detect the situation and eventually recover rather than starting automatic process.

CasperBroekhuizen commented 4 years ago

I see your point. Agreed.