1. Trammell Hudson
  2. Magic Lantern
  3. Issues
Issue #1893 new

EOS-M shutter bug

Anonymous created an issue

After loading today's build, the shutter button focuses, but doesn't shoot a still.

I did reset the ML settings and rebooted, to no avail. Shutter takes no photos, trying the touchscreen shutter locks up camera completely, live view still on, no buttons or touch functions work at all.

Settings file:

# Magic Lantern v2.3.NEXT.2014Mar06.EOSM202 (c3841c25cd40 (unified) tip)
# Built on 2014-03-05 23:07:26 UTC by jenkins@magiclantern.fm
# Configuration saved on 2014/03/06 21:40:40
beta.warn = 6
menu.first = -8
disp.mode.x = 199

Comments (295)

  1. Janke

    Same with manual focus, refuses to shoot stills. (Checked write protect lock, not locked, besides, it does record videos). Problem persists with Jan. 14th version of ML. With a non-ML card, no problems.

    I just found out that it's the old "shutter bug" that is back; it fixes itself by unmounting lens after power on, then the camera shoots normally.

    Additional info: This happened after experimenting with "Bulb Timer".

    Another worrying symptom: When using a ML-enabled card right after a non-ML card, the camera usually locks up powering up the first time (orange light stays on, not blinking); removing the battery fixes it, subsequent power-ups do work.

    It appears that some ML setting that stays in the camera which prevents shooting due to the old shutter bug. Is there any way of completely removing the ML settings from the camera? For instance, 3x video crop stays on even when changing to a non-ML card...

  2. Morghus

    My camera currently has the old shutter bug as well, only works by turning it off an on again immediately. How far did you get analyzing it? I'd gladly help tracking it down. Also my camera has the problem that it sometimes won't turn on (LED blinks green-orange for a few seconds, then solid orange and requires a battery pull to fix)

  3. One Percent

    There has to be a shutdown bug. When you plug/unplug USB the camera won't turn off properly.. I tried all of the boot methods so eliminated that. I feel the two are related and rather esoteric like the 7D "af hunt" bug that got fixed recently. Nothing in the logs.

  4. Janke

    How can we help?

    It appears to be pretty reproducible, at least on the one camera that I played "Bulb Timer" with - the problems started just then, never got the timer to work...

    My other EOS-M* doesn't (yet?) have the same bug, even though I run the same ML on it.

    Since, as I mentioned, some settings remain even when using non-ML cards (like 3x video crop), there MUST be something that ML has written into the camera settings (RAM?)

    Is there any way of downloading all the settings from ML (for the developers to check), more than the few lines I quoted in the first post?

    *On special offer, got it + kit zoom for just 300... couldn't resist! ;)

  5. Morghus

    I used to have two as well and only one had it, after a while (and doing many ML things) both got it. Unfortunately I have no clue what I did in ML to cause it

  6. Alex

    I doubt it's something from ML itself; my hypothesis is that it's from the boot process. Whatever you do in ML only affects the probability of reproducing, but has nothing to do with the cause (at least that's my theory).

  7. Janke

    Can you reproduce the bug with this minimal autoexec?

    The bug is still there with that.

    New clue after some experimentation: I do get the shutter bug in BOTH bodies with the 18-55 STM zoom mounted, but not with the 22mm f/2 STM. That should help a bit...

  8. Morghus

    I actually have all EOS-M lenses, it does happen with the EF-M 11-22 STM too, never on the 22 STM and not when I use an adapter to use other EF(-S) lenses.

  9. Alex

    I smell something similar to this: https://bitbucket.org/hudson/magic-lantern/commits/bab7ba5266b5215c84d191fafae7bd6f6adb9356

    but here I can't suggest anything to try. Since the bug is present with the minimal binary, my approach would be to compare the boot process with and without autoexec (of course, assumming the autoexec only contains that jump and nothing more).

    The bootloader code starts at FFFF0000 and after doing its stuff, it should jump to FF0C0000 where it passes control to main firmware. I believe the answer to our riddle is somewhere before this jump.

  10. Morghus

    I can not confirm Janke's behavior that the bug even occurs with the minimal autoexec.bin, for me it works with it on the first try. What exactly happens in the fix for the 7D?

  11. Morghus

    BTW. you do know that shutting the camera off an on again immediately (before it was able to shut down completely => orange LED blinking once after a 2 second delay) it works, so maybe something in reboot.c fixes it?

  12. Alex

    The description of the bug is linked there (autofocus fails when mixing new/old lenses in a certain order).

    reboot.c is used only at startup, not at shutdown. For shutdown, there is a hook in tasks.c (PROP_TERMINATE_SHUT_REQ); you may try commenting that one to see if it helps.

    There is also some fake shutdown event (e.g. turning off the camera and turning it back quickly does not finish the shutdown sequence, but causes nasty stuff with LiveView powersave - if you shutdown the camera while display off is powered). In normal usage (LV not powersaved), this event only saves the config file earlier, just in case, so it shouldn't be the cause.

    On bugs like this, that can't be explained, I usually narrow down by commenting out ML tasks in reboot.c (for example, start with "magic off" and make sure the problem is not present, then start enabling stuff from there).

  13. Morghus

    Okay, good news is I don't have the shutter bug anymore, bad news is, I'm running unchanged ML right now.

    What I did was boot with

    static unsigned short int magic_off = 1; // Set to 1 to disable ML
    static unsigned short int magic_off_request = 1;
    

    where ML was off and I experienced no shutter bug, then I tried to verify what just happened and boot again with both values set back to 0 (no difference in code from when the bug occured) and there's no shutter bug anymore...

    I tried getting it again by trying a lot of settings, modules, switching to TL and doing the same there, and the result is that I don't have the bug anymore. Disabling ML by holding SET during boot doesn't work on the M for some reason, I guess again because of the combined Q/SET button. If it comes back I'll have to start investigating again.

  14. Morghus

    Made a pull request for magic_off on the Info button, it's easier to press while pressing the on button than the menu button I think.

    EDIT: can not reproduce anymore... argh

    EDIT2: formatting the card, putting it ML on it with EOSM_202.fir again fixed the shutter bug again. deleting the settings or the rom dumps before didn't help. nothing that I changed in the boot process seemed to fix it, I didn't try too many things though because most of the things I did made ML not boot anymore

  15. Morghus

    Quick update: low level formatting the SD card with restoring ML also seems to temporarily fix the problem. Still not sure when the bug appears again, it seems like just leaving it for a while can do it too... I don't know. I'll continue to observe it

  16. Janke

    OK, good to know. In fact, I have nothing at all against the 3x zoom setting staying in the camera, since it can be removed in Canon's menu.

    3 x is the main reason for me to run ML - I can use all my 16 mm C-mount lenses at approximately their correct image size! You could hardly find another 13 x / f1.4 zoom to fit the EOS-M... ;)

    But the shutter bug is of course annoying...

  17. Peter Bayer

    Hi guys, I just installed ML, then did the low level formatting with my SD and moved the ML files on the SD again. However, it doesn't work. Is there anyhting I did wrong?

  18. Peter Bayer

    Okay, it works again. This may help you a bit fixing the prob: I took the first time a 45 MB/s 16 GB SD card, installed ML 20Aug14 on it, started the camera and (just because I thought the bug stills exist) reconnected the objective (18-55mm). However, no bug! - I already connected the SD card to my pc (via reader) and charged the battery - the shutter still works!

  19. Salim Vanak

    Hi guys,

    I have an EOS-M 18-55mm lens, 2.0.2 firmware.

    I installed my EOS-M with Magic lantern yesterday and have found I am having the same "shutter bug". For me it is happening quite consistently.

    The camera has been off for a while. I press the power on button, the camera powers on. Auto focus works, but the shutter does not fire.

    I turn it off, the power/access led comes on as I press the power button. and the LED goes off. A few seconds later the power/access LED flashes (final flash). If I now turn it back on again I get the focusing beep, the camera will not fire the shutter. I can repeat this...

    However, If I turn the camera off, and manage to switch it back on again before the "final flash" the camera will fire the shutter.

    The shutter only fires if I can switch the camera on again before the "final flash".

    I have reset the Cannon Firmware settings and the ML settings from the menus and the same behaviour continues. If I hold Info while switching the camera on, the the ML menus do not appear with a two finger press but the shutter will not fire. If I hold down info and switch on the camera before the "final flash" then the shutter fires, but the ML menus do not appear.

    I have messed around with this quite a bit. My final thoughts are that somehow there is problem with the sd card, as only a different SD card and a low level format has fixed the problem.

    Is it possible that this problem is caused by ML not being able to complete its final write? So if I power it on before the final flash it somehow corrupts the SD card?

    Salim.

  20. Peter Bayer

    Hi Salim, for me, another SD card helped, maybe because of the formatting. Try to format the card with Windows in FAT32, move ML and the standard Canon folders on it - no guarantee, but that's my only idea atm.

    BTW: Others told me as well that formatting helps.

  21. Flame Ecks

    I have this same issue on my EOS M with 18-55mm lens.

    I switched and formatted the SD card but it didn't work. Is there a way to completely remove Magic Lantern within the camera? I even tried to reinstall the official Canon firmware and I still get the same results. At least the video recording works...

  22. Rohan Hill

    Exact same problem here - got a new EOS M and installed the 27-Sept-2014 nightly. Shutter won't fire. The only way I found to fix this is to switch it off then on again quickly. Reformatting the SD card from Windows as FAT32, as suggested above, didn't help either unfortunately.

  23. Fam Wired

    Hi, I've tested about 10 different Magic Lantern's since this summer. I must confirm the shutter bug is 100% regardless of SD card etc. However, If I change to another lens it's working great. To bad nobody could find and fix this major bug. I think it makes the software unusable for most people. Especially if you only got the 18-55 lens.

  24. Janke

    "Release without lens" doesn't help, I keep that option all the time, since I also have old, manual lenses (one of my very best is an East German Meyer Orestegor 135mm/2.8, fantastic sharpness and bokeh!)

  25. Salim Vanak

    I have found once the camera is switched on removing and re-fitting the 18-55mm lens fixes the problem. In fact even very slightly loosening the lens on its mount and re-tightening works.

  26. Peter Scargill

    I have to say I am disappointed. I just sold a Samsung Android Camera and bought the EOS-M partly because of recommendation of this software - and exactly as above - it simply doesn't work with the standard lense - you have to turn it of and on quickly to get it to allow you to take photos - surely this can be fixed?

  27. Jan Zapletal

    Could a developer comment on this issue please? It would be nice to know if there is someone interested in fixing this issue or if it is going to stay like this. Thanks!

  28. Alex

    None of the developers are able to reproduce the bug on their EOS-M, to my knowledge. Also, the bug happens with a minimal autoexec.bin that does nothing but jumps to Canon firmware.

    So, unless somebody (a) can reproduce the bug consistently on their EOS-M and (b) understands the cause of this bug, we are stuck.

  29. Peter Scargill

    I don't understand it because I don't know the code - but I can absolutely, 100% repeat it. I bought a brand new Canon EOS-M - nothing special about it at all - the standard lens that comes with it. I installed the software - and from that point on - I turn it on - and it will not take pictures. I turn it on - off and back on again in quick succession - which is a pain - and it works - 100% every time. If there is anything you'd like me to do, any tests , quite happy to do this.

  30. Morghus

    Formatting the SD-Card and putting ML on it again seems to fix the problem for a while. Just deleting the ML folder is not enough. I can not consistently reproduce getting the error again after that. It seems completely random but it does come back after a day or two.

  31. Janke

    I have also had the shutter bug problem. Simplest fix is to just unlock the lens and turn it 1/4" and then back. No need to remove it completely, or even power the camera on-off.

    Since the only feature I really absolutely need of ML is the 3x zoomed video (I have a bunch of C-mount lenses, including a huge Canon 13x 7.5-97.5 mm zoom), I'm fortunate that, for some reason, it stays in the camera even when I remove the ML card! The setting disappears only if I manually change the video size or fps setting manually.

  32. Alex

    If it's so easy, you are welcome to submit a patch.

    We spent many weeks trying to diagnose it (just read the threads linked above), and I still don't know what's causing it.

  33. Peter Scargill

    A1ex - that sarcasm was totally uncalled for. I was merely trying to encourage the developers presumably including yourself - who've clearly done a great job but the end result for EOS-M users is very bad - every time you turn the camera on - you have to remember that little operation - in my case it would not be the first time that I get so fixated on what I'm taking I forget to do the off-on thing and of course lose the moment. Indeed I bought the camera because a friend told about the combination of this software and the camera being so great so clearly I'm as frustrated as anyone else that in all this time no-one has been able to crack it.

    Without understanding the software (I do understand software, just not this software) is there anything I can do - any series of tests with the camera that would help?

  34. Alex

    You are the one who grossly underestimated the effort required to fix this.

    To help, you can answer my questions from this thread (scroll up). More answers don't hurt.

  35. Daniel Fort

    Maybe someone who can reliably reproduce the shutter bug can try turning off image stabilization and see if that "fixes" it. Here's instructions on how to turn it off via the menu when using EFM lenses:

    http://support-au.canon.com.au/contents/AU/EN/8201602800.html

    Does the shutter bug also affect Canon EF IS lenses when mounted via the adapter?

    By the way, I've got 18-55mm and 11-22mm EFM lenses and have not been able to reliably reproduce this bug. I'm also not a developer so I'm not sure if my suggestion would bring the developers any closer to figuring this out.

  36. Peter Scargill

    I have the standard 18-55mm lens and just followed this through , turning off image stabilisation. Still no abililty to shoot photos. I then turned the camera off, waited, then on – still no photos – ensured that stabilisation was indeed off. In other words it made no difference whatsoever. Turned it back on…. No difference. The only way I can take pictures is to rapidly turn the EOS-M off then on.. From that point on as always, it takes pictures until of course you turn if off and leave it off for more than a second at which point we’re back to square one.

    Pete/

  37. Janke

    I performed some new tests:

    I renamed my ML card to EOS_Develop - shutter is still buggedly locked, will operate only after lens twist trick.

    This happened with the 18-55, and also the new 55-200 mm lens.

    It ALSO happens with the 11-22 if it is in the shooting position when you power on the camera, but NOT if you power on with the lens collapsed.

    However, then the message "Set lens to shooting position" does NOT appear! This always appears with a collapsed 11-22 lens with a non-ML card.

    The 22 pancake lens does not cause the shutter bug, only the 3 other lenses.

    Yes, I've got all four lenses, being an EOS-M fan (or freak?)

    Hope the above helps diagnosing...

  38. Janke

    Addendum to my last, see http://www.magiclantern.fm/forum/index.php?topic=9741.new

    Basically, doing a low-level format of the card in the camera fixed the issue - at least temporarily, but time will tell...

    Very strange, though: Letting the camera do a low-level format did NOT remove the autoexec or the ML files, but did indeed zero the DCIM and MISC folder, and removed a folder named "old FIR". The card was also renamed to EOS_DIGITAL by the camera.

    So, this looks promising. Anyone else care to try? Will your autoexec and ML folder be left intact after the low-level format?

    EDIT: Ha! It's supposed to leave the ML on the card... my bad!

    BUT: Loading the latest nightly build, the bug is back! New low-level format, shutter bug gone !

    So, everytime you load a new nightly, do a low level format (and lose the photos on the card...) ?

  39. Daniel Fort

    Ok--I guess I do have the shutter bug. I normally use manual lenses and shoot in movie mode so I didn't notice it until I decided to take stills with the 18-55mm and 11-22mm EF-M lenses. (Don't have all the lenses like Janke) Just out of curiosity, has anyone tested this with the Tamron 18-200mm EF-M lens?

    So I tried the format card trick on an older build and it worked after a format and restart but once the camera was shut down and restarted the shutter wouldn't fire. I just tried it with the 2015-01-28 build and going through those same steps crashes the camera. Here's the log:

    ASSERT: !IS_ERROR( TryPostEvent( this->hTaskClass, this, EV_VD_INTERRUPT_EVF, NULL, 0 ) ) at ./Evf/EvfState.c:504, task ? lv:1 mode:3

    Magic Lantern version : Nightly.2015Jan29.EOSM202 Mercurial changeset : 703ee626326d (unified) tip Built on 2015-01-28 23:08:36 UTC by jenkins@magiclantern.fm. Free Memory : 185K + 3444K

  40. Daniel Fort

    Don't know if this helps out but here are some tests that a1ex ask for in the forum discussion. http://www.magiclantern.fm/forum/index.php?topic=8347 (That discussion seems to be dead.)

    Camera bootflag not set, card bootflag not set, boot from a formatted card => OK (running Canon firmware)

    Camera bootflag not set, card bootflag not set, run minimal FIR => Doesn’t Fire

    Camera bootflag set, card bootflag not set, boot from a formatted card => OK

    Camera bootflag set, card bootflag not set, run minimal FIR => Doesn’t Fire

    Camera bootflag set, card bootflag set, card without autoexec.bin present => lockup? Yes—camera won’t start up.

    Camera bootflag set, card bootflag set, run minimal autoexec => bug present (confirmed by previous posts, but only for some users) Confirmed in my tests.

    Camera bootflag set, card bootflag set, run minimal autoexec followed by minimal FIR => bug present, right? (just double-checking) Yep—Doesn’t Fire

  41. David Milligan

    I'm really surprised the whole 'EOS_DEVELOP' thing didn't work out, I was looking through the strings in my 60D firmware dump I noticed "EOS_DEVELOP" towards the very end with some other strings that seem to be related to the bootloader (like 'autoexec.bin') and what looks like some sort of Canon debugger menu. Maybe it's EOS_DEVELOP in addition to other properties of the SD card or it's formatting that's making it work. I think it's worth further investigation. Too bad the person who found that hasn't been heard from since.

  42. Alex

    Actually, EOS_DEVELOP is one of the strings written when making the card bootable. Maybe the EOS-M also expects it in some other location?

    Definitely worth further investigation.

    On 7D, there was a similar bug in the bootloader. If, during the boot process, the slave CPU had some delay (dummy for with asm("nop") inside) before jumping to main firmware, but after poking the master CPU, it had a somewhat similar issue with certain lenses (AF not working properly).

    If this issue is similar, maybe slow cards could be causing trouble? Or maybe cards of a given capacity or filesystem?

  43. Daniel Fort

    I've experienced the shutter bug with a new SanDisk 32GB Extreme Pro UHS-I SDHC U3 (Class 10) 95 MB/s Memory Card. However, just to test the slow card theory I pulled out a prehistoric 1GB Kodak SD card (no indication of speed or class) loaded ML on it, made it bootable and tried it out--no shutter bug.

    By the way, I currently don't have the shutter bug on any of my cards or cameras (I've got three EOS-M bodies and the 18-55mm and 11-22mm lenses). These are the steps I took:

    1. Turn off the camera boot flag by running firmware update with a ML loaded card and wait about 30 seconds--ML displays a countdown on the bottom of the screen.

    2. Format the card in the camera which makes the card non-bootable. Note that I alway use the "Low level format" option.

    3. Then I copy the ML files on the card and do a standard ML install by doing a firmware update on the camera--this sets the camera boot flag and makes the card bootable.

    All of this stuff is pretty basic but I was thinking about Janke's comment about formatting the card. It worked for me until I restarted the camera then the shutterbug was back. With the extra steps that I took it looks like the shutter bug is gone--at least it has been gone for a few days of casual use. I'll report back if it hits me again.

  44. Peter Bayer

    Hi guys, like I mentioned before, I had success with formatting the SD card (steps above). For six months now my EOS M works fine with ML, however, updating the ML may change the current situation.

  45. Daniel Fort

    John - which steps did you follow, Peter's or mine? Note that Peter is formatting his card with a FAT32 file system on a Windows computer while I'm formatting in camera which creates a exFAT file system. Peter didn't mention how he made his card bootable but I'm doing it all with the ML firmware update method.

    I went from having 3 cameras and 6 cards that exhibited the shutter bug to everything working fine after formatting all of my cards with a camera that had the boot flag turned off and installing the latest nightly build. The key seems to be to start with a newly formatted card--or maybe Peter and I just got lucky for a while.

  46. Kristian Wannebo

    Hi, I'm new here. I just got myself an EOS-M(1) and loaded Magiclantern. I've read most of this thread and some thoughts on the shutterbug occured to me, just guesses though.

    Many report that removing and remounting the standard zoom lens removes the shutter bug. The only lens mentioned without shutterbug is the 22mm (non-zoom).

    I suppose the autofocus algorithm needs to know not only what lens is mounted but also the set focal length in order to work efficiently? ( Remounting a zoom would break and restart this communication.)

    If so, could there be some interference between this continuous (while zooming) focal length information from the lens and the ML software? I've noticed that the ML screen updates exposure info slower than the Canon screen. Could the processor be running close to its capacity in certain situations? If the lens sends its info as an interrupt signal, could there be a que with other interrupts that might lead to a stack overflow? Just speculations of course, as I don't know the software.

    Now: For my EOS-M I have the 22mm and an old 28-105mm zoom on the adapter. I haven't yet had the shutterbug, but if there is anything in my speculations I should be able to provoke it with the zoom. Unless this old zoom talks to the camera slightly differently, e.g. slower - it was made for older and slower cameras.

    Please, if there is any sense in this, give me info on how to most reliably provoke the shutterbug.

  47. Daniel Fort

    Hi Kristian - you probably won't be able to provoke the shutterbug with your equipment. So far only EF-M zoom lenses with image stabilization are affected. These include the 18-55mm Canon EF-M kit lens, 11-22mm Canon EF-M, 55-200mm Canon EF-M and the new 18-200mm Tamron EF-M. EF and EF-S lenses attached via the EF to EF-M adapter seem to work fine.

  48. Andreas Do

    Hi, I also have to deal with this shutter bug. What I found out: I have two EOS M and two SDHC-Cards (1x SanDisk 32GB ExtremePro class10 /3, 1x Transcend 16GB class10). Lens is a EF-M 18-55mm. The Sandisk does not generate the shutter bug, the Transcend does. Even if I copy all the files from the Sandisk to the Transcend, the Transcend has still the shutter bug. The config file or any other configuration is of no matter! There is a problem around the boot-flag that is set once the firmware is updated and ML is installed for boot next power-up of the camera. If I install ML but wait until ML deletes the boot flag than the shutter bug is gone! I thought the tiny program EOSCard of Pel could fix something, but it doesn't help. I formatted the Transcend on the pc in a cardreader and then again in camera, nothing helps. Only removing the bootflag. There must be some magic bits on the sd-card, which differ or make the difference between my two SD-Cards. Any ideas?

    What is in detail done by installing ML on the camera, which flags are set on the sd-card and so on... ?

  49. Daniel Fort

    Andreas, have you removed the boot flag from the camera, reformatted the card in camera then put ML back on the card without reformatting in the computer? These are the steps that worked for me. I'm still shutter-bug free but I always follow these steps when updating ML on my cards.

  50. Andreas Do

    Probably a matter of speed of the sd-cards? The Transcend card that causes problems has only 21.0 MByte/s write speed, the good SanDisk 80.1MByte/s ! Tested with h2testw.

  51. Daniel Fort

    I was going to suggest testing the card's read/write speed though I tried some very old and slow cards and they worked after following the steps I suggested. By the way, do you know that you can test the card's speed in camera with ML? You probably won't get more than 40MB/s in camera.

  52. Andreas Do

    ok, I think its not the speed of the sd-card: I tested a very old one: SD from ExtremeMemory 512MB, FAT(16) 16KB-cluster, write speed 9,86 MByte/s, read 11,3 MByte/s, no shutter-bug! low-level formatted in camera, ML files put on at the pc, firmware update and ok. What should be mentioned: After firmware update the battery has to be pulled, otherwise the cam doesn't really boot new.

  53. Daniel Fort

    Interesting--maybe it is the way the card is formatted? I'm reaching for straws here but in-camera formatting should result in an exFAT file system. Check and see if your Transcend 16GB class10 that triggers the shutter-bug is formatted in FAT16, FAT32 or exFAT (a.k.a FAT64) then try a different formatting.

    I'm not a programer or computer expert but somehow I managed to eradicate the shutter-bug on all my cards. Knock on wood.

    By the way, removing the bootflag disables ML so the shutter-bug will be gone but so will ML.

  54. Aart Olsen

    Dunno if it will help, but it recently came to light in the Canon EOS M Talk Forum on Digital Photography Review that IS is on ALL THE TIME in the three EF-M lenses that have IS (the discussion is about the new M3 but the IS behavior of the M is also described). This may be a feature to help touch-focus on the EOS Ms (because it's harder to locate the subject you want to focus on if it is dancing all over the LCD screen). Non-native EF lenses working through an EF-EFM adapter don't do this (on the M); they start IS when the shutter is half-pressed. It's interesting that only the lenses with which the shutter bug happens have this IS behavior.

    Another data point: on my EF-M 11-22mm (the only IS lens I have), when I unmount the lens with a small derotation and then click it back, as is done to fix the shutter bug, its IS turns off. The IS doesn't start up again until I press the shutter button. It's interesting that the same thing that fixes the shutter bug also turns off the otherwise always-on IS.

  55. Andreas Do

    more testing: a brand new SanDisk SDHC Extreme 32GB UHS-I class10, write 51.7MByte/s,

    • tested out-of-the-box with h2testw for any errors, result: ok

    • test data erased by explorer, DCIM etc. and ML-files copied onto the new card, no formatting, it came FAT32 .

    • tested in camera with in-camera-bootflag set: no error, no shutter-bug, but of course no ML active, since the card wasn't flaged.

    • back in the card reader, EOScard.exe started: both boxes ticked, EOS-DEVELOP and BOOTDISK, and SAVE.

    • back in camera: start ok, ML starts, no shutter-bug! no problems

    Note: the brand new sd-card was not formatted with the pc nor with the camera. And it works! I think, some sd-cards behave not ML-like and the shutter bug occurs. It might be a matter with the header data on the sd-card.

  56. Alberto Batistini

    I have 2 cameras Canon EOS M and 3 EF-M lenses: 11-22 f/4-5.6, 22 f/2 and 18-55 f/3.5-5.6. I tested four memories: old Nokia 1GB MiniSD with SD adapter, Sandisk SD EXTREME III 2GB, Sandisk SDHC Ultra 32 GB and Transcend 32 GB SDHC I U1 600X . All memories have been tested and fully functional with the original Canon firmware 2.0.2. Installing Magic Lantern 2015-04-19 version my cameras shoots only my Sandisk memories. With my others SD cards my cameras dont shoots "dont shoots" == doesn't take pictures (because of the shutter bug). I have no error message. I think that there is some incompatibility with the data written in the protected area of some cards.

  57. Alex

    I might have a hypothesis, but I need some test data from multiple users (both from those who are experiencing the bug, and those who do not).

    So, can you upload a copy of the MBR from your card? (first 512 bytes)

    From Windows, you can do this with a hex editor, e.g. HxD.

    From Linux/Mac: sudo dd if=/dev/your-sd-card of=mbr.bin count=1

  58. josepvm

    Transcend 32 GB 90MB/S 600x.

    https://dl.dropboxusercontent.com/u/44995840/mbr.bin

    Formatted by camera with 4,2 MB of unallocated space, followed by a 32 GB FAT32 partition.

    I have the shutter bug:

    • Always with the EF-M 11-22mm IS STM lens, if I start the camera with the lens extended. Never if I start the camera with the lens in collapsed position.
    • Almost always with the EF-M 18-55 IS STM lens. Sometimes (after changing lenses, I think) the bug disappears for a while. But it comes back after several on/off cycles.
    • Never with EF-M 22mm STM lens, or EF and EF-S lenses attacched with the lens adapter.
  59. josepvm

    I realize that my MBR file is almost completely void, compared with Licaon Kter's one.

    To compare, here is the MBR of an identical Transcend 32GB SD card purchased in the same batch from Amazon one year ago, and formatted the same way, that I use in my EOS 500D with Magic Lantern. It is also almost completely void:

    https://dl.dropboxusercontent.com/u/44995840/500D_mbr.bin

    In fact, the card I use now in my new EOS M, was previously used also in the 500D. I erased it in my computer and reformatted it in camera, before installing on it ML for EOS M.

  60. josepvm

    I have tested now with a third identical Transcend 32 GB card that I use also with ML on the 500D

    1 - MBR with factory default partitioning (4.2MB unallocated space followed by FAT32 partition) and formatted in camera (500D). As a result, MBR almost void, as previous ones. : https://dl.dropboxusercontent.com/u/44995840/500D2mbr.bin

    2- Deleted partition, and created a new FAT32 partition with computer (Ubuntu), taking the whole card space. There is some data on MBR: https://dl.dropboxusercontent.com/u/44995840/500D3mbr.bin

    2- Taken the repartitioned card and formatted in camera (EOS M). The MBR is almost void again. And there is again an unallocated space of 4.2MB at the beginning of the SD card: https://dl.dropboxusercontent.com/u/44995840/500D4mbr.bin

    I will install now ML for EOS M in this card and test if shutter bug is present ...

  61. Licaon Kter

    WINE?

    Anyway, skip the formatting in camera ( PC->format->ML->install ML-> test? )

    The whole "4.2MB unallocated space followed by FAT32 partition" sounds strange.

  62. Alex

    josepvm: the interesting part is the data after 0x1BE - these are 4 partition descriptors. From those, Canon bootloader code only looks at the partition ID (offsets 0x1C2/1D2/1E2/1F2) and partition start (1C6-1C9, 1D6-1D9 ... 1F6-1F9).

    On my test card (256MB, FAT16, formatted on 60D and 5D3), this data is empty (zeros). In this case, Canon bootloader relies on uninitialized data, and if lucky (e.g. 60D, 600D), it boots under QEMU. If unlucky (650D, 6D, M), it attempts to read past the end of the card, and it also appears to corrupt some memory. I'm not sure if QEMU behavior matches perfectly the real-world results, need to do more tests. But I'm almost certain about one thing: Canon routine that checks for boot flags (the one that looks for EOS_DEVELOP and DISKBOOT) may rely on uninitialized variables (it uses whatever it finds on stack from previous routines).

    In all your boot sectors, partition ID is 0C (FAT32), at offset 0x1C2.

    Licaon Kter: your boot sector appears to be from the first partition (not the MBR). What device did you use when copying?

    Here I have /dev/mmcblk0 and /dev/mmcblk0p1. The first one is the entire SD card (which contains the MBR) and the second one is the first partition. I need the first sector from the entire card (not the one with EOS_DEVELOP and BOOTDISK strings).

  63. josepvm

    A new test, with the third Transcend 32 GB card.

    • Partition removed in Linux with GNOME Disks, and created a new FAT32 partition, labeled EOS_DIGITAL
    • Copied ML nightly files for EOS M, without formatting card in camera.
    • Card inserted on EOS M, and launched firmware update to install ML.

    This way GNOME Disks stills shows a single partition using the whole available space on card, without any unallocated space. The MBR file is now:

    https://dl.dropboxusercontent.com/u/44995840/500D5mbr.bin

    But the shutter bug is still present using this card, no difference in behavior respect to card formatted in camera.

  64. josepvm

    Data from another card, Lexar 8GB sdhc 100x class 6

    https://dl.dropboxusercontent.com/u/44995840/8gbmbr.bin

    This one does not show the shutter bug.

    I have prepared it the same way than my previous post, no formatting in camera, created new partition with GNOME Disks. But this time I have labeled the partition "EOS_DEVELOP".

    Some days ago I tried to rename my Transcent card to EOS_DEVELOP, but I found that it did not have any effect in preventing the shutter bug ... so I thought the name did not matter... I will try again on the Transcend card, labelling it "EOS_DEVELOP" during partitioning.

  65. Alex

    josepvm: can you copy the 8GB card image (that does not show the shutter bug) on the 32GB card?

    (to my knowledge, there will be some unused space after those 8GB, but the card should work just fine)

  66. Alex

    Yes. For example:

    # put the 8GB card
    dd if=/dev/your-sd-card of=image
    # put the 32GB card
    dd if=image of=/dev/your-sd-card
    

    Make sure you copy the entire card (not just one partition), and double-check the SD device name (so you don't erase your hard drive by mistake).

  67. Alex

    Another test:

    • old minimal autoexec - it simply jumps to Canon firmware; you should be able to reproduce the bug with this one.
    • minimal autoexec v2 - this jumps to Canon firmware with a different method; do you get the shutter bug with it?

    Sources:

    old one, reported to show the shutter bug:

        B 0xFF0C0000         ; jump to main firmware
    

    new one, tested in QEMU:

        LDR R0, =0xe3a00001  ; MOV R0, #1
        LDR R1, =0x401018E8  ; Let the bootloader jump to main firmware,
        STR R0, [R1]         ; by patching a return value.
        BX LR                ; After patching, return from autoexec.bin.
    
  68. Alex

    No, maybe it's worth trying.

    Tip: to get a card image that compresses well, zero out the card first (this is destructive, be careful not to zero out the hard drive).

  69. josepvm

    tested both minimal autoexec.bin (old one and version 2) with Transcend 32 GB card.

    With both files, camera does not start. Green LED blinks fastly forever, until I stop it pushing again the on/off button. This happens with the EF-M 18-55 but also with the EF-M 22mm (the shutter bug never happens with this lens)

  70. Licaon Kter

    Tested both autoexec.bins too:

    • old minimal autoexec - works fine
    • minimal autoexec v2 - led blinks green, never starts, stops on off button press

    /LE:

    Apparently after using "minimal autoexec v2" replacing back the autoexec.bin does not let the camera start, now it's just stuck on "led blinks green, never starts, stops on off button press"-mode.

    Also replacing the whole ML version does not help either.

    /LE2:

    Just finished the backup (file copy), deleted all settings, BINs in log/, a M2100.CTG file in MISC/, renamed autoexec.bin to AUTOEXEC.BIN, also EOSM_202.fir to EOSM_202.FIR just in case and now ML loads fine.

    Off to make a full card image for josepvm.

  71. josepvm

    I tested first place the minimal autoexec.bin v.2, and after that I changed it to old version, so probably, as Licaon Kter points out, the camera was still locked and my test for old version was not valid.

    I remember that, after switching to another card with ML (the 8GB card with no shutter bug), the camera did not start at first attempt, green LED blinks. After power off and removing battery, camera worked again.

    I will repeat test with minimal autoexec old version, probably it works.

  72. Licaon Kter

    josepvm: Here's my 32gb (known non-bugged) cards' image: https://mega.co.nz/#!pcxRgYqK!d_58HD2uhbcPuLJOEo302wPqRIG6x5Q0aRgvjrbjgXc

    You write it to your card, say /dev/sdX (eg. if using an USB card reader) or /dev/mmcblk0 (eg. if using an integrated card reader, like on a laptop) with:

    7za x EOS-M_ML_working_32gb.7z -so | dd of=/dev/sdX bs=4096
    

    Start cv as: cv -M to watch it progress

    Or use pv like this:

    7za x EOS-M_ML_working_32gb.7z -so| pv -s 31166976k | dd of=/dev/sdx bs=4096
    
  73. josepvm

    Image successfully copied to my SD card, partition and ML files look Ok, and the card works well in camera ... but the bad news are that shutter bug is still present.

  74. Licaon Kter

    Hmm, thinking of something else, maybe it's the lens at fault, looking in the Canon menu at firmware, mine says:

    • camera firmware 2.0.2
    • lens firmware 2.0.0

    Yours?

  75. josepvm

    And remember that with a Lexar 8 GB class 6 card the shutter bug does not appear in my camera with the same EF-M 18-55mm or with my EF-M 11-22mm

  76. Licaon Kter

    Then it's card based (and the good old advice of buying only trusted brands still stands), unfortunately the flash cards storage area is a messy one, I read a bit when choosing my first one that I needed for the RaspberryPi and it got messy: chips, firmware, controllers, fakes, attack vectors, brrrr. Hopefully Alex can compare a good and a bad card and yield some helpful info.

  77. josepvm

    Tested another card, same type as my various previously tested Transcend's (32 GB SDHC Class 10 UHS-I U1) but now from a different brand: "PNY Performance", 30MB/s. It also has the shutter bug.

    I suspect the problem must be related to some hidden, read-only (not affected even when copying the whole SD card image), vendor specific ID info on the SD card, perhaps licensed content, that Canon firmare sees as Ok on Sandisk products, and not Ok on other brands?

    I will try to buy a similar Sandisk card to confirm it.

  78. Jimmie Tauriainen

    Would it be possible to compile a autoexec with a 'safe' 10-20 second sleep in before going further? I'd bet more on that timing than any vendor specific implementation of the SD cards.

  79. Andreas Do

    I tried this: http://3gfp.com/wp/2014/07/formatting-sd-cards-for-speed-and-lifetime/ but formatting is not the matter with our problem, the shutter bug stayed. The bug occured also when I just copied the ML-files (with autoexec.bin) to the totally erased sdhc-card, but the flags EOS-DEVELOP and BOOTDISK were not set. Of couse the bootflag in the EOS M was set. So I could not get the ML-menues and no ML-things were on the touch screen but the shutter bug was there! Then I just deleted the autoexec.bin from card and the bug was gone.

  80. josepvm

    I have tested now two additional 32 GB SDHC Class 10 UHS-I cards, but this time both are Sandisk cards: one of them being a Sandisk Ultra 40MB/s, and the other a Extreme Pro 95 MB/s U3.

    With none of them I have experienced the shutter bug.

    And this two cards are from a very similar type to the previous 32 GB cards I tested, all affected by the shutter bug: several Transcend 32 GB SDHC Class 10 UHS-I U1 90MB/S 600x, and also a PNY 32 GB SDHC Class 10 UHS-I U1 30MB/s. But the Sandisk cards do not show the shutter bug, and the other brands show it,

    The bevaviour is absolutely repeatable for me: same camera settings, same lens (EF-M 18-55mm). If i put in the camera one of the Sandisk cards, no shutter bug. If I shut down the camera, switch to a Transcend card, and power on ... shutter bug immediately appears, I cannot take photos. Switching to a Sandisk again, no shutter bug, the shutter works Ok.. Tested lots of times, this behaviour is the same 100% of the time.

    So it seems clear to me that we have a brand-related SD card compatibility issue with Canon bootloader code, and that Sandisk cards are the safest option to avoid the bug.

    Now we have to discover what is the difference between these cards...

  81. Daniel Fort

    I was on vacation when all the recent activity came up so I wasn't able to run the tests but here's my experience with the shutter-bug on this last trip. Before leaving I turned off the camera boot flag, formatted all my cards in camera using the low level option, then copied and installed ML on all my cards. I swear that I tested all the cards before leaving but I did experience the shutter-bug on all of my 64GB cards while the 32GB SanDisk cards were fine. Specifically, these are the cards, all formatted exFAT:

    2x 32GB SanDisk Extreme PRO, Class 10, UHS Speed Class 1 (U1), 94MB/s, SD HC I -- no shutter-bug on either card

    2x 32GB SanDisk Extreme PRO, Class 10, UHS Speed Class 1 (U3), 94MB/s, SD HC I -- no shutter-bug on either card

    2x 64GB Komputer Bay Professional, Class 10, UHS Speed Class 1 (U1), 600x, SD XC I -- shutter-bug present on both cards

    1x 64GB Lexar Professional, Class 10, UHS Speed Class 1 (U1), 600x, SD XC I -- shutter-bug present

    As a sanity check I re-formatted and re-installed ML on the 64GB cards and shutter-bug showed up right away. Guess I didn't check everything thoroughly before the trip!

    My understanding is that there is a formatting difference between cards 32GB and under (SD HC) and the larger capacity cards (SD XC).

    Anyone have shutter bug experience with SanDisk 64GB (and up) Extreme Pro UHS-I SDXC U3 Memory Cards (Class 10) ?

  82. Daniel Fort

    I have run out of space using 32GB cards while doing time lapse and the 64GB cards I own have the shutter-bug present so I took a chance and bought on of these from B&H Photo:

    SanDisk 128GB Extreme Pro UHS-I SDXC U3 Memory Card (Class 10)

    No shutter-bug! At least not yet. So far all of the SanDisk Extreme Pro UHS-I 94MB/s cards that I have tried have not exhibited the shutter-bug. Anyone else experience this?

  83. josepvm

    I have found that using Sandisk cards does not give you 100% guarantee of not suffering ocasionally the shutter bug. I have experienced it several times when using the EF-M 11-22mm with a Sandisk Extreme Pro 32 GB SDHC Class 10 UHS-I 95 MB/s U3.

    But most of the time, this card runs shutterbug free. Much better than Transcend cards, sure.

  84. Rob G

    Just thought I'd add that I'm experiencing the shutter bug with a Transcend 64GB Class 10 SDXC 3 card and the EF-M 18-55mm lens. A Samsung 32GB Class 6 MicroSD card (in adapter) doesn't exhibit the problem.

    I've also discovered a workaround that may or may not work for others.

    If I briefly press the image review ("Play") button so that the orange LED lights, then press the power button, the camera starts up without the shutter bug. It's similar to doing a quick power cycle of the camera as described earlier in the thread I think.

    The action is as follows:

    1. Very briefly press the image review button
    2. Wait 1 second (the orange LED should have come on by now)
    3. Press the power button as if turning the camera on normally.
    • If you press the power button really quickly after pressing the image review button, it won't work
    • If you press the power button once the orange LED has turned off, it won't work
    • If you don't press the power button long enough, it won't start at all, similar to not pressing the image review button long enough if you actually want the camera to start into that mode. (this isn't true)

    It's actually not so hit-and-miss as I might be making it out, you just have to wait that second between button presses.

    Background: I'd noticed that if I accidentally briefly pressed the "playback" (image review) button when the camera was off, the LED would come on briefly. The camera actually turns on if you press this button any longer, which is extremely annoying when inserting the camera into a bag.

  85. Kristian Wannebo

    Let me collect the comments Rob G refers to above concerning his play-button-plus-power-on workaround.

    The quick power cycle workaround is described here:
    Morghus 2014-03-08 ,
    a1ex 2014-03-08 ,
    salimvanak 2014-08-26 .

    Then there is also a lens-twist workaround, described here:
    salimvanak 2014-11-12 ,
    Janke 2015-01-16 .

    The 11-22 lens seems to react differently according to whether it is uncollapsed before or after powering the camera on:
    Janke 2015-01-25 ,
    Aart Olsen 2015-04-09 .

    ( This seems, as mentioned before, to connect to the non-appearance of the shutter bug with EF (S) lenses.)

    I just thought there might be some connection between these seemingly very different methods?

  86. Rob G

    For consistency I'll mention that it was indeed the EF-M 18-55mm lens that I had on when describing my play-plus-power workaround. I unfortunately don't have any other EF-M lenses to test with, the rest of my lenses are EF(-S) and I don't have an adapter. Perhaps someone else could see how it behaves with the other EF-M lenses.

  87. josepvm

    Tested the play-button-plus-power-on workaround and It works well for me, for both EF-M 18-55mm and EF-M 11-22mm. No shutter bug when starting the camera this way, even If starting with the EF-M 11-22m in extended position.

    And it works for all my Transcend and PNY 32GB SDHC cards that always show the shutter bug if camera is started in the normal way.

    I have noticed also that If camera is started with this method (play buttton plus power button), when I shut down the camera I do not see the sensor cleaning message on screen.

    Ocasionally the sensor cleaning message does not show also when shutting down after a normal start or after a quick power off-on cycle. But this is uncommon, most of the time I see the sensor cleaning message. But when using the play button trick, I never see it. Even when using a lens (EF-M 22mm) or an SD card (Sandisk) that do not trigger the shutter bug.

    Edit: With the EF-M 18-55mm this new workaround is not 100% successful. Sometimes, when first using the camera, it has no effect, the shutter does not work. But after unlocking the shutter by other methods, and taking several photos, the workaround works again.

  88. Daniel Fort

    I can verify that Rob G's method also works with the 11-22mm EF-M lens. Though with that lens if you turn on the camera with the lens collapsed that will also work. Note that you will not get the "Set the lens to the shooting position" warning when you turn on the camera if have ML loaded.

    Oh--and the 128MB SanDisk card that I reported as working now exhibits the shutter-bug. Darn it. The 32GB San Disk cards are still fine.

  89. Anton Petukhov

    Thanks for the hint 2x2

    Download for Raw raw2dng cs2x2

    and MLV - MLV mystic.

    ML weighs whole folder - 2.5 mb

    and from LOGO - 32 MB

    it seems to me, and hinders launch ML on slower cards

  90. Anton Petukhov

    Manual mode is probably more to problemme focus and not to the shutter..

    In the first variant with the LOGO - kingston 40/11 mb/s

    in the second variant with the shutter problemoi due focus - sandisk 95mb/s

  91. Douglas Blood

    I don't see the shutter issue on my EOS-M. I can do whatever testing / checking to help identify the cause. I have all 4 lenses, 16GB SD card formatted exFAT (with low level done on OSX).

    I am running the 2015-04-19 00:08:06 +0200 build, and have a couple SD cards, both normal and micro with an adapter.

  92. Daniel Fort

    You shouldn't have to change any setting. In addition, the shutter-bug has shown up on large capacity cards and small capacity ones. Mount any EF-M zoom lens and shoot some stills--this doesn't affect movie mode, raw video, etc. It might work fine at first so turn the camera on and off and keep testing. The only cards that I have that aren't currently affected by the shutter-bug are 32GB SanDisk Extreme PRO, Class 10, 94MB/s, SD cards.

    If you shoot stills on an EOS-M with an EF-M zoom and Magic Lantern running--you probably have run into times when the camera just won't fire off a shot. That's the shutter-bug.

  93. Daniel Fort

    I thought I'd go back to a test that a1ex posted. It looks like it wasn't tested thoroughly so I ran the tests on a 128GB SanDisk Extreme PRO card and a Komputer Bay 64GB 600x card that exhibits the shutter-bug:


    a1ex:

    Another test:

    old minimal autoexec - it simply jumps to Canon firmware; you should be able to reproduce the bug with this one.

    minimal autoexec v2 - this jumps to Canon firmware with a different method; do you get the shutter bug with it?

    Sources:

    old one, reported to show the shutter bug:

    B 0xFF0C0000         ; jump to main firmware
    

    new one, tested in QEMU:

    LDR R0, =0xe3a00001  ; MOV R0, #1
    
    LDR R1, =0x401018E8  ; Let the bootloader jump to main firmware,
    
    STR R0, [R1]         ; by patching a return value.
    
    BX LR                ; After patching, return from autoexec.bin.
    

    2015-04-30


    My results:

    old minimal autoexec - no shutter-bug on SanDisk - shutter-bug on Komputer Bay

    minimal autoexec v2 - camera locks up - blinking green light on both cards

    After running the test with minimal autoexec v2 the cards would lock up the camera even after deleting all of the files. Removing the camera boot flag allowed the camera to power up properly with these cards and cards worked fine after formatting in the camera. I repeated the tests a few times to make sure I got the same results.

    So the shutter-bug misery continues to confound...

    A while back it looked like a couple of the developers were on to something.


    dmilligan:

    I'm really surprised the whole 'EOS_DEVELOP' thing didn't work out, I was looking through the strings in my 60D firmware dump I noticed "EOS_DEVELOP" towards the very end with some other strings that seem to be related to the bootloader (like 'autoexec.bin') and what looks like some sort of Canon debugger menu. Maybe it's EOS_DEVELOP in addition to other properties of the SD card or it's formatting that's making it work. I think it's worth further investigation. Too bad the person who found that hasn't been heard from since.

    2015-02-07

    a1ex:

    Actually, EOS_DEVELOP is one of the strings written when making the card bootable. Maybe the EOS-M also expects it in some other location? Definitely worth further investigation. On 7D, there was a similar bug in the bootloader. If, during the boot process, the slave CPU had some delay (dummy for with asm("nop") inside) before jumping to main firmware, but after poking the master CPU, it had a somewhat similar issue with certain lenses (AF not working properly). If this issue is similar, maybe slow cards could be causing trouble? Or maybe cards of a given capacity or filesystem?

    2015-02-07


  94. Matthias Bretz

    Hi, I just wanted to share my experience with the "shutter bug".

    I'm running MagicLantern since one year on my EOS M (Gen1) with an SanDisk Extreme 32GB (SDHC Class10 45MB/s) and used the EF-M 18-55mm, the EF-M 22mm and a manual Samyang 12mm without ever running in the "shutter bug".

    A week ago I received my new Tamron 18-200mm (EF-M-Mount) and with this lens I "always" get the shutter bug. LensFirmware is 1.2.9

    Workarounds that work for me:

    • Turning on the camera and then dismounting the lens and mounting it back again

    • Powering up the camera with the play-button, waiting for one second and then hitting the ON/OFF-button (no sensor-clean as I turn the camera off)

    • Using a non-ML-SD-Card

    Workaround I tried but without an affect:

    • Naming the SD-Card-Volume-Name "EOS_DEVELOP"

    • Switching from FAT32 to exFAT

  95. Daniel Fort

    Interesting, so you are seeing the shutter-bug with the Tamron 18-200mm EF-M but not the Canon 18-55mm EF-M? Could you give us more information about the card you are using?

    Just for the record, here are the current firmware versions of the various EF-M lenses:

    • Canon 22mm- 1.8.0 (no shutter-bug)
    • Canon 18-55mm - 2.0.0
    • Canon 11-22mm - 1.0.0
    • Canon 55-200mm - (could someone check the firmware version on this lens?)
    • Tamron 18-200mm - 1.2.9

    I don't know if this is leading anywhere but when I mounted a Canon EF lens via the EF-M adapter it didn't show any lens firmware information. Do any other Canon cameras show firmware versions for their lenses?

    [Edit - I just found out that yes they do. The firmware can be updated on some lenses but only with some of the higher end Canon cameras. Other lenses need to be taken to a Canon service center to have their firmware update. Apparently it is the same with Sigma and other third party lenses.]

    [Edit 2 - Someone reported that the Canon 40mm pancake can be updated on the EOS-M using the EF-M adapter.]

    I don't think the developers were referring to the card name when they were discussing EOS-DEVELOP. I believe that it is some sort of a system call.

    Changing the SD card formatting? Apparently that hasn't worked when other have tried it either. The Sandisk 32GB Extreme PRO cards that don't show the shutter-bug are formatted as FAT32. The 64GB and larger cards that I've got an do show the shutter-bug are formatted as exFAT. I think that has to do with the difference between SDHC (32GB and under) vs. SDXC (over 32GB). I've also got some small (1 and 2GB) cards that are formatted in FAT16 and they also exhibit the shutter-bug. Has anyone had any luck formatting SDXC cards as FAT32? Is that even possible or desirable?

  96. Kristian Wannebo

    Re. Lens firmware info:

    EOS-M Mk I , Magic Lantern Nightly.2015apr19.EOSM202 .

    EF 28-105mm 1:3.5-4.5 shows NO lens firmware info, (but it is a rather old lens). EF-S 55-250mm 1:4-5.6 IS STM does, 1.0.2 .

    ( My only EF-M lens is the 22mm, so I have not had a chance to experience the shutter bug.)

  97. Matthias Bretz

    Interesting, so you are seeing the shutter-bug with the Tamron 18-200mm EF-M but not the Canon 18-55mm EF-M?

    Right, just double checked it. No Shutter bug on the EF-M 18-55 (started up the camera at 18mm, 35mm and 55mm) but on the Tamron 18-200mm (every zoom-setting, always the shutter bug).

    Could you give us more information about the card you are using?

    Shure, what else do you need to know?

    My Lensfirmwares are:

    • Canon EF-M 22mm - 1.8.0
    • Canon EF-M 18-55mm - 2.0.0
    • Tamron EF-M 18-200mm - 1.2.9

    Tamron offers a firmware-update for the 18-200mm based on the serial number of my lens I don't have the latest firmware but i couldn't find any information about the firmware-numbers before and after the update service. And I read that some EOS M3 refused to power up with the Tamron attached (and the lens having the old firmware).

    I don't think the developers were referring to the card name when they were discussing EOS-DEVELOP. I believe that it is some sort of a system call.

    You're right, but I wanted to give it a try.

    Changing the SD card formatting? Apparently that hasn't worked when other have tried it either.

    Also here, I wanted to give it a try.

  98. Daniel Fort

    Give us as much information about the card as possible, including the way it is formatted. Point to a B&H or Amazon page if that's easier. For example, the card that is working for me is this one: http://www.bhphotovideo.com/c/product/824140-REG/SanDisk_SDSDXPA_032G_A75_Extreme_Pro_32_GB.html

    There are probably variables in manufacturing so a further step would be to run an in camera speed test and report those findings but the goal should be to resolve the shutter-bug no matter what card is being used. Still, it is good to know what works and what doesn't with the current build.

    Speaking of--you may have noted that nightly builds are failing for EOS-M. This is intentional until another issue is resolved. However, development on the unified branch is moving forward so if you want to test the most recent version that includes some changes that affect the EOS-M email me and I will send you an updated build. (dan (at) digiola (dot) com)

    As for Matthias Bretz's finding that one lens works while another doesn't--this may prove important to tracking down the problem. It seems that the card is fast enough for the Canon EF-M 18-55mm but not the Tamron EF-M 18-200mm. Just like my test with the Sandisk 128GB card being fast enough to work with a1ex's minimal autoexec but not the Komputerbay 64GB card.

    Matthias Bretz - Could you try the old minimal autoexec on your card and Tamron lens and report back? The old minimal autoexec will go through the boot process but not load ML. At least that's what I think it does. I'd skip the minimal autoexec v2 test because all it did for me was to lock up the camera and make the card unusable on a camera that has the boot flag set.

    The old minimal autoexec file can be found here: https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/EOS-M/minimal/autoexec.bin

    [EDIT - BTW, if you got your Tamron lens recently you might already have the firmware update: http://www.tamron-usa.com/about/updates_canon_B011.php ]

    [EDIT 2 - if you think the shutter-bug is bad, check out what happens with the Tamron EF-M 18-200mm lens on an EOS-M3: https://youtu.be/bYuS25sWCmo ]

  99. Daniel Fort

    Up until now I assumed that the shutter-bug was common to all of the EF-M zoom lenses but apparently that isn't the case. I repeated a1ex's old minimal autoexec.bin test on both the Canon 18-55mm and the Canon 11-22mm lenses but came up with the same results.

    I noticed something with the Canon 11-22mm EF-M lens that might be helpful in solving the shutter-bug issue. This lens can be locked in a collapsed position that reduces the barrel length by about 1cm. It is interesting that the minimal barrel length is when the lens is set to about 14mm focal length and barrel length increases at both the minimum and maximum focal length--but that's beside the point.

    When powering on the camera either without a card or with a non-Magic Lantern card and the Canon 11-22mm EF-M lens in the collapsed position there is warning on the screen that reads, "Set the lens to the shooting position" and the camera won't fire the shutter with the lens in the collapsed position. However, when the camera is booted up with ML and this lens in the collapsed position, there is no on screen warning. With ML loaded onto a card that exhibits the shutter-bug if the camera is turned on with the lens in the uncollapsed position, the shutter won't fire but leaving the camera turned on, if this lens is collapsed the on screen warning appears. Once again leaving the camera turned on and uncollapsing the lens the shutter-bug is gone. That is, of course, until the next time the camera is powered on with the lens in the uncollapsed position. By the way the shutter won't fire with the lens in the collapsed position whether or not ML is running on cards with or without the shutter-bug. Note that I have the "Release shutter w/o lens" option enabled.

    Is this of any help to a developer that might be reading this? At what point in the ML boot process is the lens firmware being loaded? Could it be possible that the lenses that are more susceptible to the shutter-bug are the ones with the more elaborate firmware? I'm suspecting that the Canon EF-M 22mm has the simplest firmware and the Tamron EF-M 18-200mm has the most complex one.

    There may also be an EF or EF-S lens mounted on the EF-M adapter that will trigger the shutter-bug that we don't know about yet.

    The report from a user that updated a Canon 40mm pancake lens using an EOS-M might be a key to solving the shutter-bug. Here is the information about that firmware update:

    http://www.usa.canon.com/cusa/support/consumer?pageKeyCode=prdAdvDetail&docId=0901e0248060f7c7

    Maybe looking into a lens firmware update will help developers?

    Note: I've done some pull requests but this stuff is way beyond my coding abilities. I'm willing to give it a try if someone can give me a tip where to get started.

  100. Matthias Bretz

    My card is this one:

    http://www.amazon.de/gp/product/B00428N88M?psc=1&redirect=true&ref_=oh_aui_detailpage_o01_s00

    On my Mac the cards speed gets 42 MB/sec write and 43 MB/sec read. I tried formatting the card in the camera (FAT32) and formatting it on my Mac (extFAT) both with the same result.

    I tried the minimal autoexec with my card and the Tamron lens. The shutterbug ist still there but can be avoided by removing the lens or starting up the camera by the play-power button combination. Just like with the usual autoexec-file.

    The serial number of my Tamron lens is in the 400-range so I will try to get in contact with Tamron to know if 1.2.9 is the latest (and fixed) firmware or not.

    I also tried to measure the boot-time of the camera with different lenses but al I noticed was, that a normal boot takes about 2.5 seconds and the play-power button combination just takes about 1.3 seconds between power-button-press and the live-view appear.

    Even I have the "Release shutter w/o lens" option enabled (need it for my manual Samyang 12mm).

    And I swapped some lenses through my EF-adapter, non listet a lens-firmware-information. EF 35mm F2, EF-S 60mm F2.8, EF 85mm F1.8, Tamron 24-70mm F2.8 VC and EF 70-200mm F4 L IS.

  101. Daniel Fort

    Matthias Bretz You are in Germany? That's a good thing because Tamron is more likely to help with the firmware update--the EOS-M3 isn't available in the U.S. and the firmware update only resolves an issue with the M3.

    If possible you should try the faster Sandisk card that I pointed out earlier. Even though the EOS-M has about a 41 MByte/s data transfer limit there does seem to be a slight performance increase with the faster card. Run a benchmark test in camera, this will give you a more accurate picture of the card's performance. I took a card that doesn't exhibit the shutter-bug and formatted it in camera (w/o ML) and reinstalled Magic Lantern on it to restore the default settings. This should eliminate any data fragmentation issues or perhaps having a setting that affects the data transfer. Here are the results I got:

    BENCH0.jpg

    Try running the benchmark test on your card. Go to the ML menu-- Debug (0101) -> Benchmarks -> Card R/W benchmark (5 min). This will write a file called BENCH0.PPM on your card. I converted mine to JPEG in order to upload it to this post.

  102. Matthias Bretz

    Yes I'm from germany. The mail to Tamron is on it's way and I'm waiting for response, maybe tomorrow.

    For short I ran the benchmark, my card is just a bit slower... maybe I will do the benchmark tomorrow again (now I was to lazy to format the card). bench0.png

    And if I get the chance to borrow a faster card I will redo the test and check if it changes any behavior with the shutter bug.

  103. Daniel Fort

    As a comparison I ran the test on the Sandisk 128GB Extreme PRO card that tested out fine with the old minimal autoexec.bin. The results came out pretty much between my Sandisk 64GB Extreme PRO and your Sandisk 64GB Extreme card. I don't want to clutter up this topic with too many card speed tests but it looks like we're narrowing down on what speed is required to clear the shutter-bug hurdle. It will be interesting to find out if the Tamron lens works with a (slightly) faster card.

    [EDIT - just an observation but the 64GB Extreme card didn't exhibit the shutter-bug on the 18-55mm EF-M and yet it tested out slightly slower than the 128GB Extreme PRO card that did exhibit the shutter-bug on that lens.]

  104. Douglas Blood

    Has it been suggested yet that this issue might be ML booting too fast? I think this would explain why more people are seeing this as more people get faster cards (but this might just be my perception). Could ML run a check on the lens before the lens itself has booted. Similarly, is it possible to hack in a lens reboot / simulate a disconnect-reconnect of the lens at the end of the boot-up?

    I'll keep testing my own cards and lenses, but until I can find a way to reproduce the issue myself I can't test any of these out.

  105. Daniel Fort

    I've got another observation that someone might try reproducing. You need a Canon 11-22mm EF-M lens and some SD card that do and do not exhibit the shutter-bug.

    With the boot flag not set on the camera, power on with the lens in the collapsed position you should get the "Set the lens to the shooting position" warning on all cards.

    With the camera boot flag set pull the battery, wait at least 2 seconds before reinserting and turn the camera on with the lens in the collapsed position. The first time it will always turn on without the warning message. Subsequent power cycling will show the warning message on cards that do not exhibit the shutter-bug and will not show the warning message on cards that do exhibit the shutter-bug. It doesn't seem to matter if the boot flag is set on the card or if ML loads or not. This has been fairly consistent but not 100%, sort of like trying to reproduce the shutter-bug 100% of the time.

    The battery pull is something that is recommended when updating the lens firmware. From the Canon lens firmware instructions:

    "When the firmware update operations are finished, turn the camera <OFF> and remove battery from the camera for at least two seconds. This will cause the new firmware to take effect after the battery has been reloaded and the camera is turned on."

    I'm assuming that the warning message is in the lens firmware so if it doesn't appear it might mean that the lens firmware didn't load properly.

    It seems a little strange that on cards that don't exhibit the shutter-bug when the camera boot flag is enabled and a battery pull is done, the warning message doesn't appear on the first power up.

    I could write this up as a new bug report but it does seem to be closely related to the shutter-bug.

    [EDIT - I just found out that I can reproduce the shutter-bug without loading ML. All that is needed is to have the camera boot flag enabled. Again this isn't 100% reproducible but it did happen when powering up the camera with both the 11-22mm lens in the extended position and with the 18-55mm lens.]

  106. Matthias Bretz

    OK, I ran the debug-build on my Tamron (shutter bug) and on my 18-55 (no shutter bug).

    I found in the my logs and your’s looks similar that if the shutter bug doesn’t appear ASCheckOverrun Time(7s) hast a very small value on our both cameras an on different cards (a value of under 10). If the shutterbug appears the value is ASCheckOverrun Time(6665s). And in my log with the Tamron lens there is no appearance of DL(H->L).

    I won’t bet on it but I think we are damn close.

    Here a screenshot of the main difference between shutter bug on the left and no shutter bug on the right: Bildschirmfoto 2015-07-20 um 22.40.41.jpg

    Since you have a card affected by the bug and one not, could you try confirming my found values?

  107. Daniel Fort

    Nice work. Here are my log files:

    https://drive.google.com/folderview?id=0BwCosJpHfhBsfllmdFVDMEJqblJEUURzc1JpTmVGc2ZCc0FDRlJKWXowbjRHd0hURWpKMGs&usp=sharing

    I switched over to the Canon 18-55mm EF-M because that is the most common lens used with the EOS-M.

    I tested three cards. The Sandisk 32GB that works. Screen Shot 2015-07-20 at 2.54.27 PM.png The Sandisk 128GB that has the shutter-bug. Screen Shot 2015-07-20 at 2.54.59 PM.png And a Lexar Professional 64GB 600x Speed card that also has the bug. Screen Shot 2015-07-20 at 2.55.17 PM.png

    Indeed the cards with the shutter-bug show slower ASCheckOverrun Time values than the card without the shutter-bug.

    I've got a few more tests in mind but I'll spare the readers with screenshots and full logs and just report the ASCheckOverrun values.

  108. Daniel Fort

    Here are some more tests.

    22mm lens (never a reported shutter-bug problem) with Sandisk 128GB card that is affected by the shutter-bug

    • PropMgr:ff1be008:83:03: ASCheckOverrun pAsRecord Time=1437416891s dwCount=4
    • PropMgr:ff1be068:83:03: ASCheckOverrun Time(3s)

    Same Sandisk 128GB card using 18-55mm lens--a combination that does have the shutter-bug

    • PropMgr:ff1be008:83:03: ASCheckOverrun pAsRecord Time=1437413523s dwCount=4
    • PropMgr:ff1be068:83:03: ASCheckOverrun Time(11s)

    For comparison, here's the 22mm lens on the Sandisk 32GB card that doesn't have the shutter-bug (it is actually slower than the card with the shutter-bug)

    • PropMgr:ff1be008:83:03: ASCheckOverrun pAsRecord Time=1437417207s dwCount=4
    • PropMgr:ff1be068:83:03: ASCheckOverrun Time(4s)

    And finally, the Sandisk 32GB card without the shutterbug with the 18-55mm lens

    • PropMgr:ff1be008:83:03: ASCheckOverrun pAsRecord Time=1437413480s dwCount=2
    • PropMgr:ff1be068:83:03: ASCheckOverrun Time(4s)

    Just for grins I ran the test with a 22mm lens and an old Kodak 1GB card formatted FAT16 - no shutter-bug - lowest common denominator:

    • PropMgr:ff1be008:83:03: ASCheckOverrun pAsRecord Time=1437417767s dwCount=4
    • PropMgr:ff1be068:83:03: ASCheckOverrun Time(4s)

    Finally, I tried the 18-55mm lens with old Kodak 1GB card formatted FAT16:

    • PropMgr:ff1be008:83:03: ASCheckOverrun pAsRecord Time=1437416550s dwCount=4
    • PropMgr:ff1be068:83:03: ASCheckOverrun Time(13s)

    Just out of curiosity I put the card back in the camera and tried firing off some frames. I just about fell off my chair -- NO SHUTTER-BUG! I thought that this couldn't be so I ran the same test again on that card and got these results:

    • PropMgr:ff1be008:83:03: ASCheckOverrun pAsRecord Time=1437419306s dwCount=4
    • PropMgr:ff1be068:83:03: ASCheckOverrun Time(2s)

    What is going on?

  109. Jimmie Tauriainen

    Well, I have a 64GB Kingston (class 10, not UHS marked) . And the bug has never been 100% solid. Sometimes I can boot up the camera 10 times in a row without being affected after that It could show up 20 times in a row. So how exactly do you verify? One is not enogh, at least not for my setup if I want to be sure that Im not affected, and yes is NOT about not getting focus.

  110. Matthias Bretz

    I have to admit I was to fast with these values, they change every time you boot your camera. So I ran another "short" test, I bootet up my camera five times with the Tamron attached, which resulted in the shutterbug. Then I bootet up my camera five times with the Tamron attached but used the Play-Button-Power-Button combination which starts the camera in a different way, which kills the bug an I was able to take pictures.

    After that I compared all ten log files (noticing the ASCheckOverrun-values don't mix with the appearance of the bug). But here is what I found so far: if the camera ist started with the Play-Button-Power-Button-workaround the log shows StartupCondition : 4, 0 (a normal boot shows StartupCondition : 1, 0).

    Maybe it is possible to define this condition in the autoexec.bin-file so with ML the camera gets always bootet up with condition 4, 0 ?

  111. Daniel Fort

    I did some more tests on that old Kodak 1GB card and keep getting different results but never the shutter-bug. On my last post is the best of ASCheckOverrun Time(2s), here is the worse:

    • PropMgr:ff1be008:83:03: ASCheckOverrun pAsRecord Time=1437515657s dwCount=1
    • PropMgr:ff1be068:83:03: ASCheckOverrun Time(1493s)

    I should qualify this by saying that I'm not really sure what ASCheckOverrun is, what the units of time are or if it is even significant. I can say that this is a really slow card:

    BENCH0_Kodak_1GB.jpg

    Maybe it is because this card is formatted FAT16? Nope, I tried another card, an old Patriot 2GB card that is also formatted FAT16 and it has the shutter-bug. So it isn't the formatting or the speed of the card. A few posts ago I reported that I was able to reproduce the shutter-bug without loading ML. This happened on a bootable card and the camera had the boot flag enabled, so maybe the issue is in the MBR (Master Boot Record) of the card? I don't know, this is difficult to test because the results are somewhat erratic and the combination of a bootable card and the camera boot flag enabled often ends up in a locked up camera that requires a battery pull.

    Matthias Bretz Pointed out that he got different StartupCondition values when he started up using the Play-Button-Power-Button combination that kills the bug. Indeed every log that I've got when the camera was powered on via the ON/OFF button shows a StartupCondition : 1, 0 no matter if the shutter-bug was present or not. I ran a different test, what happens if the camera is turned on only using the PLAY button?

    • Kodak 1GB 16, 0 (no shutter-bug)
    • Sandisk 32GB 16, 0 (no shutter-bug)
    • Sandisk 128GB 16, 0 (shutter-bug)
    • Lexar 64GB 16, 0 (shutter-bug)

    I'll try the Play-Button-Power-Button-workaround but I need some practice first because it doesn't always work for me.

  112. Daniel Fort

    Finally, something significant to report.

    Matthias Bretz found the key. After a few practice runs I got the Play-Button-Power-Button combination timing down and got a consistent StartupCondition : 4, 0 on all the cards. This killed the shutter-bug on the cards that exhibited the shutter-bug and the cards that didn't exhibit the shutter-bug continued to function without the shutter-bug.

    So now we need help from a developer to figure out how to get this to happen every time the EOS-M is powered on:

    PropMgr:ff23cfb4:81:03: StartupCondition : 4, 0

  113. Daniel Fort

    I ran a diff on a log from one of the cards that exhibited the shutter-bug with and without the Play-Button-Power-Button combination. There were several differences. There might be something else of significance so I uploaded "Sandisk_128GB_Play-Button-Power-Button_no_shutter-bug" to my Google drive. All the test logs are located here:

    https://drive.google.com/folderview?id=0BwCosJpHfhBsfllmdFVDMEJqblJEUURzc1JpTmVGc2ZCc0FDRlJKWXowbjRHd0hURWpKMGs&usp=sharing

  114. Daniel Fort

    Excuse me for my OCD behavior these past few days. I really think we are getting close.

    I couldn't find StartupCondition or that hex address in platform/EOSM.202/stub.S so I went looking for it. I followed the excellent Tutorial: finding stubs by Alex and disassembled the EOS-M firmware.

    My initial search of ROM1.BIN.dis found StartupCondition and the hex address, ff23cfb4, in that vicinity. An offset was expected as explained in the tutorial. Here is a snippet of the disassembly:

    ff23cfa8:   e28f2d09    add r2, pc, #576    ; ff23d1f0: (72617453)  *"StartupCondition : %d, %d"
    ff23cfac:   e3a01003    mov r1, #3
    ff23cfb0:   e3a00081    mov r0, #129    ; 0x81
    ff23cfb4:   eb371c46    bl  loc_40d4
    ff23cfb8:   e3540002    cmp r4, #2
    ff23cfbc:   0a000054    beq loc_ff23d114
    ff23cfc0:   e5950014    ldr r0, [r5, #20]
    ff23cfc4:   e3500000    cmp r0, #0
    ff23cfc8:   0a00013a    beq loc_ff23d4b8
    ff23cfcc:   e28f2f8e    add r2, pc, #568    ; ff23d20c: (20514552)  *"REQ CLR Adjective & Situation : StartupCondition"
    ff23cfd0:   e3a01016    mov r1, #22
    ff23cfd4:   e3a00081    mov r0, #129    ; 0x81
    ff23cfd8:   eb371c3d    bl  loc_40d4
    ff23cfdc:   e5859018    str r9, [r5, #24]
    ff23cfe0:   ea00004b    b   loc_ff23d114
    

    So, what's the next step? Create an entry in platform/EOSM.202/stub.S? Try to assign 4, 0 to StartupCondition in src/boot.c or boot-hack.c? Playing around with property handlers looks like dangerous territory.

    [EDIT - removed ROM1.BIN]

    [EDIT 2 - removed link until I get confirmation that the disassembly is ok to share publicly.]

  115. Daniel Fort

    These are all interesting tests but I'm in over my head figuring out how to use this information to fix the shutter-bug issue--and believe me I really made an effort. I'll be happy to share the disassembly files with anyone who wants them, email me (dan (at) digiola (dot) com). If you are running Magic Lantern on an EOS-M you've already got the ROM1.BIN file in the ML/logs directory of your SD card.

    I'm not an expert but I believe that StartupCondition is simply reporting a condition and probably cannot be set during boot up. Unmounting and remounting the lens is another shutter-bug workaround so a solution may be to find a way to reload the lens information. Maybe this would be possible with a lua script? I don't know.

    In any case it would be nice if a developer would comment. I'm sure us EOS-M users would like this fixed but there are far more interesting projects out there and only so many developer volunteer hours to devote to this little discontinued camera.

  116. nikfreak

    Found myself indications on 70D ROM and would check myself after publishing a new release for 70D on forums. Firmware could check and clear (ROM strings: current adjective / situation and clear adjective / situation) it later again so I would like to see what debug log shows while using the cam. Bug exist for ~1.5 years so at least you seem to have found a workaround. Guess it's not up to some more days. ML development sometimes might let you feel lost especially while you are on a learning curve but you are doing great up until now. Like what I see / read (on forums,too). Keep it up, really!

  117. Daniel Fort

    This is what we know about StartupCondition so far:

    • StartupCondition : 1, 0 = camera powered on normally, with the ON/OFF button
    • StartupCondition : 16, 0 = camera powered on via the Play button
    • StartupCondition : 4, 0 = Play-Button-Power-Button workaround used by Matthias Bretz - interrupted startup?

    Interesting that Licaon Kter brought up ASCheckOverrun Time. The cards that don't exhibit the shutter-bug show faster times, less than about 10s while the ones with the shutter-bug show 11s and over. Maybe Licaon Kter's system boots so fast that it doesn't even show a value for ASCheckOverrun. Funny thing is that the Play-Button-Power-Button workaround increased ASCheckOverrun Time to:

    • PropMgr:ff1be008:83:03: ASCheckOverrun pAsRecord Time=1437527028s dwCount=6
    • PropMgr:ff1be068:83:03: ASCheckOverrun Time(395s)

    The dwCount is usually 2 to 4 with the regular power on methods.

    My theory about the shutter-bug is that it isn't the actual speed of the card but it does have something to do with the way it is formatted and the amount of time it takes to read the boot sector. The Kodak 1GB card is by far the slowest card I have yet it doesn't exhibit the shutter-bug yet the fastest 64GB and up cards are more susceptible. It also looks like after the first start up there is some card information cached because subsequent start ups are faster, until the battery is pulled as recommended when updating the lens firmware. If the camera boot flag isn't set, it won't read the boot sector and the lens firmware is loaded properly but when the boot flag is set it seems that there is a critical moment when the system is reading both the card and loading the firmware and depending which one takes priority, the lens firmware might not load properly. This is perhaps why some cards always exhibit the shutter-bug, others don't and some cards are very close to the critical point where they become unpredictable.

    As far as which lenses show the shutter-bug, the EF-M zoom lenses with image stabilization are the only ones we know of and they probably have the most complex firmware. These lenses have no external switches so everything must be handled through the camera/lens connection. We don't know of any Canon EF/EF-S lenses that exhibit the shutter-bug but maybe some of the newer lenses with advanced electronics and firmware will trigger the shutter-bug. However it doesn't matter which shutter-bugged lens you're using, simply breaking the lens/body connection while the camera is powered on will cause the camera to re-read the lens firmware and the shutter-bug is gone.

    The Play-Button-Power-Button workaround is effective only if you time it just right and what seems to be happening is that the camera is allowed to read the card's MBR then the boot process is interrupted just long enough to re-initialize the boot process without having to re-read the card. In other words the lens firmware is loaded with a "hot" system as opposed to a "cold" boot. Sort of like what happens when the lens is hot swapped. This may also explain the much longer ASCheckOverrun Time when starting with the Play-Button-Power-Button workaround.

    So much for theory--I might be totally off base on this but what I believe that we need to do is to find out what happens when the lens/body connection is broken and the camera re-loads the lens firmware. I'll try to figure out how to turn on logging and do a lens unmount/mount to see what's going on. Any hints on how to do this? nikfreak -- can you point me in the right direction?

  118. nikfreak

    Best you can do is to disable startup logging but leave intercept debugmsg enabled. Now afterwards you can use "Debugmsg log" in debug menu or place the call for the logging elsewhere. Hint: set your fps to a lower value. If you want to log specific stuff / stubs have a look at dm-spy-extra.c in my "dmspy-70D-new" branch. Start with StateTransition / TryPostEvent stubs. Using too much at first isn't a good idea. Later, add those you want to be logged too (for e.g. I was talking about current adjective / clear adjective / current situation / clear situation. It's a big stub containing all those and may be worth taking a look).

    EDIT: In theory you should at least be able to see a difference with the StateTransition / TryPostEvent stubs comparing the logs with cam booted normally and cam booted by Play-Power-Button. Guess there could be lines containing abort / wait / late / error words...

  119. Matthias Bretz

    Sorry I was off that last days. I'm not really familiar with the source code so forgive me if I am totally wrong...

    So far as I understand src/boot-hack.c contains code that ist executed at startup? I found some statements where (for what I understand) the Canon-firmware gets loaded ("call Canon's init_task"). Wouldn't it be possible to code a delay (sleep for 100 or 200 milliseconds) before starting the Canon-firmware? Or maybe for debug purpose give it a full second to see if it helps the lens firmware to be fully loaded in time?

  120. Daniel Fort

    Thanks for tips nikfreak I cloned your dmspy-70D-new branch and will start going through it.

    Matthias Bretz there are a few areas where we can try adding a delay. Here are the boot-hack.c "call Canon's init_task" you mentioned:

    #ifdef CONFIG_DEBUG_INTERCEPT_STARTUP
        debug_intercept();
    #endif
    
        // memory check OK, call Canon's init_task
        int ans = init_task_func(a,b,c,d);
    
    #ifdef ARMLIB_OVERFLOWING_BUFFER
        // Restore the overwritten value, if any
        if(backup_address != 0)
        {
            *backup_address = backup_data;
        }
    #endif
    

    and

        // Prepare to call Canon's init_task
        init_task_func init_task_func = &init_task;
    
    #ifdef CONFIG_ALLOCATE_MEMORY_POOL
        /* use a patched version of Canon's init_task */
        /* this call will also tell us how much memory we have reserved for autoexec.bin */
        init_task_func = init_task_patched(a,b,c,d);
    #endif
    

    From what I understand you don't have a setup that will compile ML. Just make the changes you want to make post the snippet here and I'll compile it for you.

  121. Daniel Fort

    I tried the simple task first--putting a delay before both of the call Canon's init_task areas. That didn't work so I also tried after the init_task_func calls. I tried msleep(1000) but noting that there were some other sections of the code with larger values I also tried msleep(10000). FYI, sleep(1000) and pause(1000) caused error messages.

    Well I did manage to get much longer boot times but the shutter-bug is still present.

    Any ideas where I could put this code snippet? Be nice!

    #if defined(CONFIG_EOSM)
        msleep(1000);
    #endif
    
  122. Matthias Bretz

    Daniel Fort your right, I don't have a setup that will compile ML. Could you try a complete different approach? Its just one of my random ideas ;)

    Try changing src/lens.c line 696 till 697 from this:

        int took_pic = mlu_lock_mirror_if_needed();
        if (took_pic) goto end;
    

    to this:

    #if defined(CONFIG_EOSM)
        call("Release"); //EOSM is mirrorless no need to check for MLU
        goto end;
    #else
        int took_pic = mlu_lock_mirror_if_needed();
        if (took_pic) goto end;
    #endif
    
  123. Daniel Fort

    Matthias Bretz Your message came in right when I was experimenting by putting delays in various places of boot-hack.c, nothing worked yet. I just tried your random idea and it didn't work either. I can post a build of it if you want to examine the log file, I'm working on the dm_spy_experiments branch until something works then I'll try it on unified.

    Your instructions are exactly what I needed and your code compiled on the first attempt--not like some of the code I wrote.

    Anything else you want to try?

    By the way, I compiled an EOS-M build from nikfreak "dmspy-70D-new" branch. This is a newer code base than "dm_spy_experiments" so we should probably start using it for further testing. As is it doesn't save the startup log file so take a look at that branch and let me know what you want me to do and I'll compile it for you--or anybody that wants to keep testing.

    https://bitbucket.org/nikfreak/magic-lantern/branch/dmspy-70D-new

  124. Daniel Fort

    Ok--I played around some more with the nikfreak "dmspy-70D-new" code. I enabled CONFIG_DEBUG_INTERCEPT_STARTUP and it created the same startup log that we've been looking at. However, following nikfreak's instructions on his last post I disabled startup logging but left intercept debugmsg enabled. I tried turning on DebugMsgLog in the Debug menu, the logging message shows up but I'm not getting any log files. Here's the build for anyone who wants to test it.

    https://drive.google.com/folderview?id=0BwCosJpHfhBsfk9ObF9aY202LWFBdzVfd2FueTdEbFdCZ0NHOW1QbWpvNzZGZjQ0NEdGSlE&usp=sharing

  125. nikfreak

    After the logging message shows up you need to "select" again DebugMsgLog:

    First selection activates logging

    Second selection writes the log to card. Btw: read this:

    http://www.magiclantern.fm/forum/index.php?topic=15233.msg148618#msg148618

    Licaon_Kter already posted some log in past but it's one w/o the StateTransition / TryPostEvent stubs and while raw_recording. We would need to catch the "Shutter bug" so activating the debugmsg and immediately taking some bursts then asap selecting debugmsg log could do the trick

  126. Daniel Fort

    Thanks nikfreak I've got some catching up to do. I had an Ah Ha moment today when I compared dm-spy-extra.c in your dmspy-70D-new and Alex dm-spy-experiments. There are no entries for the EOSM yet so I guess that's up to us to start testing. In the meantime I used your instructions to log what happens when a lens is unmounted then mounted--clearing out the shutter-bug. Here's the log:

    https://drive.google.com/file/d/0BwCosJpHfhBsNDhVcFl6NzBwWUE/view?usp=sharing

    And here's a log simply trying to fire off a shot with the shutter-bug preventing the shutter from firing:

    https://drive.google.com/file/d/0BwCosJpHfhBsYnZxWlJxUl92X0k/view?usp=sharing

    Not sure what to look for, there's a lot of information in those logs.

  127. nikfreak

    Browsed through your logs but can't really find anything that would give a hint regarding the bug. Might be a good idea to add some stubs to dm-spy-extra. But I can't give a recommendation about which to add (lens related ones probably). As stated above start with the StateTransition / TryPostEvent stubs. All of this is a lil' bit "time consuming" and might not really lead to a solution but searching of past committs in source I found a discussion between nanomad and 1% which might also lead to a solution as it is overlapping with the date this "shutter bug" was reported (read: not introduced?). Looks like EOSM used another boot method which required some changes to dualiso to work again. One theory: maybe the old boot method didn't contain the "shutter bug"???

    EDIT: signs of an old "boot method" seem to apply to older firmware which is a no-go.

  128. Matthias Bretz

    Maybe I am completely wrong with jet another idea of my brain (it goes ping-pong with ideas some times) but here is what I'm thinking about at the moment:

    Since all lenses affected by the shutterbug have IS and the IS is somehow "always" on at the EOSM it could be the camera (depending on the speed/size of the MBR of the card) not recognizing the IS-state while booting up. I just testet mounting the lens while the camera is booting and 10 out of 10 times this was a workaround for the shutterbug to. So maybe you look out for some IS-related stuff in the stubs?

  129. Daniel Fort

    Speaking of ping-pong, our posts are going between California and Germany so taking into the account the time difference we're working on this issue almost 24/7.

    As far as stubs, I read this post about finding stubs. I got as far as creating a ROM1.BIN.dis but I couldn't figure out how to find a stub for StartupCondition. I also tried comparing platform/EOSM.202/stubs.S with ROM1.BIN.dis but that lead to even more confusion. At one point I posted a link for my ROM1.BIN.dis but I also included the original ROM1.BIN which was a no-no. I'm not sure if it is ok to publicly share the disassembly but since we're on different time zones and I don't want to wait for an answer I'll PM Matthias Bretz and nikfreak a private link to it. Anyone else who wants it can PM me for the link.

    I did find a stub once that resolved an issue. Here's the pull request that was merged. That might have made Licaon Kter think I knew more than I really know, all I did was to steal that stub from 1%'s Tragic Lantern source. There's several other stubs in there but I'm not sure what they do or if any of them will help with the shutter-bug issue. Someone must have gone through those stubs when merging the Tragic Lantern fork into unified and had a reason to leave them out.

    That discussion between nanomad and 1% points to yet another piece of code to look into, src/state-object.c. The wiki page on StateObjects might point the way to changing the state of StartupCondition--maybe? Maybe not?

  130. Daniel Fort

    Matthias Bretz I was thinking about what you were saying about lenses. [mounting the lens while the camera is booting and 10 out of 10 times this was a workaround for the shutterbug] Mounting the lens while booting might be the same as breaking the lens/camera connection once the camera is on. Try this, go to the Firmware update section of the Canon menu where you can see the firmware version of your lens. Now unmount the lens--notice that the menu pops back a level. As for [IS is somehow "always" on] the exception may be the 11-22mm when it is in the collapsed position. Again, go to the same Firmware update menu, switch between the collapsed and the extended positions--notice that this time the menu doesn't change. I also mentioned in a previous post that the first time that the camera is started with the 11-22mm lens in the collapsed position it doesn't show the "Set the lens to the shooting position" warning. I'm not the first person to notice this. Anyway, this makes me suspect that the lens firmware is somehow not loaded properly when Magic Lantern boots.

    By the way, you can turn off the Image Stabilizer from the second camera icon in the Canon menu but that doesn't turn off the shutter-bug.

    Back to your [mounting the lens while the camera is booting] workaround. Have you noticed a difference in StartupCondition? My bet is that it doesn't matter what the StartupCondition is/was because when you break the lens/camera connection the lens firmware is reloaded--or at least that's what I'm assuming is going on.

    As far as [look out for some IS-related stuff in the stubs] there doesn't seem to be anything for that in stubs.S. Maybe we can find something in the disassembly files and create a new stub?

  131. nikfreak

    Let me ping pong one in: Does EOS-M have the "Force Liveview" option in menu? Can you check it and what happens when you change the menu option...

  132. Daniel Fort

    I'm starting to check older builds to see if I can find when the shutter-bug first appeared. Here's the earliest Tragic Lantern nightly build. On the same card that always shows the shutter-bug, this build will work on every other power on. Yeah, weird and not very useful without the source code. In addition, this is early work on an unsupported branch.

    [EDIT - found the earliest EOSM.202 build on bitbucket.org. It also exhibits the shutter-bug most of the time so this is an issue that goes way back to 2013-08-04, the beginning of time for ML on EOS-M (v2.0.2).]

  133. Jimmie Tauriainen

    Yes, it's not a regression. Its been there all the time with all ML builds for 202.Can't comment the older firmware since I didn't even attempt it or the camera at that time due its slow AF.

    Also the boot method wasnt doing any bad, my feel was that I had a higher bug rate with those older bugs than after the boot method was switched. I've no stats just by the feel, sijce shjtter bug has always been random for me. (I mostly use 11-22mm only).

  134. Matthias Bretz

    I didn't managed to get my virtual box to work so I could compile the source code for my self today. But a question before I go to bed. Is it possible to display the values of the lens_info (defined in lens.h) on the screen or write them in a log?

  135. Daniel Fort

    Yes, that information is displayed on the screen. For the DOF info you need to go to the ML menu between the front and back camera icons. (Don't know what to call that icon.)

    By the way, lens_info and prop_lv_lens are items that show up on the disassembly file.

    Jimmie Tauriainen The Canon 11-22mm is also my favorite lens. It just happens to be the easiest to use when the shutter-bug shows up, simply collapse then extend the lens.

  136. Daniel Fort

    I just came up with something that might be significant. There are several difference between the log files for a normal power on and the Matthias Bretz Play-Button-Power-Button workaround so I made a diff comparing a normal startup with the Play-Button-Power-Button workaround. Note that at the very end there is something that only appears on the Play-Button-Power-Button workaround:

       Startup:ff0c4d7c:8b:05: startupPrepareDevelop
       Startup:ff0c4da4:8b:05: Set_AVS 60
       Startup:ff135dcc:00:03: SVT step=0 HVT step=0
    FrontShtDe:ff15e22c:96:02: Init
    DianaFront:ff171b58:bb:02: Init
    RearShtDev:ff15be34:97:02: Init
    DianaRearS:ff16baf
    

    Perhaps Matthias Bretz discovered an undocumented key combination used by Canon developers or service technicians. I don't know what to make of this but it looks like it is running some extra startup code at the end of the boot process. Maybe re-loading the lens firmware? Here's what's in the disassembly:

    [EDIT: Oops--showed some Canon code. DELETED]

    My feeling is that "StartupCondition" may just be reporting something while "startupPrepareDevelop" is actually running some sort of initialization process.

    I'm struggling to figure out how to find a stub, test it and use it. There is no stub that I could find in the EOSM (or any other platform) to do something like re-load the lens firmware or setting the StartupCondition.

  137. Rob G

    Great to see this is getting so much attention now, thanks for taking it on. I read every e-mail that comes in but I definitely should be putting more effort into the investigation process. I'm more a general hacker than a developer but I'll look at getting the tool chains set up and see if I can contribute anything useful.

    P.S. the Play-Power workaround was discovered by myself!

  138. Daniel Fort

    Ah yes, credit where credit is due. As you can see the Play-Power workaround has created some very interesting logs that might point the way to a solution to the shutter-bug.

    I tried creating a stub for "startupPrepareDevelop" and called it from several places in boot-hack.c with results varying from camera freezes to no effect at all and some rather interesting error messages in-between the two extremes.

  139. Daniel Fort

    Something new to report. Using the dm-spy DebugMsgLog from the dmspy-70D-new branch I was able to consistently get these PtpDps messages when twisting an EF-M lens off then back on--one of the shutter-bug workarounds. If logging is started with the lens off then attaching the lens or with the lens attached then detaching the lens it will not create PtpDps messages. Collapsing and extending the 11-22mm lens (another workaround) won't create these messages either.

        PtpDps:ff0ffe54:33:01: Dispatch : Cur = 0, Event = 9, Param = 0x0
        PtpDps:ff292d3c:33:01: ptpPropertyChangeEvent[80030011][1f][0][0]
        PtpDps:ff2838c8:32:01: GetConnectSessionFirst end[0][3]
        PtpDps:ff29e648:33:01: PROP:0x80030011,0
        PtpDps:ff29f89c:33:01: PROP_LENS (Exist) [d1a8][80030011]
        PtpDps:ff2838c8:32:01: GetConnectSessionFirst end[0][3]
        PtpDps:ff283abc:32:01: GetConnectSessionHandle 1 err[0][0]
        PtpDps:ff2838c8:32:01: GetConnectSessionFirst end[0][3]
        PtpDps:ff283abc:32:01: GetConnectSessionHandle 1 err[0][0]
        PtpDps:ff29d440:33:01: ptpGetPropEvent FAILED! [d1a8][0]
        PtpDps:ff29f8d8:33:01: PROP_LENS (Extender Type) [d198][80030011]
        PtpDps:ff2838c8:32:01: GetConnectSessionFirst end[0][3]
        PtpDps:ff283abc:32:01: GetConnectSessionHandle 1 err[0][0]
        PtpDps:ff2838c8:32:01: GetConnectSessionFirst end[0][3]
        PtpDps:ff283abc:32:01: GetConnectSessionHandle 1 err[0][0]
        PtpDps:ff29d440:33:01: ptpGetPropEvent FAILED! [d198][0]
        PtpDps:ff2838c8:32:01: GetConnectSessionFirst end[0][3]
    
    --- this loops several times ---
    
        PtpDps:ff2838c8:32:01: GetConnectSessionFirst end[0][3]
        PtpDps:ff29e648:33:01: PROP:0x80030021,4d2d4600
        PtpDps:ff2838c8:32:01: GetConnectSessionFirst end[0][3]
        PtpDps:ff283abc:32:01: GetConnectSessionHandle 1 err[0][0]
        PtpDps:ff2838c8:32:01: GetConnectSessionFirst end[0][3]
        PtpDps:ff283abc:32:01: GetConnectSessionHandle 1 err[0][0]
        PtpDps:ff29d440:33:01: ptpGetPropEvent FAILED! [d1d8][0]
        PtpDps:ff0ffe54:33:01: Dispatch : Cur = 0, Event = 49, Param = 0x0
        PtpDps:ff1da818:9f:03: ChangParam [80000043]
        PtpDps:ff0ffe54:33:01: Dispatch : Cur = 0, Event = 49, Param = 0x0
        PtpDps:ff1da818:9f:03: ChangParam [8000002d]
        PtpDps:ff0ffe54:33:01: Dispatch : Cur = 0, Event = 49, Param = 0x0
        PtpDps:ff1da818:9f:03: ChangParam [80000036]
    

    It looks like the code that it is running starts here:

    [EDIT -- I took out this part because it is showing Canon code. Better self-censorship than having someone else do it! PM me if you want more information. BTW the code starts at around ff0ffdf0.]

    I'm not really sure what to do with this information. A re-read of the previous comments points to a similar issue with the 7D so maybe calling the *"Dispatch : Cur = %d, Event = %d, Param = %#x" function with Cur = 0, Event = 9, Param = 0x0 from reboot.c is worth a try? Uh--what address do you use and how do you code that?

  140. nikfreak

    Ok another tool to use as I am using it (adtg_gui) atm. Compile a nightly for EOSM and enable GDB in makefile.user.default. In case you might get compile errors with any of the tools below add asm.o in makefile.setup in your platform dir. Personally I am using the adtg_gui from iso-research branch by simply copying all contents of the dir into unified's adtg_gui dir. Then, add adtg_gui to makefile.modules.default and compile + use the build / module (=activate in debug menu -> ADTG_register). Set the ADTG_register submenu option to everything and simulate the bug by normally powering it on and trying to find the register which changes after removing and re-attaching the lens.

    Hint: Seen a pre-compiled adtg_gui.mo on forums so search for it if it's hard task to compile yourself. There's another submenu called "Advanced" which enables more registers (digic registers). Take a look at adtg_gui.c and add the engio stubs for eosm for being able to use this, too.

    Level of difficulty for finding a solution with adtg_gui: probably hard due to the amount of registers being involved and shown and none of the registers might be involved to the bug. You might think you found a possible register but it might be one of dozens which changed and be unrelated.

    Other tool with easy level of difficulty which you can enable by same instructions above (read carefully again): mem_spy

    And another tool with which I would personally start first with: prop_spy

    For prop_spy take a look at my dmspy branch you already know and do find and add these for EOSM (read: find for EOSM don't copy paste - its for 70D):

    https://bitbucket.org/nikfreak/magic-lantern/commits/0e832f1e58ab

    Then in debug.c #define CONFIG_DEBUGMSG and replace all 6 occurrences of "if CONFIG_DEBUGMSG" by "#ifdef CONFIG_DEBUGMSG".

    Right afterwards compile the build and use prop_spy in debug menu and simulate the bug in hopes prop_spy being active while and after swapping lens (unsure about this - never tried) and showing the property or properties which might have changed showing the new value. Personally I guess it's something around / about PROP_LENS (80030011) but who knows there will be several props changing but unsure which might be involved regarding the bug (check property.h for known props)...

    That's all I can add atm to the topic and should suffice to rub some of your time cause I got the feeling you won't really give up until this one is solved ;-D

    Disclaimer: i don't claim you might find a solution to the bug by using tools above. Do what you want with and to your device. Don't blame me for anything you do to your device ;-D

  141. Daniel Fort

    Wow, thank you so much for the detailed instructions. Looks like I got my work cut out for me.

    I'm going to keep working on this though I might not always have as much time as I had these past few weeks. Got a trip coming up and so wanted to get the shutter-bug squished before that but no big deal because I've got some cards that don't exhibit the bug.

    Notice I've been taking out all traces of Canon code from my posts?

  142. Daniel Fort

    Got through the first part of nikfreak instructions and adtg_gui is up and running. The first compile went flawless but when I got to these instructions: "Take a look at adtg_gui.c and add the engio stubs for eosm for being able to use this, too." there was a problem. Here's what I did:

        else if (is_camera("EOSM", "2.0.2")) // from 1%
        {
            ADTG_WRITE_FUNC = 0x2986C;
            CMOS_WRITE_FUNC = 0x2998C;
            ENG_DRV_OUT_FUNC = 0xFF2C1694;  // from stubs - added as per nikfreak
         // ENGIO_WRITE_FUNC = 0xFF2C19AC;  // from stubs - won’t start ADTG Registers
        }
    

    It complied alright but turning on "ADTG Registers" with the ENGIO_WRITE_FUNC turned on would lock up the camera. Maybe the stub has the wrong address?

    /** Engio **/
    NSTUB(0xFF2C1694, _EngDrvOut)                               // AJ_EngDrvOut_1xVar_to_ShadowStruct
    NSTUB(0xFF2C19AC, _engio_write)
    NSTUB(0xFF2C1730,  shamem_read)                             // AJ_0x8FB0_engio_struct_n_R0_manipulation_to_get_ptr
    // NSTUB(    ???,  EngDrvOut)                               /* present on 7D_MASTER.203 */
    

    Note that I couldn't find anything related to "shamem_read" in adtg_gui.c so I left that one out.

    Once it was working I got some log files before and after lens twists and compared them. The main difference seemed to be in the order that the registers were logged. At first I thought that the registers were randomly logged but it turned out that is not the case. In order to be through I ran several tests and even tried twisting the lens before and after starting "ADTG Registers" but it always came up in the same order. Sure, there were some address that changed but that's what jumped out at me.

    My logs are located here.

    If anyone dares to try my EOSM.202 build of dmspy-70D-new with the iso-research you can get it here.

  143. Michael Wilson

    Not sure if this helps, but I noticed this when removing ML, due to the shutter bug issue. I had been using ML on my EOS-M with an old manual Nikon lens, with no problems for a few months. Purchased an EF-M 18-55 IS STM and like others, as soon as I put it on the shutter bug appeared. I decided to remove ML in the meantime so I could get on with using the camera. Here's the possibly interesting bit: 1. Formatted the SD card, as per the FAQ in uninstalling (use SDFormatter.app on OS X) - used the "Quick Format" option (Transcend 32GB card). 2. Put card into camera. ML doesn't start, but the shutter bug was still there. 3. Formatted the SD card again, but this time used the "Overwrite Format" option, which effectively zeros out the card. 4. Put card into camera - shutterbug gone. I wonder, does this mean that even though I "quick formatted" the card, the 'boot loader' still ran but didn't start ML? i.e. only when I overwrote the card did the boot loader not run. Could the problem be in the boot loader? Apologies I am not familiar with the ML architecture, but it just seemed to me that if the problem is still there when ML is not running, then is it something before ML runs? Hope this helps, Cheers, Mike.

  144. Daniel Fort

    Hi Michael Wilson I also ran into a situation where the shutter-bug was present without ML running. Here's that note so you don't have to search through a bunch of posts:

    [I just found out that I can reproduce the shutter-bug without loading ML. All that is needed is to have the camera boot flag enabled. Again this isn't 100% reproducible but it did happen when powering up the camera with both the 11-22mm lens in the extended position and with the 18-55mm lens.]

    So yes, it does seem that the shutter-bug is something to do with having both the camera boot flag set and a bootable card but deleting the autoexec.bin is also a combination that can result in a camera that refuses to start. In fact I just tried "Quick Format" with the SDFormatter.app on OS X and the camera would not startup. However, turning on the "Logical Address Adjustment" option with "Quick Format" allowed the camera to start up without the shutter-bug.

    I'm not a developer or an engineer but it seems to me that maybe the shutter-bug happens when the battery/SD card access door is closed (note the activity light light up when you insert a bootable card) which is one of the reasons why this is so difficult to figure out. [EDIT - On second thought, never mind that comment because the shutter-bug re-appears whenever the camera is power cycled.]

    Of course the goal is to find a solution that will kill the bug on boot up so we won't have to use awkward workarounds or settle on recommending just the few cards that don't exhibit the shutter-bug.

    [EDIT - BTW, your comments do help.]

  145. Daniel Fort

    nikfreak I got mem_spy working, though I'm not sure how to work it yet. For testers brave enough to try it out but can't compile ML yet, here you go.

    I am stuck trying to get prop_spy working. In your instructions you pointed out a line you hard coded in debug.c. I made a slight change for portability but I'm stuck--what function are you calling and how do I find the EOSM address for it?

    #if defined(CONFIG_70D)
        static void *(*_prop_cleanup)(void *token, int property) = (void *) 0xFF12B15C;
    #elseif defined(CONFIG_EOSM)
        static void *(*_prop_cleanup)(void *token, int property) = (void *) 0xFF12B15C; //find EOSM address
    #endif
    

    BTW--searching the disassembly I came across something that might be promising, "PROP_Request PROP_REBOOT" It might be worth a try putting it where the 7D fix was made but how to code it? It doesn't seem to require any arguments (parameters? I don't really know how to code, I just follow instructions.)

  146. Daniel Fort

    Doh! I'm sure I searched the EOSM stub.S file but there it is. Stubs are still a mystery to me--can't figure out how anyone was able to find some of them.

    I am having problems compiling. Switching the 6 "if CONFIG_DEBUGMSG" to "#ifdef CONFIG_DEBUGMSG" causes this error:

    ../../src/debug.c: In function 'debug_property_handler':
    ../../src/debug.c:3298:5: error: implicit declaration of function '_prop_cleanup' [-Werror=implicit-function-declaration]
         return (void*)_prop_cleanup( debug_token, property );
         ^
    

    Your instructions are to add #define CONFIG_DEBUGMSG in debug.c, which I did. I also tried putting it in debug.h, uncommenting it in config-defines.h and turning it on in Makefile.user but nothing worked. BTW--assume it needs to be assigned a value of 1?

    Of course prop_spy doesn't show up on the debug menu. I feel I'm missing something, like maybe a module named prop_spy? There doesn't seem to be anything in the ML code.

  147. nikfreak

    don't touch makefile.user. Do it like it have written. re-read maybe again and don't forget to run a "make clean" after modifying source code.

    Btw: You may take a break here and leave a note. I can compile for you in the evening (GMT+1) and share the link.

  148. Daniel Fort

    Got it to compile. I was using some other instructions on how to build ML that said to copy Makefile.user.default to Makefile.user and make any modifications on Makefile.user and don't touch Makefile.user.default. Guess that's where I messed up--listen to just one expert at a time!

    I can now see "Spy properties" in the Debug menu. Turning it on will show the properties on the screen for a second or so then the camera freezes. Am I doing something wrong or maybe it didn't compile properly?

    VRAM2.jpg

    Thanks for your guidance and your time--I didn't mean to drag you away from your work on the 70D port.

  149. Licaon Kter

    nikfreak: Maybe better open a forum thread though, I feel that given so much is not known about these things that having a discussion stuck/lost on IRC is worse. This knowledge is split in so many parts Wiki/forum/individual experience that having a conversation that acts as a guide on how to troubleshoot helps current and future ports. :D

  150. Daniel Fort

    Of course searching the forum for information is barrel o' fun--or a barrel of monkeys at times.

    Anyway--back on topic.

    Hopefully the tools that nikfreak helped compile for the EOSM will lead to a solution for the shutter-bug issue. I posted links to the debug builds in the previous posts for testers who enjoy abuse--I mean are willing to take on a challenge.

    "Spy properties" looked very promising but it crashes the EOSM. Here is a post about it crashing the 70D. I agree with Licaon Kter that there should be a separate developer's topic to deal with it. I'm focusing my efforts on the shutter-bug until it is squished or I give up in total frustration. (Or my wife complains that I spend more time with the shutter-bug than with her.)

  151. Daniel Fort

    Wow--found what may be the first report of the shutter-bug: Reply #99 on: December 15, 2012 on the EOSM ** Alpha 1 topic.

    So this bug has been around for a long time. Re-reading the posts on this issue shows some suggestions but few posts on what was tried and failed. Following a1ex's 7D fix in reboot.c here's what I have tried and obviously failed. One at a time of course.

        #if defined(CONFIG_7D)
            *(volatile int*)0xC0A00024 = 0x80000010; // send SSTAT for master processor, so it is in right state for rebooting
        #endif 
    
        #if defined(CONFIG_EOSM) // ChangParam to squash shutter-bug
            // *(volatile int*)0xffb823cc; // *(volatile int*)0xFF1DAB00 = 0x80000004; //sometimes skips this
            // *(volatile int*)0xffb82420; // *(volatile int*)0xFF1DAB00 = 0x80030011; //often runs this one twice
            // *(volatile int*)0xffb82420; // *(volatile int*)0xFF1DAB00 = 0x80030011; //22mm lens only does this once
            // *(volatile int*)0xffb82ab0; // *(volatile int*)0xFF1DAB00 = 0x80000043; //sometimes skips this
            // *(volatile int*)0xffb822d0; // *(volatile int*)0xFF1DAB00 = 0x8000002d;
            // *(volatile int*)0xffb82768; // *(volatile int*)0xFF1DAB00 = 0x80000036;
    
            // *(volatile int*)0xFF0C5024; // startupPrepareDevelop
    
            // *(volatile int*)0xFF23D1F0 = 4,0; // StartupCondition
    
            // Maybe try it this way?
            // void (*myfunc)(int, double);
            // myfunc = ( void (*)(int, double) )0xADD12355;  //my leet version of address
            //( void (*)(int, double) )0xffb823cc;
    
            // Note that I found:
            //
            // #define myfunction    (*(void (*)(int i))0x08001234)
            // myfunction(3);   // This will call the function at absolute address 0x08001234
            // 
            // So maybe calling Dispatch with: Dispatch : Cur = %d, Event = %d, Param = %#x
            // 
            // #define Dispatch      (*(void (*)(int i))0xff0fffd0)
            // Dispatch(0);
            //
            // need to pass this information:
            // 
            // PtpDps:ff0ffe54:33:01: Dispatch : Cur = 0, Event = 9, Param = 0x0
    
            // *(volatile int*)0xFF1BDF80; // PROP_Request PROP_REBOOT
    
        #endif 
    

    Note: I know that some of this code is set up completely wrong but I wanted to document the various function address locations to try out.

  152. Alexander Guwa

    Hi guys! It seems I have fled the shutter bug. What I did: I thought logically - if the problem is in the card, it is necessary to allow "Release shutter without card - ON" from the menu. What I did. Now, the shutter is released (spit over your shoulder). Try it yourself. Sorry for the Google-translation !

  153. Daniel Fort

    Alexander Guwa Doesn't work for me either. Unless I take the card out. [EDIT: I always have Release shutter w/o lens - Enabled]

    One of the problems with the shutter-bug is that it sometimes comes and goes as if playing a "catch me if you can" game. I don't doubt that "Release shutter without card - ON" worked for you because it worked for me the first time I tried it--but that's the only time it worked.

    BTW--I've been experimenting with the lua branch and maybe someone can help come up with a script to track down some properties that seem to kill the shutter-bug? I'll see if I can post a lua build for EOS-M tomorrow after checking that it works properly and write up some instructions on how to use it.

  154. Daniel Fort

    Ok shutter-bug hunters, here's another tool. An EOS-M build of the lua branch with an added script for checking properties.

    Warning to Mac users (I'm one of them) something strange is going on with Google Drive and Dropbox that when downloading the .zip file on a Mac it does something to the file that affects the lua module. Good luck figuring that one out. I tested downloading on Windows and Linux and it works fine.

    Turn on the lua module, restart the camera and you'll see some error messages on the screen. Restart the camera and the messages should be gone.

    In the ML menu under the wrench icon all the way at the bottom you'll see "Mode display" this is a script that Licaon Kter wrote in order to solve another EOS-M issue. The script is located in ML/scripts and is named my_script.lua. Here's an explanation of what it does and how to modify it to look at other properties. I changed SHOOTING_MODE to LENS_NAME (and the lower case shooting_mode to lens_name for good measure) and whenever I mounted a lens the name of that lens showed up. I also tried LENS_SOMETHING which got me nowhere and LENS that got me some cryptic messages as the lens focused and did whatever else it was doing. Check out the ML lua documentation that David Milligan posted to see what other properties you can look into.

    You can only see a property when it changes so I'm not sure if this is the right tool to track down the shutter-bug but maybe someone has some ideas?

    In any case, lua is a way for users who don't have a development system but have some scripting skills to try things out. There is a switch that can be turned on in order to change properties but there are some stern warnings in the source code, like this one:

    // !!!DANGER WILL ROBINSON!!!
    //#define LUA_PROP_REQUEST_CHANGE
    

    I didn't turn that option on.

    I'll be on vacation for about a week (big sigh of relief from the watchers of this issue) happy shutter-bug hunting!

  155. Daniel Fort

    Just a quick update for Mac users.

    To deal with the dot underscore files that are causing issues on lua scripts simply run this command in the terminal:

    dot_clean -m /Volumes/EOS_DIGITAL
    

    If your SD card is named something different or for a typing sort cut type "dot_clean -m" then drop the icon of the SD card from your desktop into the terminal window to get the path and name of your card.

    I'm still not sure why this is only affecting zip files downloaded from a cloud drive.

  156. Daniel Fort

    David Milligan fixed the Mac "._" issue in this commit of the lua branch. I can provide a new build if anyone wants to play around with it but I'm doubting that this will bring us any closer to a resolution to the shutter-bug issue since it can only show properties as they change. Activating the option to modify properties is a bit risky but if anyone wants to build a lua script to change properties but can't compile ML send me a PM and I'll make a special build along with a warning - // !!!DANGER WILL ROBINSON!!!

    Right now I'm working on taking a look at the 7D fix Alex made in src/reboot.c and see if there is an EOSM equivalent that can be used. This has been mentioned a few times before--has anyone attempted it yet?

  157. fish boy

    Hi! I'm a new victim of this old bug. It's incredible that this bug has survived for such a long time. Is there a fix for the SD card? I tried formatting in windows, linux. I even trided to format the card with a "full overite" option in DSFormatter v4.0. Nothing seem to work on a Samsung 32GB Class 10 SDHC Pro Memory Card. However, I had a 60D with magic lantern installed on other cards. After formatting those cards it seems that the bug is not there. Strage. So, it must be the way that Canon M is formatting the card with ML-on it. Is there any way how to restore the card's previous settings, and wipe out the ML from card?

  158. Daniel Fort

    fish boy welcome to the Hurt Locker. The shutter-bug has shown up on all flavors and methods of SD card formatting. There are workarounds to kill the bug and once dead it won't come back until the next power cycle, which for EOSM users is rather frequent because of the short battery life. The goal should be to kill the bug on boot up no matter what card you are using.

  159. Photato

    Free from the Shutter Bug, 2 months and counting. What worked for me is a new microSD card from Samsung. It is the Samsung 32Gig Pro. BRand new I formated it with my PC using the standart Fat32, then I formated it Low Level with my EOS M. Then I copied the TL files that were in my old card. I also later copied ML into it and so far so good. So I think it might have something to do with the card. Perhaps there were older version of ML or CHDK that messed with the Secured sector? Dunno. But I am happy that it has been worked for me with my 2 IS M lenses.

  160. Jimmie Tauriainen

    Photato, your method may work for you but it's missing some ingredients, it's rather a work-around. Mainly your card is not a SDXC (64GB+) and it's a microSD which is most likely a slower card than fullsized SD version of it. Other work-around could be to use Sandisk branded SD cards as well.

    To summarize: Non-Sandisk + SDXC (64+GB) = High chances of shutter bug, no matter how you format it.

  161. Photato

    Jimmie my Samsung microSD 32gic speed is: Read: 90 MB/s Write: 80MB/s So I don't think s slow. I was just reporting what worked for me so it seems that some SD cards are not affected by the shutter bug.

  162. Licaon Kter

    Since EOS-M is limited to 40MB/s that's not a thing anyway, do test in ML benchmark ( start recording video, go to ML menu Debug ).

    Also, using a microSD card with an adaptor might add a layer of complexity to this.

  163. Photato

    Yes I know EOS M unfortunately is hardware limited to 40MB/S. Well, MicroSD is the new Normal. Super fast and easy to pics and videos to Mobile devices. So if a Universal fix is to be found it needs to apply to all kinds of SD cards. I think MicroSD is just a physically smaller SD card with the same SD pins. So is basically the same thing only smaller.

  164. cybertim

    I'm using a Transcend R95 W60MB/s SDXC I class 10 64GB card. Today I received my 18-55 kit lens (never owned one always used my trusty 22mm) and suddenly I have this 'shutterbug'. At least I found a solution WITHOUT removing the lens while the device is on, just go to Menu->Settings(3)->Sensor Cleaning->Clean Now You hear the shutter clap and suddenly you can make photos again :)

    I Already tried formatting the card FAT on a Mac, low formatting in the device..etc..etc.. different versions of Tragic and Magic lantern, nothing helps, always have to clean the sensor before shooting.

    So, is it possible, as a workaround, to trigger the sensorcleaning on startup instead of the build-in feature to run it on shutdown?

  165. Peter Scargill

    Now that didn’t work for me. I pulled my (bog standard lense) camera out of the cupboard. It was set on manual - so the menu was actually something like menu item 8, not 3 – however – I did the CLEAN NOW, a couple of seconds later I heard the shutter clap… and… back to taking a picture… STILL won’t take a picture.

    So I switched the camera to auto – still around menu item 8 – cleaned – heard the click etc… back to taking a pic – button still would not work. Turned the camera off and on as usual – works perfectly.

    I was getting excited there…

    Pete.

  166. cybertim

    I'm currently using the 'latest' tragic lantern (http://tl.bot-fly.com Dec19) and this 'trick' works for me everytime. Later today I will try it with the latest working build from http://magiclantern.fm so we know this isn't related to a specific build.

    Tried it with Build Date: 2015-04-19 00:08:06 +0200. edit; it doesnt work as stable as with the tragic, it doesn't always work..

    ps. This was also tested on my other 'nameless' SDHC card class 10 16GB. (which also has the shutterbug only with the 18-55 lens, so for me its more lens related).

  167. Daniel Fort

    Tried your workaround but it doesn't work with a version that incorporates the latest pull requests (after 2015-04-19).

    Note that with some cards the shutter-bug is intermittent so what you are experiencing with the Tragic Lantern build being more stable might be a matter of chance.

  168. cybertim

    I must agree now, did some more testing and the results are quite random to say the least.

    16GB SDHC: TL, worked 2 times (out of ~7); installed ML, worked 1 time (out of ~10) 64GB SDXC: TL, worked all the time (~20); installed ML, did not work (~5); installed TL, didn't work anymore.. (~20)

    Too bad..

  169. Douglas Blood

    I know people have tried with multiple SD cards, but has anyone tried with a second EOS-M camera? I can't replicate the issue with my cards, but would be interested in testing out with someone else's cards that exhibit the problem, and having them try with my cards that don't. This could highlight camera settings or other possible avenues to look at for why the problem exists, and possible work arounds. I have all 4 lenses and have never seen the issue with my setup (most of the time I use a SanDisk microSD Extreme). I'm traveling around Europe (heading northish from Italy) so can pop into quite a few cities over the next couple weeks if someone who has the issue would be interested in meeting in a cafe for an hour to do some testing.

  170. Daniel Fort

    Hi Douglas Blood those SanDisk microSD Extreme cards are probably pretty much the same as regular (non-micro) SanDisk Extreme cards that do not exhibit the shutter-bug--assuming they are >32GB. The shutter-bug has been reported on pretty much any card 64GB and over. Of course there are many other cards that exhibit the shutter-bug either consistently or intermittently.

    Only the 22mm is shutter-bug free but all the EF-M zooms, including the Tamron 18-200mm EF-M, have the shutter-bug with certain cards.

    I have 3 bodies, have tried all sorts of settings and can get consistent results across all 3 bodies.

    Of course it would be great to resolve this issue in a European cafe in an hour--though you might as well meet in an Amsterdam coffee shop when you're dealing with this bug.

  171. Anton Petukhov

    a shutter bug seems more or less clear. and who knows, there is some information that will be even updatings on the EOS-M or already all over? (2015Apr19) it would be possible to make a LOG-C with mov-video, as an alternative to video RAW. because the EOS-M writes a maximum of 40 megabits per second. and problems with shutter. I apologize for the Google translation)))

  172. Daniel Fort

    Shutter-bug is still an unresolved issue. We haven't given up yet.

    EOSM development, and Magic Lantern development in general is still going on--it is just that an issue was discovered back in April so the platform was intentionally halted from nightly builds. The issue was eventually fixed but the main developer has been away for a while so it hasn't been merged in yet.

    A discussion on LOG-C is off topic here but basically the H.264 codec isn't suitable for logarithmic color space. You need to shoot raw video in camera and convert to log in post. The EOSM as well as other cameras with similar write speeds can shoot raw (mlv) video, you just have to limit your frame size. However, none of this has anything to do with the shutter-bug.

    The shutter-bug only affects shooting stills with EF-M zoom lenses.

    Note that you can post in your native language if you like.

  173. Anton Petukhov

    Привет. почему то закрытый форум на ЕОС-М. плохо еще тут ориентируюсь. Можете посоветовать форум по этой теме. Наткнулся на интересный момент, в RAWвидео максимальная скорость записи 40мб/с а MOV x3, скорость потока доходит до 150мб/с. почему так?) или я что то не понимаю?) И еще. DNG файлы после конвертации с компрессией из MLV занимают в 2 раза меньше места на диске с той же битностью, Не знаю всех тонкостей.... но попробую предположить что если бы камера сама могла сжимать DNG файлы при записи то это дало бы больше возможностей по разрешению картинки.

    или подскажите форум по этой теме.

    Hi. why is a closed forum on the EOS-M. bad even then I guided. Can you recommend a forum on this topic. Came across an interesting point in RAWvideo maximum writing speed 40MB / s and MOV x3, the flow rate reaches 150MB / s. why?) or I do not understand?) And further. DNG files after conversion compression of MLV take 2 times less space with the same bit depth, I do not know all the details. I'm not a programmer ... but I'll try to assume that if the camera itself can compress DNG files when this would give more options for the resolution of the image.

    or prompt a forum on this topic.

    I apologize for Google translator))2015-09-24 09-57-32 Свойства  tom fujik 2015-09-23 23-36-55 eosm .png

  174. Mat Bennett

    Hi all, been using ml for a while now. the only way i can get rid of the bug is releasing the lens , not completely as don't want to expose sensor to dust just enough to release contact and this seems to work, is there a chance that ml is somehow messing with canon software pin-out? i have release shutter without lens activated in c functions, what if there was a code in ml for the same .....just a thought

  175. Daniel Fort

    Mat Bennett could you be a little more specific? Releasing the shutter without a lens isn't the problem. The issue is that in certain situations the shutter will not fire when an EF-M zoom lenses is mounted. There has even been an issue reported when one zoom exhibits the shutter-bug while another doesn't. If there was a way to fire the shutter while the shutter-bug is active please elaborate. The solution seems to be to somehow remount the lens via software or set a startup condition that avoids the shutterbug, (Play-Button-Power-Button combination to bring up StartupCondition : 4, 0) but nobody has come up with a way to do that yet.

  176. Anton Petukhov

    интересно. что правдо если отключить контакты обьектива. на програмном уровне. что будет? правда диафрагма будет открыта постоянно.

    interesting. What is true if you disable contacts Lenses. on the software level. What will happen? although the diaphragm will be open continuously.

  177. Anton Petukhov

    у меня очень редко появляется ошибка затвора. но я снимаю и фотографирую в мануальном режиме. кто-нибудь анализировал вероятность возникновения ошибки, с автофокусом и без? стабилизатором и без?

    I very rarely get an error shutter. but I shoot in manual mode. anyone analyzed the likelihood of errors, with and without autofocus? stabilizer and without?

    ef-m 18-55is. sandisk 64g 95mb/s, 45mb/s

  178. Anton Petukhov

    можно было бы тогда дать время прогрузится МЛ и потом подключать объектив через какое то время. меня больше огорчает отсутствие обнавленей пусть даже с ошибкой(((

    It could then give time progruz ML and then connect the lens after a while. I was more upset absence of updatings even with an error (((

  179. Daniel Fort

    Anton Petukhov Yes, it has been a long time since the EOSM got a nightly build. There's a reason for that, there is a problem that the lead developer wants to make sure is resolved before allowing any more automatic builds. If you want to try a newer version than what is on the nightly builds remember that this is an open source project so users can either compile their own ML builds or ask someone in the community to build a version for them.

    Back to the issue of this discussion--look through the code and see if you can come up with an idea how to solve the shutter-bug. To unmount and remount the lens in software you'll probably have to disassemble the camera firmware and figure out how that works. I have also posted several ML testing builds to help debug this issue--just look back through my previous posts. For example on 2015-08-05 I posted an EOSM lua enabled build.

  180. Anton Petukhov

    сейчас наверно опять скажу какуюнибудь глупость)) спецально взял самую медленную карту, чтоб вызвать ошибку затвора. пробовали отключить и включить объектив? и сразу все работает. или это уже тоже было?)) извиняюсь за гугль перевод)) http://youtu.be/4fb5gu9QSeo

    Now perhaps again I tell what something stupid)) specifically took the slowest card to trigger the shutter bug. tried to disable and enable the lens? and once everything works. or is it too was?)) sorry for the Google translation))

    http://youtu.be/4fb5gu9QSeo

  181. Daniel Fort

    Thanks for sharing that video. Here's one that was done a couple of years ago.

    https://youtu.be/jc8Zo-VMUkU

    There is one more workaround that was discovered by Rob G

    "If I briefly press the image review ("Play") button so that the orange LED lights, then press the power button, the camera starts up without the shutter bug. It's similar to doing a quick power cycle of the camera as described earlier in the thread I think."

    I have already done a test with various cards and surprisingly the slowest card that I could find did not exhibit the shutter-bug so there is more to it than simply the speed of the card. In addition it seems that cards over 32GB, even very fast cards, are more susceptible to the bug.

    This may sound like a broken record but the "real" fix should be done in the Magic Lantern startup process so every lens and card that works without Magic Lantern will also work with Magic Lantern.

  182. Anton Petukhov

    а) простите)) печально((( про кнопку плей читал да. а про объектив видимо пропустил. печально что просто нельзя перезагрузить обьектив на програмном уровне после загрузки МЛ. у меня сандиск 64 работает прекрасно. спасибо за исчерпывающую информацию) похоже вы уже тут все перепробовали)) удачи вам и спасибо!! отличная прошивка!! буду ждать

    a) sorry)) sad ((( I read about the play button, yes. and about the lens apparently missed. sadly just can not restart on the lens of the level of software after downloading the ML. I have a SanDisk 64 works perfectly. Thank you for detailed information) looks like you've tried everything)) Good luck and thank you !! firmware excellent !! I will wait

  183. Daniel Fort

    Don't wait for someone to fix it--

    Арте́льный горшо́к гу́ще кипи́т.

    Took that off of a Russian proverbs web page:

    • It may be easy to complete a simple task on your own. But when you undertake a complex assignment it's hard to manage it without a helper. That is the reason why Russians commonly say that "Артельный горшок гуще кипит".

    Literal translation: An artel's pot boils denser.

  184. Anton Petukhov

    а перепрошить объекти поменять прошивку объектива? тоже уже были идеи?

    change the firmware of the lens? also already had ideas?

  185. Daniel Fort

    I don't think anyone has though of changing the lens firmware. Seems like a lot of work and you would have to do it for each lens that exhibits the shutter-bug.

    Just for the record, here are the current firmware versions of the various EF-M lenses:

    • Canon 22mm - 1.8.0 (no shutter-bug)
    • Canon 18-55mm - 2.0.0
    • Canon 11-22mm - 1.0.0
    • Canon 55-200mm - 1.0.4
    • Tamron 18-200mm - 1.2.9
  186. Janke
    • Canon 55-200mm - (could someone check the firmware version on this lens?)

    Mine is 1.0.4 - bought in January this year.

    Best regards,

    Janke

  187. Jim VanPetten

    Guys, i hope this doesnt sound stupid. I'm brand new here but had no shutter on my first try. I went to the eos-m firmware, custom functions menu C.Fn.7 release shutter without lens and it worked.

    I just downloaded Daniel Forts latest (hg clone -r EOSM__working https://bitbucket.org/daniel_fort/magic-lantern). I am a c programmer with 15 years but only have done web apps. I plan on becoming a contributing member of the community as i have just successfully shot ENG b4 lens with ML and the results were amazing. I now can use my old ENG lens, servo zoom, remote focus 19x fuji A19 lens and my old Canon J's just like old times!!!

    I'm at 1080 .h254 and would like very much to optimize raw. Thinking the eos-m3 may be necessary due to read/write speed. Dont know, but if we can get bitrate 2.5 and raw and explore this, sky is the limit. I'm also shooting my old FD lenses which are turning out amazing. 50/1.4 24/1.4. I have a 24-105 fixed 2.8 i cant wait to try (70-300 2.8!!!)

  188. Daniel Fort

    Jim VanPetten Welcome! We could use a C programmer with an EOSM. What you seemed to have experienced was what happens when you use a lens that doesn't communicate with the camera's electronics. The shutter-bug only happens with EF-M zoom lenses in still photo mode.

    What timing--I was just tinkering with trying to get video hacks working. Please check out the EOSM camera specific topic at:

    http://magiclantern.fm/forum/index.php?topic=9741.msg156598#msg156598

    Let's keep this bitbucket issue just for the shutter-bug.

  189. Alex

    Here's a different kind of minimal autoexec: it attempts to start the main firmware by re-running the bootloader. This is an older experiment by g3gg0, but I thought there's no harm in trying it again.

    autoexec.bin

    It should start plain Canon firmware. Can you reproduce the shutter bug with it?

  190. Daniel Fort

    Of course this would come up on a week when I'm away from home and without lenses that trigger the shutter-bug. Is this the same test that was done way back on September 24, 2013? http://www.magiclantern.fm/forum/index.php?topic=8347.msg78288#msg78288

    Alex I know that I made a lot of noise on this issue and haven't come up with a solution but this comment seems to be as close as I have ever come to figuring this thing out: https://bitbucket.org/hudson/magic-lantern/issues/1893/eos-m-shutter-bug#comment-20434355

    I haven't given up on it. In fact posting those tutorials for building development machines were a part of my master plan to build an army of EOSM super users who would chip away on the shutter-bug but so far it has been working more like the infinite monkey theorem.

  191. Alex

    It's not the same test, but a similar one. The test in the forum is a minimal autoexec that jumps to Canon firmware (the way we start Canon firmware on all other cameras). The new one patches the bootloader with cache hacks, so it no longer checks for autoexec.bin, and re-executes the bootloader.

  192. Alexander Guwa

    Hi, guys! I want to express the opinion on a shutter bug. After turning "on" process of loading during which there is an appeal to ROM, a memory card with ML and to lens ROM begins. At the "correct" sequence of loading of a shutter bug isn't present, at "the wrong" sequence loadings the shutter bug appears. The second is most often shown. Manipulation with the play button sometimes puts loading "on the right track". That at the switched-on camera shutdown/connection of a lens solves shutter bug problem, allows to assume, what exactly the appeal to lens ROM occurs "not at that time and not in that place" or doesn't occur in general. Therefore the task consists in making algorithm of loading correct. Excuse me if you understood nothing.

  193. Photato

    This problem can be solved by getting a $9 memory card. I've been using my EOS M for 4 months now with a Samsung 32 Pro mSD card and no Shutter Bug so far. IMHO it is waste of time try to solve this issue which might not have a solution after all. I would rather focus resources in other aspects of ML. I propose for the creation of a List of bug free memory cards somewhere else. Lets move on ! :)

  194. Daniel Fort

    Photato It isn't a waste of time to have ML on the EOSM working properly no matter what SD card is used. I have not found any 64GB or larger card that is shutter-bug free so your card list is going to be very short. In addition, the shutter-bug is intermittent on some cards so what worked for one user won't necessarily work for all users. The only 100% reliable card that I found costs $30.

    Alexander Guwa There are several theories and opinions about the shutter-bug. If I understand what you are saying then you are on the same track that Alex is experimenting with.

    I will be able to run the test this weekend or maybe sooner if I can make it home but anyone interested in solving this issue should be able to run the test. Mount an EF-M zoom lens, put this autoexec.bin file on a card that exhibits the bug and report back.

  195. Daniel Fort

    Thought I'd pull out my shutter-bug testing setup and try it again.

    New (bleeding-edge/EOS-M/rerun-bootloader) autoexec.bin test results in flashing green LED, no ML boot or Canon menu. No battery pull required to shut off camera however switching to another card with a working autoexec.bin or card without ML or even no card at all requires battery pull to start up camera. (No start up condition is persistent.)

    Previous (bleeding-edge/EOS-M/minimal) autoexec.bin test results in camera turning on and Canon menu. No ML boot. No shutter-bug.

    The discussion for that previous test (EOS-M Alpha shutter-bug discussion) seemed like it went nowhere.

    Hope this gets us somewhere.

  196. Martin Nolan

    Hello, I tried many tricks to avoid shutter bug, but I stick with Sandisk 32GB SD card and everything is OK (55-200mm and 11-22mm without shutterbug). One time I got shutterbug again, I use 11-22mm lens and dont put it into the "ready to use" position. In normal display there was warning (something like: put lens into the working position), but in ML display there wasnt anything, But pressing shutter didnt work. So maybe this is the reason of shutter-bug. Because only new EF-M lenses have new feature of extending body before shot.

  197. Daniel Fort

    AFAIK only the Canon 11-22mm and the new Canon 15-45mm EF-M lenses have the collapsible feature. Without ML loaded if the lens is in the collapsed position when powering on there is an on screen message, "Set the lens to the shooting position" but with ML the message doesn't appear when powering on the camera. The message will appear if you extend then collapse the lens and that will also eliminate the shutter-bug. It seems that maybe there's a relationship here?

    BTW--noticed that there isn't a bug report for the collapsed lens warning message so I guess one should be opened.

  198. Martin Nolan

    my SD cadrds which dont produce shutter bug - SanDisk SDHC Ultra Class 10 UHS-I, 32GB (read speed 48 MB/s) - SanDisk SDHC Ultra Class 10 UHS-I, 32GB (read speed 40 MB/s)

    BUT - SanDisk SDHC Ultra Class 10 UHS-I, 32GB (read speed 80 MB/s) sometime have sutter bug

    maybe the reading speed is also important

  199. spe42

    So I've been experiencing the shutter bug recently, but it has brought up in the process of trying to fix it some other more perplexing problems.

    My main concern is that I can't get the camera to record video or photos after uninstalling magic lantern. That is to say, seemingly, the superficial symptoms of shutter bug have persisted in the camera despite having uninstalled Magic Lantern (i.e. in place of taking a photo, the display overlays flash off and back). i've reinstalled magic lantern at this point, and one additional thing I've noticed is that photos and the shutter button seemingly only work with full resolution silent picture enabled. When I switched the capture mode to simple or to slit-scan, a lua black box text display appears which flashes "preparing..." for a split second and doesn't take a picture. Similarly, without silent picture enabled, it won't take photos at all, even after resetting ML to standard settings. It's been very confusing to me that this should be the first thing to happen after reinstalling the software on the camera.

    The only thing which has occurred that has had a noticeable effect on the camera recently happened when I was freehanding a lens that my friend and I are trying to customize atm. What happened is the camera seems to have shorted or something by my accidentally touching the thread mount of the lens to the auto focus contacts on the EOSM, which happened at least twice, after which initial instance the camera stopped running the lua script log on startup. The camera produces an error message on startup whenever I made that mistake ("camera not shut down cleanly," I believe) however, all of the functions of ML seem to be loaded and functional on every bootup of the camera, sans the script overlay that runs when turning on the camera. After that first accident, I have noticed that the camera also has started making a hissing sound on startup and shut down, but still runs correctly, with the exception of the errors mentioned at the beginning of this message. Again, the main problem is that when I uninstalled ML I could no longer record video in video mode. When I re installed ML, I could record videos, but only by enabling the setting within the ML menu that links half shutter to record start in video mode. My friend has noticed some inconsistencies with the shutter speed. The shutter speed control does nothing.

  200. spe42

    That is to say, I'm not certain I'm experiencing the shutter bug issue. When I described what was going on with my camera to another user, they insisted that this was the case. All that I know for certain was described above. That said, I have not thus far experienced a locked shutter. All that I have experienced is an inability to take photos without silent picture enabled, and that after uninstalling ML these problems persisted, and I've demonstrated this to be the case at least twice now to my friend who is trying to help me figure out what's going on.

  201. Walter Schulz

    In other words: Try another card type. BTW: EOS M (and - at time of writing - no other ML enabled cam) doesn't support UHS-II. This card will switch in UHS-I mode and UHS-I write speed for this particular card is limited about 48 MByte/s.).

  202. Licaon Kter

    Fast but not Sandisk apparently.

    Also, since the EOS M camera is limited to <40Mb/s, any speed above that is useless in camera, might help when transferring files with the card reader maybe.

  203. Daniel Fort

    There's a pull request #792 for updating the EOS from Canon firmware version 2.0.2 to 2.0.3. Just checked for the shutter-bug and it is still present on the new firmware. Same workarounds as before, SanDisk Extreme card < 32MB, untwist lens, etc.

  204. Log in to comment