When they talk about rerouting power and performing a "big bang" reconfiguration with a 23 hour lag on equipment that was underpowered when the 8088 came out... it kind of melts my brain.
Apparently it still has ten years worth of fuel left!
When they talk about rerouting power and performing a "big bang" reconfiguration with a 23 hour lag on equipment that was underpowered when the 8088 came out... it kind of melts my brain.
Apparently it still has ten years worth of fuel left!
I would guess that even that case is partially accounted for by a watchdog that is hardwired into the system.
Some of the challenges they had to deal with while developing the fix:
- The only source code they had for the flight data software was an OCR'd Microsoft Word document (with typos) that was likely scanned from a hard copy assembler listing printout.
- The processor runs a custom instruction set developed by JPL for the Voyager mission. The documentation they had on the processor was incomplete.
- Everybody who had designed the flight software was dead.
- They had no assembler, no debugger, and no processor simulator. They had no testbed, the only two FDS processors were in space.
There is a Vimeo video of the Voyager team reacting when data first began trickling in from Voyager 1 after the fix in April 2024. "Voyager 1 Team Reacts to Receiving Engineering Data From Spacecraft" (JPLraw channel): https://vimeo.com/939376171
Cummings is the one against the back wall who shoots his two arms up in the air in celebration. He and Armen Arslanian (in the blue shirt to his left, right in the image) developed the software fix.
The slides from Cummings' presentation can be downloaded as a PDF from the Flight Software Workshop Day 2 page, first entry: https://drive.google.com/drive/folders/1BXSBUgEJExsLSE-m585I...
It's just that in most cases, the amount of effort required is orders of magnitude higher than is really justifiable.
Most microcontrollers can update their own flash while running, either with a built-in bootloader or a user-programmed bootloader that takes up a little bit of the flash.
What makes you think that Voyager isn't "rebooted" though?
So you copy a small write routine into RAM, copy a chunk of new data there too, jump to the routine, then it returns to your main bootloader in flash which receives the next chunk from a UART or whatever (because of course it doesn’t fit into RAM all at once), rinse and repeat. You aren’t exactly going to be serving realtime interrupts during this.
(So if you do need minimal downtime, you probably have dual external flash chips, or even just two microcontrollers given execute-from-external-flash would bump you up to fancy micros.)