Perhaps this page is unnecessary, since now there is Vitaly's more detailed article here?

Downloading manufacturer's firmware updates

Very innovative methods of getting hardware, but what is missing from firmware updates provided on manuafacturer's web site? For general interest, might explain why at the top of the page. If it would work, mention that instead.

Receiver scheme

To GrAnd: instead of a phototransistor, isn't the thing on the scheme a photodiode? --Melado 23:23, 11 July 2007 (UTC)

It can be a photodiode. But I did not test such scheme, because I used a phototransistor. But, the A700 firmware was gotten by a photodiode in the line-in input, AFAIK. So, just try... --GrAnd 12:23, 15 July 2007 (UTC)
Hm, I see. But I have another doubt. If I want to dump the A540 firmware, I will have to use the blue LED instead the AF one. Since BPW96C is only sensible from 620 to 980 nm (and blue is about 450-500), I guess I should use another phototransistor. Any advices? Thanks. --Melado 16:00, 17 July 2007 (UTC)
I tested BPW96C with blue led and it is sensible enough. The following graph demonstrates the signal strength for comparison:
Wave cmp.png
The first part is the signal from AF beam (red lamp). The second - from blue led. This couple was captured by BPW96C inserted in mic-in.
And the last part is the signal from blue led captured by photodiode inserted in the line-in of soundcard.
BTW. A700 firmware was dumped with the signal strength showed in the last part of the graph.--GrAnd 10:01, 18 July 2007 (UTC)
Thanks again. I bought a BPW77NB, that should be the same. I build the scheme and, more or less, it works. I recorded a piece of 1 minute of blinking, and ran adc.exe. It gave a dump file of 0 bytes. I recompiled adc.exe to change the values of the defines to the A610's blue led ones (the values you wrote in the wiki), and the problem that I have now is that adc.exe gives thousands of SYNC ERRORS and creates a dump file with some bytes.
Maybe I should tweak the values of the defines? How? And which ones? The ones within the adc program, the ones from the FIR executable, both? --Melado 23:24, 18 July 2007 (UTC)
If the signal looks readable (at least as the third part on the picture above) you have to tune adc program only. If the signal has small amplitude you have to reduce threshold levels (the baseline is 0x80). The lowest possible values are (0x80 +-1):
  • LEVEL_THRES_HI: 0x81
The other values are numbers of samples:
  • LEN_SYNC: Spacing between bytes
  • LEN_SPACE: Spacing between bits
  • LEN_0: Narrow pulse - logical "0"
  • LEN_1: Wide pulse - logical "1"
If it does not help then just send me the file you recorded and I'll send you appropriate adc.exe.
--GrAnd 12:08, 19 July 2007 (UTC)
Hello, Melado & GrAnd. I found an A540 at half price last week and have started to look at it.
Melado, the orange LED does work at 0xc0220080 (from the A530 page).
I eventually found a transistor in my junk box that works in the visual (SD5410 photodarlington) so I can probably get a capture the next time I work on it.
GrAnd, pakwif did not work on a big-endian host; can I give you a patch?
Nobody has used big-endian machine yet. I think it could be useful if you share the patch. --GrAnd 04:37, 30 July 2007 (UTC)
I'll do that as soon as I test that I didn't break it for little-endian host.
Addendum-- It looks like I am going to have to do the actual recording on a Windows (XP) machine, which I am not familiar with; can someone recommend a suitable free recording program? --kps 02:27, 30 July 2007 (UTC)
I think any recording program which can record at least 6 hours and save a data as PCM will be suitable. I used Adobe Audition (Adobe has the trial version). --GrAnd 04:37, 30 July 2007 (UTC)
Thanks, that works. I have a partial dump. My audio problems are:
  • Sound card only goes up to 48KHz; not really a problem, because...
  • Sound card has very high impedance input, so the transistor is slow.
  • Lots of noise, especially 60Hz (mains power). I used the AF LED to get more signal than noise.
So right now I have checksum errors on about half the blocks. Now, Eric below has posted while I was writing this, so I will try his work -- thanks, Eric! But for the benefit of someone working on a different camera in the future, this is what I would have tried next:
  • Tweak thresholds and lengths to try to get more data.
  • Run the signature finder and try to find enough I/O to dump to SD instead.
  • Run the signature finder on the camera, reporting by LED very slowly.
  • Repeat the audio dump in full, or modified to dump only my missing blocks, until I get everything.--kps 13:45, 2 August 2007 (UTC)
As an experiment I was able to get the dump of A610 using AF-assist lamp on 96KHz sampling rate at ~9200 bps. It took me just 1 hour. There was no errors at all.

AF-assist lamp, 96KHz

As for A700 there was only 5 (five!) CRC errors despite on low amplitude of signal (just +-1 sample). In this case 11KHz sampling rate was used. And there was no noise at all unless I touched the bared end of wire I used to connect the phototransistor to my sound card.

50Hz noise, amplitude +-25 samples

--GrAnd 15:10, 2 August 2007 (UTC)
Hello, I have a patch for the A540 Camera on (Password is 'a540'). I don't sure on the values zoom_busy, focus_busy and nrflag in capt_seq_hook_set_nr(). You can use this patch to write the firmware onto the SD-Card (debug.c). Have fun, Eric!
So, it seems that you've got the dump of A540? Could you share 'PRIMARY.BIN' file? --GrAnd 15:10, 2 August 2007 (UTC)
Hello, GrAnd. You can download the dump on here (Password is also 'a540').
I can't download the file. The reason is incorrect password (Das eingegebene Kennwort war falsch). --GrAnd 21:38, 2 August 2007 (UTC)
Sorry, The password is 'a504'. I've mistype. --Eric 05:46, 3 August 2007 (UTC)
Thanks. I've got it. BTW, how did you get the dump? Did you use blinker? I'm asking just for statistics. --GrAnd 06:24, 3 August 2007 (UTC)
I've got dump it by orange AF-LED and use the BPW40 sensor. The absolute time for download was 45 Minutes.
You can download the dump program here. But it's a hack and not to distributed ;-).
My problems:
  • soundcard only goes up to 48KHz
  • the hi- and low-level was changed. I don't know wherefore.
  • the time for CRC-check is not deterministic. The consequence is a different length of sync space and a new tune on the sensor. I've calc it befor send the data.
--Makalu 10:17, 3 August 2007 (UTC)
The time of CRC calculation does not affect the consequence recognition. It is always calculated while SYNC is sent. The main idea is the SYNC signal have to be longer than 'between-bits' signal. So, if 'between-bits' signal has length, for instance, 5 samples, and SYNC signal (usually) - 10 samples, the length of SYNC signal can reach 1000 samples (due to CRC calculation) without any negative effect on transmitted sequence. --GrAnd 11:24, 3 August 2007 (UTC)

Oops, it looks that I arrived late. It looks like you have the A540 dump now. Is it possible now getting the CHDK ported to it? --Melado 13:14, 6 August 2007 (UTC)
Unfortunately, Vitaly and I have no free time at this moment. Vitaly promised that the ported version will be available in September. The version, sources of which are mentioned above, is not fully completed (autoboot feature won't work, many addreses are not found/incorrect, etc). --GrAnd 13:39, 6 August 2007 (UTC)
Ah, don't worry. I just wanted to know if now that you have the dump it was possible to port it. Take your time and thanks for all the work :) --Melado 14:07, 6 August 2007 (UTC)
If you need A540 Tester, contact me --demlak 11:28, 13. September 2007 (CET)
I have a firmware dump from my a570IS. Is someone interested for chdk porting ? --rossig 01:00, 30. September 2007 (CET)
I am beginning the porting process of my A560. Please, can you write a little (maybe in a separate topic, or even in the A570 page) on the circuit you made, the results, and your experience? I have followed your post in dpreview and maybe, the people is interested in knowing your progress.-- 13:56, 30 September 2007 (UTC)

IXUS 700 firmware

Here is a IXUS 700 firmware link

Getting blinker to work on a SD300?

I've gotten blinker to build and the camera sees the PS.FIR file as a valid firmware for the camera (ID 0x30BF), but when I run the "firm update" menu item, the screen goes blank then half a second later the lower indicator LED (next to the optical viewfinder) lights up solid, then the camera becomes unresponsive. The only way to recover is to remove the battery. I tried swapping some values around to make do_bit use the Print LED, but that also yielded no results. Perhaps something is terribly wrong with my PS.FIR file, would someone else mind building one with a camera ID of 0x30bf so I can test it? Myself, and several thousand of my co workers would really appreciate it. (all Canon USA employees received SD300's as a bonus in 2004)

During the 'blinking' process a camera behaves as you described. Are you sure that the led lighted strongly solid? Because the blinking is fast and the led look like solid. --GrAnd 13:39, 13 September 2007 (UTC)
Yes, it was completely solid, and it was the lower rear indicator LED next to the viewfinder (macro mode focus light) that was illuminated, not the AF Assist beam. I compiled the program using the WinARM toolchain, and the windows gnu utilities for the other Unix commands in Make.bat. I may try just using some of your code as a sample to write some kind of super-simple test that just flashes the AF Assist beam to see if I can get that to work. I'll have to try that later tonight. --Dirkus 19:20, 13 September 2007 (UTC) (Correction - WinARM, not WinAVR. My bad.)

PowerShot SD400 firmware

The link to direct download SD400 firmware Installation Instructions Firmware updater software for Windows Firmware updater software for MacOS X

PowerShot A430 firmware

Greetings! The name's Littlejohn. I've just had a play with my powershot A430 (firmware GM1.00B, P-ID 30F8 PAL).

(edited to reflect current status) I've compiled blinker (using yagarto) and was able to upload the blinker firmware to my camera.

Problems I encountered / solved

How safe is the blinker firmware? That's one I had to ask myself before I did the "firmware upgrade". I had to read through the wiki to persuade myself it was safe enough. I guess in a real firmware upgrade, a part of the .FIR program will actually upload a firmware to flash (if all the safeguards are passed). The blinker firmware doesn't write anything to the firmware flash (since this is what we are trying to dump) and the ominous warnings "Are you sure you want to upgrade from to" may be ignored. Anything goes wrong, take the batteries out and the camera will be as good as new (hopefully).

I use cygwin / yagarto. In make.bat, I had to replace

zero | dd bs=1k count=100 >> main

by the following two lines:

c:\cygwin\bin\dd.exe bs=1k count=100 if=/dev/zero

c:\cygwin\bin\cat.exe >> main

I made the circuit, how do I know it's working? If you put the photodiode or phototransistor against the HD activity LED, you will pick-up scritching noises via your recording program.

I made the circuit, used short leads but I pick-up 50Hz noise! The noise you may pick-up actually comes from strobing artificial lights. Use masking / duct tape to prevent artificial lights from interfering.

I uploaded the blinker firmware and the AF LED is solid lit. Actually, I padded the wrong file using dd, and my firmware was a bit broken. I guess that's why I got a solid light! Dirkus, check the size of your PS.FIR. On my machine, it's 105,332 bytes. My first attempt was only 5K and lit the AF LED solid. With a working blinker, about 5s in, I now actually see some blinking activity.

Mine is ~103K. I got around the dd problem by just using dd on my mac to make a 100K file of dev/zero, then just cat-ing it onto the end like you did. I may try re-compiling mine using yagarto. --Dirkus -- 11:45, 18 September 2007 (UTC)

Things to try next...

I'm thinking of using audacity to record the sound file, although I'm not sure whether the on-board soundcard will like 96KHz sampling rate.


Audacity - Photodiode passive circuit

If I use a phototransistor (tried SFH300-3 and YY66W, both available in the UK from Maplin), the signal is too small (need a screenshot). If I use a photodiode (used hamamatsu S1226-8BQ), I get a large enough signal, but do not recognise what I'm getting (see screenshot).

Any idea of what's going on?

At least this much is clear: On the A430, the faster speed will result in the wrong waveform being generated. I am now trying the blue LED at a slower transfer speed (see below).

Active circuit?

The PC's microphone input has a 2.34V rail available on one of the channels, so I tried a few powered circuit (both photodiode and phototransistor). They gives a much larger signal, but the shape of the signal still differs from the ones given as example.

The test circuit uses a small piece of breadboard. Bottom side has two rows of 3 tulip sockets. This is where I plug-in my phototransistors and filter cap. Top side has three rows of 3 tulip sockets. The one away from the cable, I plug my 1k trim in. The other two are used for bridging the circuit with the computer. These can be removed and replaced by filtering caps if needed.

Active circuit

Test circuit - under

Test circuit - top side

Test circuit and audio cable

Phototransistor Active circuit

Phototransistor, active circuit

Phototransistor active test circuit (bottom)

Phototransistor active test circuit (top)

The trimmer (blue on the photo above) has one of its legs bent. The two legs making contact with the circuit are the one under the screw and the middle one. The red component is a 1μF ceramic cap.

Active circuit, blue LED...

Audacity - YY66W phototransistor - Blue LED

YY66W - Blue LED - Filtered

I am now trying for the blue LED with slower transfer speed. I used my amplified circuit and tried both the S1226-8BQ photodiode, YY66W (IR) and SFH300-3 phototransistors. Surprisingly enough, the IR phototransistor is the one that gives the largest signal (see screenshots). With a lower transfer speed, I now get the waveform I was expecting.

The effect of the 1μF cap is shown in screenshot 2 (screenshot 1 is without). The signal amplitude is more constant and will (probably) result in fewer decoding errors.

All in all, it now looks like I should be able to get a firmware dump.

As usual, I'll keep you guys posted.

Cheers, --Littlejohn 10:00, 24 September 2007 (UTC)

Standard LEDs instead of photo-diodes

I suggested using a standard LED instead of a photo-diode or photo-transistor in the main article but for some reason my edit was reverted. I wonder why. I'll leave the comment here and hope it sticks. If you try it and it works, put it back in the main article.

I haven't tried this, but since most LEDs can be used as low sensitivity photo-diodes, any LED might work as a photo-diode. I would guess an LED of the same color as the LED on the camera would work best, and an LED with a shorter wavelength(closer to violet in the rainbow) than the LED used on the camera might not work at all. White LEDs might not work well as photo-diodes due to absorption by the phosphors, but I suspect that even they would work.