

Bricking a Mars probe, before Curiosity (2012) - gw5815
https://gregsramblings.com/2012/08/11/bricking-mars-probe-viking-curiosity/

======
userbinator
_an over-the-air software update was broadcast to the Viking 1 lander to
correct a battery charging issue. The update had an error in it and
accidentally overwrote the wrong bits resulting in a bricked lander._

That problem has been (partially) solved even in devices here on Earth:
there's a small amount of memory which is either much more difficult or
impossible to modify, and that holds "recovery mode" code which is responsible
for the basic operations including updating the main application code. This is
known as the bootloader, boot block, or boot ROM. It's designed to be simple
and thus nearly bug-free as possible.

~~~
planteen
It seems that the architecture of Viking was such the bootloader would have
needed to perform gimbal control of the antenna. That isn't super simple. My
guess is it would have needed to know what time it was, along with a control
loop and astronomical algorithms for a vector to Earth.

I wonder if they had a way to test this software update on the ground before
they sent it.

~~~
andyjohnson0
Martin Marietta built what they called the "Proof Test Capsule", which was a
similar to the pair that flew and was used for ground-based system integration
testing. According to these [2] notes there was a separate analog/digital
computer that simulated the descent from orbit to surface.

Edit: The report referenced in [2] is available for download at [3]. Starting
at page 184 there is a description of the Viking Test Language, which appears
to have been used for scripting tests to be run against the flight
hardware/software. And this was back in 1977.

[1]
[http://www.unmannedspaceflight.com/index.php?s=bf5c742cc7bc7...](http://www.unmannedspaceflight.com/index.php?s=bf5c742cc7bc7c3192119a4a0a3d7f76&showtopic=7324&view=findpost&p=184472)

[2]
[http://www.retrotechnology.com/memship/viking_software.txt](http://www.retrotechnology.com/memship/viking_software.txt)

[3] [http://www.dtic.mil/get-tr-doc/pdf?AD=ADA040770](http://www.dtic.mil/get-
tr-doc/pdf?AD=ADA040770)

~~~
planteen
This is very interesting. And how little things have changed between 1977 and
2015 (from [3]):

"Originally it had been planned to slowly take STE programmers off of the
Viking Project. By the time the STE was moved to KSC for operational test
support, there were to be no programmers left. As matters turned out, the
number of programmers assigned to STE peaked during this period. This was only
partially due to the problems with maintaining the H-632. New requirements for
software functions constantly arose, both in Denver and at KSC. Two new
programs were written at the Cape to assure that Flight loads would be
correct."

------
ironchief
Here is a fix to the link rot in the article. "Galileo’s Rocky Road to
Jupiter"

[1] [http://appel.nasa.gov/2011/05/13/galileos-rocky-road-to-
jupi...](http://appel.nasa.gov/2011/05/13/galileos-rocky-road-to-jupiter/)

------
spapin
Ahah yes when I worked in the space industry and something failed we had a
good time.... wait we didn't. Bosses were angry and the responsibles were
sacked.

~~~
onion2k
Sacking someone for making a mistake[1] is often more about petty revenge than
any desire to improve things. It's a stupid policy. Someone who's made an
error and learned from it is less likely to make it again than someone who
hasn't made the error in the first place. This is the exact reason why
experienced people are better qualified to do jobs than new people. Experience
is valuable.

[1] By that I mean an actual, hard-to-foresee mistake that no one else caught
rather than just incompetence or lack of ability. It's safe to assume that
people without ability don't get in to decision making positions at NASA
though.

