CHDK Forum
Using CHDK => General Help and Assistance on using CHDK stable releases => Topic started by: Poldy on 16 / August / 2013, 15:25:46
-
I'm using CHDK on powershot camera without any problems. I even uploaded wrong software and then removed battery. Everything OK.
This time, I tried to load CHDK on IXUS 110 IS, firmware update method. I had trouble finding camera firmware number, so I thought I should try the first one for IXUS 110 - ixus110_sd960-100b-1.2.0-3031-full_BETA.zip. It won't overwrite anything, so it should be safe . Stupid me. I have flashed many electronics devices, and this is the first time I have done something so stupid.
Now if I power on camera with power button, Canon writes on the the display, then error E32 appears. Lens are OK. If I power on with play button, only green light blinks.
I have removed battery, standard and internal (button type). Cleared SD card, connected to PC via USB... No success...
Is there anything I could do? Please help...
-
I had a SX260 that stopped working completely. I thought it was the power button or door closed sensor. I ended up sending it back to Canon under warranty, and they replaced it. You may have to do that.
However, my replacement SX260 recently did the same thing, but I got it to respond by taking the card and battery out, and trying the on switch with just the battery and no card. I had to do this twice, but then the camera came on. But then I realized that I was using the SD card for the G1X, not the SX260. I suspect that this is what happened before.
So it sounds like CHDK is going out of control if you load the wrong version for the camera. This is an easy mistake to make if you have more than one camera.
Maybe Phil or reyalp can figure out a way to check that the camera and CHDK version are compatible at the beginning of the loader before doing anything else?
-
I have removed battery, standard and internal (button type). Cleared SD card, connected to PC via USB... No success...
Have you tried with no card installed at all? Depending on exactly how you "cleared" the card, it's possible for some remnants of CHDK to be left. The camera should boot with no card and just say "No memory card" or something like that.
If you have tried without a card and still have the problem, let us know, there may be some debugging steps someone here can come up with.
Up to now, there has been no report CHDK causing this kind of harm. That's not to say it is impossible, but it's definitely not a known risk from using the wrong version.
Going from http://chdk.wikia.com/wiki/Canon_error_codes (http://chdk.wikia.com/wiki/Canon_error_codes) it looks like E32 is an IS related error. It seems unlikely to me that trying to load the wrong version could cause permanent damage to the IS system, but who knows...
A list of this kind of incident is kept at http://chdk.wikia.com/wiki/Camera_failures_suspected_to_be_caused_by_CHDK (http://chdk.wikia.com/wiki/Camera_failures_suspected_to_be_caused_by_CHDK) feel free to add yours.
So it sounds like CHDK is going out of control if you load the wrong version for the camera.
I would not jump to the conclusion that the OP's problem was caused by CHDK. It's possible, but there are other possibilities.
Maybe Phil or reyalp can figure out a way to check that the camera and CHDK version are compatible at the beginning of the loader before doing anything else?
For cameras with different diskboot encodings, this is impossible, because the camera simply decodes the image using the wrong keys and tries to execute it. CHDK is never executed. It might be possible to check the PID and possibly firmware version on models that are compatible. However, it's not really clear what could be done at that point, there wouldn't be enough information to shut down cleanly or display a message. You could trigger an exception, but I suspect even the exception handler code would be hosed at that point. maybe a romstarter exception handler?
-
Yes, I have tried with erased SD, different firmware SD, and without SD card.
If I connect camera to PC with USB, PC don't detect anything attached. Camera acts the same.
-
Maybe Phil or reyalp can figure out a way to check that the camera and CHDK version are compatible at the beginning of the loader before doing anything else?
For cameras with different diskboot encodings, this is impossible, because the camera simply decodes the image using the wrong keys and tries to execute it. CHDK is never executed. It might be possible to check the PID and possibly firmware version on models that are compatible. However, it's not really clear what could be done at that point, there wouldn't be enough information to shut down cleanly or display a message. You could trigger an exception, but I suspect even the exception handler code would be hosed at that point. maybe a romstarter exception handler?
It's never easy is it? It would be nice to have a message, but if it's the wrong firmware, I'd be happy for the program just to go into an infinite loop, even if you have to take the battery out to restart it. That would be preferable to executing random code that might end up flashing the camera and bricking it (if that's what's happening).
-
Yes, I have tried with erased SD, different firmware SD, and without SD card.
If I connect camera to PC with USB, PC don't detect anything attached. Camera acts the same.
One thing to check is whether you can run a "canon basic" script, such as the dumper found here: http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper (http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper)
See the card setup link at the top of that page for what you need to do to set up the card.
If it runs, please post the resulting dump. If something has been changed in flash, we may be able to tell from that.
If canon basic runs, it may be possible to suppress the error using the functions discussed in http://chdk.wikia.com/wiki/User:Srsa_4c/Working_with_a_broken_camera (http://chdk.wikia.com/wiki/User:Srsa_4c/Working_with_a_broken_camera)
If you can't get it to run, we may still be able to do something with a diskboot, but we would need to know what firmware version is on the camera.
If you have a jpeg from the camera from before it was bricked, we should be able to get the firmware version from that.
-
I have followed your instructions to run cannon basic script, but this is my first time, so I'm little lost.
I used EOScard to create script string, then two files must be on card, script.req and extend.m? Where should be universal dumper?
-
I used EOScard to create script string, then two files must be on card, script.req and extend.m? Where should be universal dumper?
See http://chdk.wikia.com/wiki/Canon_Basic#Format_of_the_SD_card (http://chdk.wikia.com/wiki/Canon_Basic#Format_of_the_SD_card) for details: script.req should contain that magic string, and extend.m should contain the Canon Basic script (in your case, the dumper).
You need to start the cam in play mode, and make sure the card is _not_ protected by the write protection switch. You can start the script with a short press on the SET button.
A possible problem:
If the cam can't start in play mode due to the failed initialization of the IS, you might not be able to start the script.
The event procedures mentioned in that 'broken camera' wiki page are not available on your camera, unfortunately.
Can you start the cam in clock mode? Press and hold the SET button, then power the cam on with the PLAY button. Does it start and show the 'fancy' clock?
If all the above fails, you can upload a JPEG made by that camera, or you could determine the firmware version yourself with http://www.zenoshrdlu.com/acid/acid.html (http://www.zenoshrdlu.com/acid/acid.html) .
-
I have prepared SD card, but I can't run it. When I press play button, green light turns on for about half a second, everything else seems dead. I have tried SD card on friends camera - worked OK.
If I press simultaneously play and func. button, green light blinks for about 4 seconds, and there is LCD backlight, but remains dark. I can't bring watch on the display.
Firmware version is 101f.
-
I have prepared SD card, but I can't run it. When I press play button, green light turns on for about half a second, everything else seems dead. I have tried SD card on friends camera - worked OK.
If I press simultaneously play and func. button, green light blinks for about 4 seconds, and there is LCD backlight, but remains dark. I can't bring watch on the display.
Firmware version is 101f.
Yes, I was afraid of that. Apparently the IS initialization starts early in the boot process and blocks it. I think diskboot will still work, but it will take several tries trying to make even file operations to work (a ROM dump is desperately needed, the camera is a black box without it).
BTW, what's the longest time the camera will stay on (in rec mode I guess) before shutting down with E32?
-
In rec mode, camera is on for about a second (even lenses don't extend completely), there is CANON logo no the LCD, then LCD goes black and E32 is displayed for about 5 seconds. Then camera shuts down.
-
Actually, the old udumper might be able to dump the firmware.
Download Cardtricks 1.44 from this link (https://drive.google.com/folderview?id=0B08pqRtyrObjSmFqSV8yRUlqbnM&tid=0B08pqRtyrObjTy11Y003Sk1lYTQ#list), and prepare a card with the "NewDryOS" option. It requires a bootable card, it will dump the firmware without any visual activity (details in udumper.txt).
If it's unsuccessful, try the "DryOS" method.
In rec mode, camera is on for about a second (even lenses don't extend completely), there is CANON logo no the LCD, then LCD goes black and E32 is displayed for about 5 seconds. Then camera shuts down.
So, if it has to be CHDK, there's 5 seconds to make a dump.
-
I did a quick comparison of the stubs_entry.S files for 100b and 101f
The lowest change function address I found is
GetVRAMHPixelsSize 0xff8b58dc-> 0xff8b59cc
The highest unchanged is
IsStrobeChargeCompleted 0xff8a71a0
variable addresses are changed too:
canon_shoot_menu_active 0x000070bd -> 0x000070c1
Since the code size changed, the canon firmware initialized data segment (copied to 0x1900) would be all wrong when loading the wrong firmware:
FFB7DF64 -> FFB7E0D4
This would wreak all kinds of havoc, but it ought to croak pretty early.
-
I did a quick comparison of the stubs_entry.S files for 100b and 101f
I triggered my problem by booting the G1X_100g SD card on my SX260_101a. Can you predict what would happen from subs.entry.S?
The power button or play button had no visible effect with the G1X SD card in the SX260. I took the card out and still got no response. Taking the battery out and reinserting (without a SD card) then worked (printed SD card error message). Then the SX260 SD card worked.
I think this may have been what happened with my old SX260_100b. I remember the power button becoming unreliable for awhile, and then it stopped working complete (bricked camera) no matter what I did.
-
I triggered my problem by booting the G1X_100g SD card on my SX260_101a. Can you predict what would happen from subs.entry.S?
G1x and sx260 have different diskboot encodings, (7 and 8 respectively) so if the wrong diskboot is present, the canon firmware will load it, decode it with the wrong key, and attempt to execute the resulting garbage.
Since this all happens in the canon firmware, there is absolutely no way CHDK could prevent it.
Figuring out specifically what would happen would require duplicating the decode process and disassembling the resulting junk, but I'd expect it to hit an exception very quickly. If the exception handlers are also borked, it could end up in an infinite loop of exceptions. I would not expect this to be very dangerous, because it should fail very quickly. Poldy's scenario is potentially more dangerous, because it can run for a while and send wrong values to real functions.
The power button or play button had no visible effect with the G1X SD card in the SX260. I took the card out and still got no response. Taking the battery out and reinserting (without a SD card) then worked
This is what usually happens when you try to run a diskboot with the wrong encoding. The camera gets stuck in a state that requires the battery to be removed to reset. Collectively, CHDK developers have done this a LOT without any obvious permanent damage.
I remember the power button becoming unreliable for awhile, and then it stopped working complete (bricked camera) no matter what I did.
That sounds like a regular old hardware failure to me. It's hard to see how executing garbage code could cause a progressive failure like that.
-
Poldy's scenario is potentially more dangerous, because it can run for a while and send wrong values to real functions.
There have been many people who posted in the forum that, not knowing their correct firmware version, or CHDK not being available for their exact version, they simply tried all the firmware versions available for their camera. Presumably many more people tried the same thing but did not post on the forum.
Did this brick some cameras? Hard to say but you would think there would have been more complaints?
-
There have been many people who posted in the forum that, not knowing their correct firmware version, or CHDK not being available for their exact version, they simply tried all the firmware versions available for their camera. Presumably many more people tried the same thing but did not post on the forum.
Did this brick some cameras? Hard to say but you would think there would have been more complaints?
I expect most people who tried an bricked their camera would complain somewhere, probably here or on the wiki.
I think the odds of this ending up just right to damage the camera are pretty low, but higher than if you try to execute an incorrectly decoded diskboot or a firmware that doesn't have remotely similar addresses. I don't have any opinion whether it happened in this case, but it's not completely implausible.
It might be worth digging through the ixus110 porting thread, and seeing if anyone else there reported trying the same combination. If someone did without bricking their camera, that would favor this being a coincidental failure.
-
That sounds like a regular old hardware failure to me. It's hard to see how executing garbage code could cause a progressive failure like that.
Yes, that's what I concluded at the time. I did open the battery door on that poor camera a few hundred times to get the card in and out for CHDK development. Now I use PTP.
There have been many people who posted in the forum that, not knowing their correct firmware version, or CHDK not being available for their exact version, they simply tried all the firmware versions available for their camera.
I plead guilty to doing that with the G1X, since there isn't a key sequence that shows the firmware version, and I was too lazy to figure out Card tricks. Did anyone figure out how to show the G1X firmware version page?
And I've crashed the camera many times and had to remove the battery while doing CHDK development, with no ill effects, but CHDK had started normally beforehand. When the power button doesn't work, though, it's not obvious what's going on.
-
Hi Poldy,
I'm not sure if you've given up on this or done something with the camera, but here's CHDK build for ixus110_sd960 that will attempt to save a romlog (camera error log) and a copy of ROM at startup. These could potentially help us figure out what happened to your camera.
I'm not sure if they will complete before the camera shuts down again, but it's worth a try. If it works at all, the romlog should at least get saved. The files saved on the card should be ROMLOG.LOG and ROMDUMP.BIN
The card will have to be made bootable and locked. You must have gone through the same process when you originally loaded the wrong firmware, so the card may still be set up correctly.
If you use this, you should hold the power button down so the CHDK will attempt to start in record mode.
edit:
In the original porting thread, I see that someone used a 101d build on a 101f camera without permanent damage: http://chdk.setepontos.com/index.php?topic=9133.msg95630#msg95630 (http://chdk.setepontos.com/index.php?topic=9133.msg95630#msg95630)
I don't see any evidence of anyone trying 100b build on a later camera.
-
I have gave up until yesterday, when I found camera tossed in some old box. That reminded me of this thread ind I found reyalp post.
I did what you said. At startup, there was for a second CHDK picture displayed. Romdump.bin was created, log file was empty.
http://www.filedropper.com/romdump (http://www.filedropper.com/romdump)
Thank you in advance.
-
One more thing. I don't know what happened, but maybe because of different SD card or simply because camera was without battery for long time...
If I insert bootable card and press power button, CHDK image shows and I can go actually inside CHDK menus, for about 3-4 seconds before camera shuts down due to lens error.
Someone mentioned that script can disable lens error, but I don't know how to set up everything correctly...
-
Thanks for getting back on this issue.
Someone mentioned that script can disable lens error, but I don't know how to set up everything correctly...
Newer cameras have a special function added to their firmware that prevents camera shutdown on (most?) e32 errors. Unfortunately this camera is slightly older generation and has no such function.
Now, for the ROM dump.
Your dump shows difference in 4 consecutive bytes (address is 0xFFDF4AA4) when compared to the 101f dump in our collection. That section of the firmware is some kind of data.
There are no asserts/exceptions recorded in the ROM. However, I see logged data that, I think, shows E32 (subtype 1) errors. This is "ISStartupError", which would also explain why you're getting an instant shutdown (cameras with e32 usually have ~60 seconds runtime before the shutdown).
It could be possible that those 4 damaged bytes are the cause of the IS initialization failure.
-
It could be possible that those 4 damaged bytes are the cause of the IS initialization failure.
Or an unrelated calibration difference, or flag recording the error ... (I have no preference for any of these theories)
From comparison with D10, which is similar generation and same ROM size, it looks like the normal "adjustment data" is at 0xFFFE0000 (EraseAdjustmentArea refers to a variable that has the address when running)
FFDF0000 seems to be the start of some block of data, before that it's all 0xFFFFFFFF (i.e. never used flash). I expect this address holds the same data for all firmware versions of the cam, and likely many other cams with the same ROM size.
FFDF0000 is referenced from ISCommunication.c in the firmware. Near the string "SIO_Int"
Our ixus110 100b, 101d and 101f dumps all have the same value (01 BC A9 02) at FFDF4AA4... which might lower the odds of it being a calibration value.
My d10 has a different value.
The next difference in poldy's dump is at FFFC0000, the there is only this one difference in the FFDF0000 block.
The ML cache lockdown hacks might offer a way to try "patching" this to the value found in other firmwares without modifying ROM.