[SOLVED] EOS M bricked after changing PROP_VIDEO_MODE

Started by dfort, May 08, 2019, 09:11:28 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

dfort

@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.

Levas

Bricked  :o  what did you do what we must not do  :P

Danne


Levas

Ok prop regs, which/what are the prop regs, where do I need to stay away from, help me here  ???

dfort

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.

Levas

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?

Danne

Count me in dfort  8)

@Levas
In Movie crop mode code. Moving that to other locations=playing with fire...

Levas

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?

nikfreak

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.
[size=8pt]70D.112 & 100D.101[/size]

dfort

Well the lesson learned is to be very careful when invoking prop_request_change.

Levas

Levas making note now.
"whenever you see in ML code prop_request_change, stay the Fork away from it.

Danne

Yeah, pretty much. Also reveals how robust ml is working fooling around with other regs. Regs which I been testing endlessly...

Audionut


Greg

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
:o

dfort

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.

1) Portable display test


That worked. So I skipped down to:

3) ROM dumper

That worked too.

4) Startup log

Uh 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 blinker

No 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 on the dm-spy-experiments branch.

a1ex

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:



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 ???

Danne

Two eosm cams fixed today, wohoo. Mine and dfort's. Fake or not, they are as alive as ever before. Thank you!

a1ex

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.

dfort

Sending logging information to the UART and using a FTDI cable 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?


a1ex

No, to fix the shutter bug we'd have to understand the MPU firmware (SH2A-FPU processor).

This manual might be helpful.

Levas

Great job !

Good to know I can safely brick my camera ;D

Danne

I am more than impressed by these fixes. But I never had a doubt that a1ex would eventually pull this through.