(info for developers)
Solution: start camera with a HDMI monitor.
See http://www.dvxuser.com/V6/showthread.php?274188-I-did-a-bad-thing&p=2527639&viewfull=1#post2527639 .
When you start the camera, you get ERR70 at every startup, even without ML.
Usually, one of the Properties was set to some invalid value and got saved into NVRAM.
Since you have no access to Canon menu, you can't reset the camera to defaults.
Known properties which may cause this (based on what we experienced during development):
Simply reboot the camera without a card and clear the settings.
Go to C mode, change the affected setting back and forth from Canon menu, reboot in CA mode, then reboot in M mode. http://www.reikan.co.uk/photography/blog/?p=1550
Attempt to restore a valid value. This is possible because Magic Lantern still loads and is running behind the ERR70 dialog.
If you know what property you have changed last time, should be easy (you need to know a valid value to restore it).
If you don't know… save a debug log (call “dumpf”, see Debugging Magic Lantern) and look for failed asserts. You'll see something like:
11: 50.637 [[STARTUP]] ERROR ASSERT : PropertySatellite.c, Task = PropMgr 12: 50.737 [[STARTUP]] ERROR ASSERT : Line 624 13: 50.779 [[STARTUP]] ERROR ASSERT : TempMovSoundRecord != PROP_MOV_SOUND_RECORD_ON
So… let's look at the code (with GPL Tools/ARM console):
s TempMovSoundRecord ff85e364: 'TempMovSoundRecord != PROP_MOV_SOUND_RECORD_ON'
PROP_HANDLER:str:PROP_MOVIE_SOUND_RECORD_FOR_CREAT+420: ff85e22c: 028f0e13 addeq r0, pc, #304 ; *'TempMovSoundRecord != PROP_MOV_SOUND_RECORD_ON' 'TempMovSoundRecord != PROP_MOV_SOUND_RECORD_ON'
Let's decompile this:
dec PROP_HANDLER:str:PROP_MOVIE_SOUND_RECORD_FOR_CREAT [...] if arg0 == 67764263/2: DebugMsg(129, 3, msg='PROP_MOVIE_SOUND_RECORD %d %d %d %d ######', *0x2708, *(arg2), *0x270C, *0x2710, *(arg2), ...) if *(arg2) == 0: TH_assert('TempMovSoundRecord != PROP_MOV_SOUND_RECORD_ON', 'PropertySatellite.c', 0x270) [...]
Looks like property 67764263/2 = 0x2050013 should not be zero. Valid values are 1,2,3 (with property spy on a healthy camera, or with guesswork if you don't have one).
Be careful: setting one property may cause other properties to be changed.
If you are really unlucky, trying to restore the right value via prop_request_change will not work (the camera will simply refuse to accept the new value due to failed assertions).
What to do?
In : dec TH_assert if aAJ_TH_assert_struct_0x19C8_0x00_to_0x08.off_0 == 0 /*EQ*/: TH_con_puts('x07Assert: File %s, Expression %s, Line %dn', arg1, arg0, arg2) => ret_TH_con_puts_FF814D00 AJ_msleep_sub1_assert_fail(arg1, arg1, arg0, arg2) => ret_AJ_msleep_sub1_assert_fail_FF814D0C if aAJ_TH_assert_struct_0x19C8_0x00_to_0x08.off_0 != 0 /*NE*/: JUMP(aAJ_TH_assert_struct_0x19C8_0x00_to_0x08.off_0)
If you really have cojones, install your own assertion handler in order to ignore failed asserts. This should give you access to the menu. But… the consequences of doing this might be arbitrarily bad in theory.
Anyway… for PROP_PIC_QUALITY on my 5D2 it just worked (and it also unbricked a camera damaged by a USB remote control app https://vimeo.com/groups/magiclantern/forum/topic:255083). Calling prop_request_change did not work (same call that worked on 550D and 60D for the same problem).
You may call FA_SetDefaultSetting to restore your camera to defaults. Details at http://groups.google.com/group/ml-devel/msg/51b4518bf0a2278f . The command works, but the therapeutic effect is not guaranteed :)
No. The clock battery only stores the clock, not the shooting settings. Poor design, IMO.