Firmware: Canon EOS-1D X Mark II v1.02

[Maximilian]

If this means you can't use CFast cards formatted in the computer, this is a half-way fix IMHO.

Please refer to the camera manual(s) (for almost every camera):
"If the card is new or was previously formatted by another camera or personal computer, formatting the card with the camera is recommended."

That may be true, but if I carry two different camera bodies (5DMkII and 5DMkIII) I will mix cards with no issues.

It's up to you to decide what you want to do. That's the freedom of choice.
If you later find out that files - pictures - were corrupted please don't complain and don't start a thread about Canon beeing stupid. Good luck.

 

[JMZawodny]

So, Canon's workaround is to basically create a 'garbage' file on the CFast card that it will always write to at the end of any data write. This means that the 'at risk' data is no longer an image file but instead is the 'ImgSaver.bin' file. If the data in the file is corrupted, it does not matter.

So....Sandisk problem. Canon 'very primitive' work-around fix.

Just remember to format the card IN THE CAMERA or Canon's work-around will not have any effect.

Bob

Since I use Lexar cards and have not encountered this problem, I'll skip this firmware rev. I hope someone does testing to see if there is any impact to the camera performance (like max fps, max burst size, ...).

 

[Robert Kline]

Since I use Lexar cards and have not encountered this problem, I'll skip this firmware rev. I hope someone does testing to see if there is any impact to the camera performance (like max fps, max burst size, ...).

Thinking about it, I'm guessing the write to the ImgSaver.bin file occurs only in the 'final' write that the camera does to the card, hence the text in the firmware update about the 'access light staying lit or blinking' longer than before when opening the card slot cover.

If that's right, then I would assume (standard warning about the word 'assume') that it should not have an effect.

Physical testing to confirm this would be good, as so logic is all too often not applied when doing code design.

Bob

 

[msatter]

I don't own the camera...maybe in my dreams.

If thee is a extra file written then it solves the card not writing through it's cache it is a so called quick-and-dirty fix but it is a fix.

Now what is Sandisk doing for owners of the cards in the meantime especially the card came together with the camera supplied by Canon.

 

[tron]

This is quite an interesting piece of information. Now if there is anyone that has a non-sandisk cfast card maybe could let us know:

1. whether using firmware 1.00 there is a problem like the one with sandisk.

2. whether using firmware 1.02 there is still an ImgSaver.bin file.

 

[RGF]

So, Canon's workaround is to basically create a 'garbage' file on the CFast card that it will always write to at the end of any data write. This means that the 'at risk' data is no longer an image file but instead is the 'ImgSaver.bin' file. If the data in the file is corrupted, it does not matter.

So....Sandisk problem. Canon 'very primitive' work-around fix.

Just remember to format the card IN THE CAMERA or Canon's work-around will not have any effect.

Bob

Since I use Lexar cards and have not encountered this problem, I'll skip this firmware rev. I hope someone does testing to see if there is any impact to the camera performance (like max fps, max burst size, ...).

You'll need to skip all future firmware upgrades to avoid this patch. They are accumulative

 

[msatter]

It would not be forever that the quick-and-dirty fix has to stay in the firmware. If Canon and Sandisk, a Western Digital firm, solve the problem by exchanging the faulty cards then the firmware can become normal again.

 

[mrsfotografie]

If this means you can't use CFast cards formatted in the computer, this is a half-way fix IMHO.

Please refer to the camera manual(s) (for almost every camera):
"If the card is new or was previously formatted by another camera or personal computer, formatting the card with the camera is recommended."

That may be true, but if I carry two different camera bodies (5DMkII and 5DMkIII) I will mix cards with no issues.

It's up to you to decide what you want to do. That's the freedom of choice.
If you later find out that files - pictures - were corrupted please don't complain and don't start a thread about Canon beeing stupid. Good luck.

No complaints, it always works reliably in my experience

 

[unfocused]

I wonder at what point Canon starts manufacturing the 5D IV. If they have already started production they would have to go through and change the firmware on every unit. That would be a real pain.

 

[unfocused]

Thinking about it, I'm guessing the write to the ImgSaver.bin file occurs only in the 'final' write that the camera does to the card, hence the text in the firmware update about the 'access light staying lit or blinking' longer than before when opening the card slot cover.

If that's right, then I would assume (standard warning about the word 'assume') that it should not have an effect.

Except that in my case it occurred when the camera automatically switched cards during a burst when the CFast card became full. It does seem likely you could lose a frame or two when that happens. Fortunately it's an unusual situation. The card has to reach capacity in the midst of a burst and since it's pretty unusual for me to reach capacity on a 64GB card I'm not overly concerned.

 

[JMZawodny]

So, Canon's workaround is to basically create a 'garbage' file on the CFast card that it will always write to at the end of any data write. This means that the 'at risk' data is no longer an image file but instead is the 'ImgSaver.bin' file. If the data in the file is corrupted, it does not matter.

So....Sandisk problem. Canon 'very primitive' work-around fix.

Just remember to format the card IN THE CAMERA or Canon's work-around will not have any effect.

Bob

Since I use Lexar cards and have not encountered this problem, I'll skip this firmware rev. I hope someone does testing to see if there is any impact to the camera performance (like max fps, max burst size, ...).

You'll need to skip all future firmware upgrades to avoid this patch. They are accumulative

While true, if the patch is only activated for cards formatted in the camera, then I can skip it for all versions. I rarely format the cards in the camera. I usually format them on my mac if at all. The larger CFast card I have I formatted to Fat32 in the mac.

 

[zim]

I'm a software developer and have some experience with industrial firmware. Reading Canon's notes on the firmware fix made me laugh. Both Canon and Sandisk have indicated that this is a Sandisk problem, but Canon was going to issue a firmware change that 'worked around' the issue.

The 'issue' is that the files associated with the last 5 or so megabytes of data written to the card can be corrupted when the camera is powered off. It sounds like the CFast card probably has some volatile memory in addition to the non-volatile memory. This may act as a 'cache' for performance. I speculate that it is the responsibility of the 'card' to ensure that the contents of the volatile memory are written to non-volatile memory on power-down and for some reason the Sandisk card is failing to do this.

The pre-firmware update work-around was to take enough 'junk' photos before powering off to ensure that important photos were not corrupted.

I find it humorous that the Canon firmware update appears to do EXACTLY the same 'cluge' work-around. Consider the following text from the firmware update:

Note that when using a CFast card formatted according to the above step 2, the following operations will take place.
- An "ImgSaver.bin" file of several MB in capacity will be created in the "MISC" folder on the card. Do not move or delete the folder or the file on the card.
- When opening the card slot cover, the access lamp may remain lit or blink for a longer duration.

So, Canon's workaround is to basically create a 'garbage' file on the CFast card that it will always write to at the end of any data write. This means that the 'at risk' data is no longer an image file but instead is the 'ImgSaver.bin' file. If the data in the file is corrupted, it does not matter.

So....Sandisk problem. Canon 'very primitive' work-around fix.

Just remember to format the card IN THE CAMERA or Canon's work-around will not have any effect.

Bob

And if there is not enough space left on the disk to write the bin file?
Or does the update make sure there is always space in which case you've not really brought what you paid for.
This really is a temp cludge of a fix

 

[Robert Kline]

And if there is not enough space left on the disk to write the bin file?
Or does the update make sure there is always space in which case you've not really brought what you paid for.
This really is a temp cludge of a fix

The file is created when the CFast card is formatted with the 1.02 firmware. So, it is always present. The firmware just 'overwrites' the data in the file.

So...I guess folks could complain about 'reduced capacity'!

Bob

 

[msatter]

And if there is not enough space left on the disk to write the bin file?
Or does the update make sure there is always space in which case you've not really brought what you paid for.
This really is a temp cludge of a fix

The file is created when the CFast card is formatted with the 1.02 firmware. So, it is always present. The firmware just 'overwrites' the data in the file.

So...I guess folks could complain about 'reduced capacity'!

Bob

I would worry more about the information written every time on the same location after one or more pictures.

 

[East Wind Photography]

I'm a software developer and have some experience with industrial firmware. Reading Canon's notes on the firmware fix made me laugh. Both Canon and Sandisk have indicated that this is a Sandisk problem, but Canon was going to issue a firmware change that 'worked around' the issue.

The 'issue' is that the files associated with the last 5 or so megabytes of data written to the card can be corrupted when the camera is powered off. It sounds like the CFast card probably has some volatile memory in addition to the non-volatile memory. This may act as a 'cache' for performance. I speculate that it is the responsibility of the 'card' to ensure that the contents of the volatile memory are written to non-volatile memory on power-down and for some reason the Sandisk card is failing to do this.

The pre-firmware update work-around was to take enough 'junk' photos before powering off to ensure that important photos were not corrupted.

I find it humorous that the Canon firmware update appears to do EXACTLY the same 'cluge' work-around. Consider the following text from the firmware update:

Note that when using a CFast card formatted according to the above step 2, the following operations will take place.
- An "ImgSaver.bin" file of several MB in capacity will be created in the "MISC" folder on the card. Do not move or delete the folder or the file on the card.
- When opening the card slot cover, the access lamp may remain lit or blink for a longer duration.

So, Canon's workaround is to basically create a 'garbage' file on the CFast card that it will always write to at the end of any data write. This means that the 'at risk' data is no longer an image file but instead is the 'ImgSaver.bin' file. If the data in the file is corrupted, it does not matter.

So....Sandisk problem. Canon 'very primitive' work-around fix.

Just remember to format the card IN THE CAMERA or Canon's work-around will not have any effect.

Bob

And if there is not enough space left on the disk to write the bin file?
Or does the update make sure there is always space in which case you've not really brought what you paid for.
This really is a temp cludge of a fix

This is really a moot point. If your card is full you have other problems to worry about.

 

[kaihp]

And if there is not enough space left on the disk to write the bin file?
Or does the update make sure there is always space in which case you've not really brought what you paid for.
This really is a temp cludge of a fix

The file is created when the CFast card is formatted with the 1.02 firmware. So, it is always present. The firmware just 'overwrites' the data in the file.

So...I guess folks could complain about 'reduced capacity'!

Bob

I would worry more about the information written every time on the same location after one or more pictures.

In that case, you're worrying about a non-issue: wear-leveling of flash cells (ie moving files around in the flash memory to avoid this problem) has been done by system firmware for 20+ years.

 

[UnholyRacket]

Updated via MAC OS. All went swimmingly. Cannot recreate the problem now, which I had experienced (although infrequently) previously. Still leaves me feeling a little nervous as the talk of 'workarounds' etc doesn't sound ideal. Having invested a small cameras worth of pennies in Sandisk cards (which I have traditionally been a fan of), I am a little disappointed in this episode. :-\

So my opinion summary is....

Thanks to Canon for the fix, but why did this not get picked up in testing? Sandisk are hardly a niche card manufacturer. Unfortunately I can't really think of any positives for Sandisk from this. Short of recalling/replacing cards not sure what they can do.

 

[kaihp]

Still leaves me feeling a little nervous as the talk of 'workarounds' etc doesn't sound ideal.

While not 100% ideal, workarounds generally gets you from the ~99.95%-mark to the 100% functionality.
In this case, you loose ~5MB of capacity on the card, vs not getting corrupted images. With a 64GB card, it's less than 0.1% of capacity, so I guess you could call the solution for 99.9% ideal

 

[LDS]

Thanks to Canon for the fix, but why did this not get picked up in testing? Sandisk are hardly a niche card manufacturer.

Probably because tests weren't designed to pick this. Hope Canon updated its tests now (and the 5D4 doesn't need workarounds) . It would be interesting to know why - AFAIK - only the 1Dx II + SanDisk combination triggers this, and if there are issues at the hardware level - and on which side (if not both). If hardware is OK, maybe they will eventually deliver a full fix (which may require more complex changes, and time to test them to avoid another bad situation), if a recall is needed, well, that's expensive, and will be the last option.

 

[kaihp]

Thanks to Canon for the fix, but why did this not get picked up in testing? Sandisk are hardly a niche card manufacturer.

Probably because tests weren't designed to pick this. Hope Canon updated its tests now (and the 5D4 doesn't need workarounds) . It would be interesting to know why - AFAIK - only the 1Dx II + SanDisk combination triggers this, and if there are issues at the hardware level - and on which side (if not both). If hardware is OK, maybe they will eventually deliver a full fix (which may require more complex changes, and time to test them to avoid another bad situation), if a recall is needed, well, that's expensive, and will be the last option.

Certainly the SanDisk card operates in a slightly different way than the other manufacturers' cards. From what has been written publicly, it seems like it needs to have the power on slightly longer than other cards, to avoid the last ~5MB written getting corrupted.

Testing is based on many criteria, but one of them is usually worst-case scenarios; e.g. highest number of new files being created/second, highest bandwidth written (both user-seen BW and internal BW) and so on.
For example, the flash memory in the CF/CFast is written in "chunks", so you will have an expansion of the data-rate when you spill over to using just one byte of the final "chunk" (Unrealistic example: 16MB+1byte becomes 17MB).

My guess is that even though stills can be shot at up to ~450MB/sec (16fps * 28MB/image @ ISO3200), the Motion-JPEG video storage requires even more bandwidth, so this was a metric to test for, but the test engineers didn't expect the power-off/change-cards scenarios to be important.

The old RISC-processor maxim comes to mind: "Make the common case fast and the rare case correct".

The trouble is that rare events like the power-off/change-card scenarios are notorious for taking a lot of time to simulate or test for.

My gut feeling is that this is also why Canon has pushed out the current solution; it is an obvious workaround where you are guaranteed to avoid the problem, without having to go through a vast regression suite. Once Canon have had time to fully understand the timing issue and do a regression for it, they might issue a new FW update (together with some other updates).