Just a little story that may change the current ideas about permanent
A user was playing with some USB remote controller and did something
pretty simple: he tried to change picture quality setting on his 5D
Mark II. However, not all combinations are valid, and Canon's
validation code is a bit strange: if some setting is incorrect, the
camera displays ERR70... AND saves the incorrect setting into NVRAM.
That means the user will get ERR70 at every boot (even without card or
without any third party software).
What's worse: subsequent attempts of restoring a correct value for
that unlucky setting may fail. In this particular case, the ERR70 was
a failed assertion in the PropMgr task - the one managing the settings
- which explains why the setting couldn't be changed back.
Canon error message was: ASSERT: FALSE at DevelopCombination.c:98 (5D2 2.1.1).
Luckily, ML can disable the assert handler, so we could ignore the
error and get into Canon menus to restore defaults. The 5D2 is alive
Imagine that your config file gets corrupted and you can't just delete
it and start from scratch. I consider this a design flaw in Canon
software. I've noticed this problem in 5D Mark II, 550D, 60D, 600D and
5D Mark III, so probably all their cameras have this problem.
If you are wondering: removing the main battery or the clock battery
will NOT solve the problem. I've tried leaving the camera without
batteries for a long time - the user settings were not reset.
What does this mean?
* With any USB controller app there's a risk of permanent damage. I'd
say that running ML carries the same risk as using some third party
USB controller app. Maybe even less, since ML has safeguards against
this kind of problems.
* A bug in Canon firmware can result in permanent damage. Sure, it is
very unlikely, because Canon engineers do test their code very well
(much better than I can do).
* Having autoboot enabled means that ML is loaded even if the settings
memory is corrupted. This allows us to troubleshoot the problem and
maybe even fix it. Without autoboot (with the FIR only), there would
be no way to run user code once we lose access to Canon menus. So, I'd
say the autoboot method is much safer - this is advice for those who
may request a FIR-only ML version.
The current FAQ says: "Nothing is written into the ROMs." (
Is it really true? Almost. Canon code is not changed by ML, but settings are.
So... is it that dangerous? Can a bug in the code render the camera unusable?
The custom modes (C1, C2, C3) have a very nice property: in those
modes, Canon settings are not saved automatically. The same code that
"bricks" a 5D Mark II in M mode (that is, causes ERR70 at every
startup, even with a fresh card), ran perfectly safely in C modes.
I've got ERR70 when running the known dangerous code, but after
reboot, the camera was 100% clean.
So... bottom line: custom modes are probably the safest way to run ML
and to experiment new things when developing. And, of course, knowing
what's dangerous for the camera is essential while developing.
This page contains technical details about how to recover the camera
from similar failures: http://magiclantern.wikia.com/wiki/Unbricking
What do you think - would a "safe mode" bring some peace of mind? That
is, ML could refuse to run in modes other than C. Maybe the rebel
cameras have hidden C modes too. This needs further research, but it
promises a huge improvement in safety of ML code.
P.S. Someone with better writing skills may help me turn this into a
nice blog post.