Identical SDXC Cards Boot ML and "Brick" the 700D

Issue #2556 closed
Former user created an issue

Here's a good brain teaser for you mates:

Two identical SDXC cards (Lexar Pro 128GB, R:150mb/s W:~43mb/s) produce drastically different results: one boots ML fine, while the other, even without ML loaded, will temporarily "brick" my T5i/700D. This "brickatose" state can be broken by quickly ejecting the battery, but if the bricking card is in the slot—no matter what data or lack of data it has—the camera will remain dead.

The only other difference between the two cards is one is painted red and the other blue. Red likes to play. Blue likes to kill.

It only seems related to ML because before I loaded ML onto Red, both cards worked fine. Something must have happened between then and now to make Blue the Cam Killer.

Comments (35)

  1. Eric J. Russell

    BLUE has been formatted in exFat/128, inserted into 700D both blank and with ML (supplemented with the EOS Card utility), neither work. RED's ML data has been copied straight over to it, but still soft-bricks the 700D, I believe the term is.

    As it stands, if BLUE is inserted in 700D, no matter what data or lack of data is has, the camera is effectively bricked.

  2. Walter Schulz

    Please follow instructions to the point:

    Format both cards using cardreader. If there is a firmware update available for your cardreader install it first. For each card repeat: Remove battery, remove card (if any). Insert battery. Insert card. Try to startup cam.

    (Technicians tend to hate the term "does not work" ...)

  3. Eric J. Russell

    Both cards formatted exFat/128.

    1) Removed battery, inserted battery, inserted RED, switched on 700D, Canon GUI.

    2) Removed battery, removed RED, inserted battery, inserted BLUE, switched on 700D: No lights, no response from 700D. Soft-bricked.

    Repeated step 1: Canon GUI.

  4. Walter Schulz

    Thanks! May I ask which cardreader model you're using? Are you able to test/format BLUE with another cardreader type? You may want to download F3 (OS X) or h2testw (Windows) and run it against BLUE. If card looks okay (will take some time to terminate) you have to contact Lexar Support. There had been issues with (older) EyeFi X2 cards showing same behauviour. EyeFi was unable to offer a solution for those cards. Newer cards seems to be compatible, though. First time I hear about UHS-II cards acting this way.

  5. Eric J. Russell

    It's an Ativa CR-45 USB 3.0 card reader. I also repeated the steps above in my old Inspiron 6000 laptop's SD card slot to no avail.

    H2Testw came back good.

    Looks like I'm calling Lexar.

    ô nô

  6. Walter Schulz

    Bugger! There is some information Lexar Support might find helpful (and I hope I got it right and a1ex doesn't have to correct me ... a lot).

    A ML enabled cam (= cam's "boot flag" enabled) will lookup for a bootable card. "Lookup" will take place if card and battery are inserted and compartment doors shut without Power switch turned ON! (If a bootable card is found and cam is powered on cam will try to locate and load Autoexec.bin and that (in short) is ML.)

    What's likely happening (similiar to older EyeFi cards) is that the card "does not like" cam's access method trying to determine if the card is bootable. There is a problem with Lexar's firmware/controller for this very card and it should be their responsibility to make their cards fully compatible.

  7. Alex

    You could also do the following test:

    • copy the raw contents of both SD card images, after formatting them in the same way (on a Linux system, dd if=/dev/your-card of=card.img)
    • look for differences (for this, I use vbindiff; there might be nicer GUIs around)
    • if there are no differences between the two card images, it's probably the card controller, as Walter said
    • if there are differences, I may be able to reproduce the error in QEMU, but there is one more thing to try:
    • fill the cards with zeros (dd if=/dev/zero of=/dev/your-card, but triple-check so you don't overwrite your HDD!!!) and format them again (this step might even fix the issue)
    • if, even after this step, there are differences between the card images, zip them and send them to me.

    Note: you can find GUIs that copy the raw card contents or fill a card with zeros for your operating system, but I don't have experience with any of them.

  8. Eric J. Russell

    Thanks, guys. Just an FYI, I haven't disappeared, I'm just working on what a1ex instructed. I'll post when I get results.

  9. Eric J. Russell

    Unfortunately I'm having trouble finding a file comparison program that will take 1TB files. Any recommendations?

  10. Eric J. Russell

    Thanks, a1ex. Sorry to bother you. I worked out the dd troubles. I'm currently zeroing up RED to compare. BLUE soft-killed the 700D both while zero'd and formatted after zeroing.

  11. Eric J. Russell

    OK, one thing I'm not 100% on: No storage site I'm part of has a max limit that's anywhere near handling two, albeit zipped and compressed, 128GB files. How do I sling 'em your way?

  12. Eric J. Russell

    I can already tell, it's going to be surprisingly tiny. OK, never mind. I'll upload tomorrow morning when it's finished zipping.

  13. Eric J. Russell

    To the letter, Walter. Holy crap, that's a ton of info to sort through. I don't have time for this right now. :(

    Give me a day and I'll sit down and cram all the 7zip compression methods into my brain. Until then, thank you mates so so much for taking the time to help me out with this issue.

  14. Alex

    If you really zeroed out the cards before formatting, the compressed size should be very very small.

    In my example (linked above), a 256MB card image, zeroed out, formatted, and with a small autoexec.bin on it, was compressed to less than 45K (both 7zip and xz got the same size).

    Even if the size would be several GB, the compressed size should be similar, as the image would contain mostly zeros.

    Therefore, you should really double-check the zeroing process (you can paste the dd command and its output here so we can verify).

  15. Eric J. Russell

    I used dd if=/dev/zero of=\.\Volume{string for mounted card}

    Zero'd cards inserted into the card reader request to be formatted in order to be used.

    Am I off here?

  16. Walter Schulz

    Is there any known issue with 7-zip skipping compression? File size too big, free temp storage area too small?

  17. Alex

    If you are using , can you run dd --list ?

    I have a feeling you have zeroed out only the active partition, not the entire card (which may explain why it didn't fix the "bricking" issue). Still, it doesn't explain why the images couldn't be compressed.

  18. Alex

    Hm, I'm not sure \\?\Device\Harddisk2\Partition0 is the entire card, and no idea what \\?\Device\Harddisk2\Partition1 is (no experience with windows device names, sorry).

    Can you run it from a Linux LiveCD? To find the device name, run dmesg after inserting the card.

  19. Eric J. Russell

    lol I'm going in to work soon, but I'll see if I can dig up my old Kubuntu disk when I get back. You'll have to guide me pretty tight from there, though. Linux is likely more alien to me than Windows is to you.

  20. Log in to comment