@scrax - Looks like I bricked one of my EOSM's. Going through your list I found something that might help determine if it is bricked. Remove card and lens, insert batter and start camera. In my case if the camera is started with a lens it just shows a black screen and flashing LED. Starting without the lens will show an Err 70 message. Interesting that even with just the EF to EF-M adapter attached to the body and no lens, the Err 70 message doesn't show.
[EDIT] Never mind. Camera stopped showing the Err 70 message. Still bricked though.
Bricked :o what did you do what we must not do :P
Stay off the prop regs dfort. Told you :P
Ok prop regs, which/what are the prop regs, where do I need to stay away from, help me here ???
Live and learn? Mistakes are experiences?
This is the first time I bricked a camera. If a1ex opened his repair service I'd be happy to be one of his first clients.
Seriously I'm scared now :o
I've messed my way around with adtg_gui module and making custom crop presets, up till now I thought it was impossible to brick a camera.
What do you think caused the bricking?
Count me in dfort 8)
@Levas
In Movie crop mode code. Moving that to other locations=playing with fire...
I don't get it, do you mean messing around with in which sequence the registers are activated?
So putting the part where A and B timers are etc putting that in the same place as shutter blanking or cmos registers?
As long as you got your lessons learned - which is - keep your initial ROM backups in a safe place - there might be a chance to reflash your camera once "he" returns. I won't even ask dumb questions like "did you try the portable rom dumper" etc.
Well the lesson learned is to be very careful when invoking prop_request_change.
Levas making note now.
"whenever you see in ML code prop_request_change, stay the Fork away from it.
Yeah, pretty much. Also reveals how robust ml is working fooling around with other regs. Regs which I been testing endlessly...
Seems like a good excuse to push this. (https://bitbucket.org/hudson/magic-lantern/pull-requests/825/prevent-canon-settings-from-being-saved/diff) :D
If you remember which prop and you can load ML, you can try to create a minimal autoexec.bin which will try to restore this prop before err is initialized.
It worked on my 500D a few years ago.
If this does not work, you need to contact unbrick.io (http://unbrick.io)
:o
Hi Greg - Danne already tried to help me with that. Didn't work. Uploaded problem builds, ROM's, etc. and send a PM to a1ex.
So Unbrick.io is online?
QuoteWe offer free repair service for cameras bricked by Magic Lantern. Contact us for a quote!
If it is free I wonder how much it will cost me. ;D
In any case, I went through the steps outlined in this sticky post (https://www.magiclantern.fm/forum/index.php?topic=2296.0).
1) Portable display test(https://live.staticflickr.com/65535/47807678871_cb2138c25b.jpg) (https://flic.kr/p/2fQARkn)
That worked. So I skipped down to:
3) ROM dumperThat worked too.
4) Startup logUh oh -- no EOSM.202 build. Glad I can compile (though that's what got me in trouble in the first place) but no luck saving a startup log.
5) Startup log blinkerNo luck either. The LED stays lit when the battery door is closed so it seems to be attempting to load autoexec.bin but there is no blinking.
[EDIT] BTW--This is still a problem (https://www.magiclantern.fm/forum/index.php?topic=2388.msg196964#msg196964) on the dm-spy-experiments branch.
Some progress:
- managed to print Canon's early debug messages on the screen (before their GUI comes up)
Quote from: dfort on May 30, 2019, 11:59:59 PM
This is what a1ex and I were looking at today:
(https://live.staticflickr.com/65535/47967663351_3c626dc3bb.jpg) (https://flic.kr/p/2g5JP9t)
How things have changed!
- could save diagnostic logs after removing most of ML initialization code
- reproduced the error in QEMU (it's something on the MPU side)
- camera stubborn while trying to restore a valid value for PROP_VIDEO_MODE (still looking into it)
- edit: apparently solved by faking the MPU message for PROP_VIDEO_MODE at startup ???
Two eosm cams fixed today, wohoo. Mine and dfort's. Fake or not, they are as alive as ever before. Thank you!
Yay!
Learned a bunch of new tricks while diagnosing this - applicable to all other models that might have similar issues in the future.
In particular, the ability to print things on the screen while booting the main firmware - before starting the GUI subsystem - is going to be very useful for both new ports and for troubleshooting cameras unable to boot.
Sending logging information to the UART and using a FTDI cable (https://www.sparkfun.com/products/9718) to read it also seemed promising but I had trouble removing the last screw so I couldn't take apart the camera. Might come back to this to see if we can look further into the shutter-bug--or maybe a1ex learned some new tricks that will save logs early enough in the boot process to see what is going on?
No, to fix the shutter bug we'd have to understand the MPU firmware (SH2A-FPU processor).
This manual (https://www.magiclantern.fm/forum/index.php?topic=17596.msg212171#msg212171) might be helpful.
Great job !
Good to know I can safely brick my camera ;D
I am more than impressed by these fixes. But I never had a doubt that a1ex would eventually pull this through.