I'm trying to find a way to prevent Canon code from saving their settings at shutdown.

Some settings are saved on the MPU's EEPROM, when opening the card or battery door; also triggered by timeout (about 2 seconds after settings settle).

How I've reached this conclusion?- M mode, changed shutter speed, opened battery cover and took battery out => change saved- used a pin to hold the battery cover switch; changed shutter speed, took battery out => change not saved- used a pin to hold the battery cover switch; changed shutter speed, waited a few seconds, took battery out => change saved- used a pin to hold the battery cover switch; changed shutter speed a few times every 1 second, took battery out => change not saved (initial shutter speed restored)- used a pin to hold the battery cover switch; changed shutter speed a few times every 2 second, took battery out => change saved (some intermediate shutter speed restored)- reinstalled battery door, changed shutter speed, locked up the main CPU (cli(); while(1) without delay, took battery out => change saved- reinstalled battery door, locked up the main CPU (cli(); while(1), changed shutter speed (change visible on top screen), took battery out => change saved

So, we cannot prevent these settings from being saved into persistent. To my understanding, the MPU settings are all those properties starting with 0x8 (e.g. 0x80000005 PROP_SHUTTER, 0x80000039 PROP_VIDEO_MODE, 0x8000002f PROP_PIC_QUALITY). Some of these caused soft-bricking issues previously.

Hmmm So is there a timer? Like if we open batt door and immediately pull batt it won't save? Or is there still a chance there is saving happening with a lightning fast pull? Or is canon saving setting to ROM ever 2 seconds regardless of a batt pull.

Ohhhhhhhhhhhh very interesting! So ML doesn't use the MPU (always saving settings) Hmmm so then the issue is the little switch on the door. Does that have a timer? Or does it save as soon as it is activated?

Ohhhhhhhhhh! I think I get it now. Sorry I had to read through it again. Hmmmm.So there is not much that can be done about certain properties being saved unless you can mod the timer in which the MPU/CPU saves those properties after a change and mod the switch? ... Right? If I still don't understand I am sorry for wasting forum space. This is why I am a user not a programmer.

Would it be safer if ML never touched those properties (e.g. 0x80000005 PROP_SHUTTER, 0x80000039 PROP_VIDEO_MODE, 0x8000002f PROP_PIC_QUALITY)? Or is that not possible with some features?

Also I can confirm:- used a pin to hold the battery cover switch; changed shutter speed, took battery out (quickly) => change not saved- used a pin to hold the battery cover switch; changed shutter speed, waited a few seconds, took battery out => change saved

Just tried this just now. So the save timer and switch are working against you.

lso I can confirm:- used a pin to hold the battery cover switch; changed shutter speed, took battery out (quickly) => change not saved- used a pin to hold the battery cover switch; changed shutter speed, waited a few seconds, took battery out => change saved

Would it be safer if ML never touched those properties (e.g. 0x80000005 PROP_SHUTTER, 0x80000039 PROP_VIDEO_MODE, 0x8000002f PROP_PIC_QUALITY)?

Some of the cases I've unbricked, with bad PROP_PIC_QUALITY values, were cameras that did not have ML before the crash. One of those cases was linked in the FAQ (but looks like the original discussion is no longer available...)

What I'm trying is to prevent accidental bricks. With the current CPU and OS design (without MMU, just with a statically configured MPU), any task is allowed to write to any memory location. A programming mistake that results in overwriting Canon's code or data structures can be unlucky enough to cause persistent changes (worst case, completely bricking the device). It's not very hard to imagine a jump (by mistake) to EraseSectorOfRom...

(BTW, this weakness also allows us to patch Canon code and data structures easily - with proper memory protection in place, it would have probably been a lot harder to interact with the firmware)

(todo: take a closer look at the mem_prot module, which can reconfigure the unused part of the ARM MPU - not to be confused with the TX19A MPU)

Some of the cases I've unbricked, with bad PROP_PIC_QUALITY values, were cameras that did not have ML before the crash. One of those cases was linked in the FAQ (but looks like the original discussion is no longer available...)

"were cameras that did not have ML before the crash" Does this mean the ML card wasn't in the camera at the time of the crash?