Physical Architecture: S/S Bug-Squashing Firmware Reprogram

[Hello-1122]

Existing diagrams to extend:

• [PFBD] Root Physical Function Breakdown
• [PCBD] Root Physical Component Breakdown
• [PAB] Root Physical Architecture

New diagrams to create:

• [ES] Firmware Reprogram Scenario:
  • scenario in comment below
• (Optional) [PDFB] Functional Dataflow View of Firmware Reprogram
• (Optional) [PAB] Physical Architecture View of Firmware Reprogram

[chgio]

2 possible approaches to implementing this feature were identified, and the advantages and disadvantages of each were discussed.

1. "Hardware" bootloading

the fundamental characteristic of this approach is writing to flash directly from the serial bus:

sequenceDiagram
    participant obc as OBC
    participant target as Target S/S

    activate obc
    obc ->> target      : trigger boot mode
    activate target
    target -->> obc     : boot mode ok
    obc ->> target      : new firmware
    target ->> target   : write from bus into flash
    target -->> obc     : write ok
    
    target ->> target   : reset
    deactivate target
    
    target ->> obc      : heartbeat
    activate target
    deactivate target
    deactivate obc

Loading

2. "Software" bootloading

sequenceDiagram
    participant obc as OBC
    participant target as Target S/S
    participant rom as S/S Non-Volatile Memory

    activate obc
    obc ->> target      : new firmware
    activate target
    target ->> rom      : new firmware
    activate rom
    rom -->> target     : write ok
    deactivate rom
    target -->> obc     : write ok
    deactivate target

    obc ->> target      : trigger boot mode
    activate target
    target ->> rom      : load from storage into flash
    activate rom
    rom -->> target     : new firmware
    deactivate rom
    target ->> target   : reset
    deactivate target

    target ->> obc      : heartbeat
    activate target
    deactivate target
    deactivate obc

Loading

Comparison and Choice

method	pros	cons
hardware	simple: implementation only involves the OBC writing the new firmware to the serial bus	restrictive: imposes on the Target S/S MCU the requirement of featuring serial bootloading from the specific serial bus in use throughout the system (most likely I2C)
software	complex: implementation involves an additional component (a non-volatile memory module, likely external to begin with), plus the Target S/S to relay incoming bus reads as storage writes and to load storage reads to flash writes -- on top of the tasks involved in the hardware approach	permissive: does not impose any specific COTS requirements on the Target, other than the bare minimum of writeable flash

considering the above tradeoffs, we are opting for the software method, valuing permissiveness over simplicity.

This is mainly because, given the extreme limitations of our financial and technical means, it may very well be impossible to find a Target MCU that satisfies these specific serial interface requirements and all those imposed by its S/S.
On the other hand, the introduced complexity seems manageable, and could even come in handy for further robustness features, such as duplicating backup firmware storage on the Target S/S itself.
At any rate, this cost is better paid upfront than later with interest; conversely, switching from this approach to its counterpart should make for easier implementation, and is always an option if the Target MCU supports it.