Yes - these are the modes used in the original BLF VLD as far as I know. I had to use some time, to understand how Tido sets up modes - but it is actually quite clever…
I hope Tido can help here, as I am not expert on avrdude and its many options
Yes - these are the modes used in the original BLF VLD as far as I know. I had to use some time, to understand how Tido sets up modes - but it is actually quite clever…
I hope Tido can help here, as I am not expert on avrdude and its many options
sixty545, please try the following command to dump the firmware:
avrdude -pt13 -c usbasp -P com2 -u -Uflash:r:flash-dump.hex:i -Ueeprom:r:eeprom-dump.hex:i -Ulfuse:r:lfuse-dump.hex:i -Uhfuse:r:hfuse-dump.hex:i
This should create four files, one each for the program flash, eeprom, high fuse and low fuse.
OK, I can give it a try tomorrow evening. Then I need a way to pass the files to nkildal.
I just sent you a PM with instructions.
Btw: I just now spent 2 hours resoldering my SOIC clip - it turned out, that 5 of 8 connections had broken.
Some of the pins had pulled back yesterday - I guess I must have broken them in the process of pushing them out again - sigh :-|
I think the 6 pin ic is a PAM 2803 or similar ,DC DC converter which must start first to feed the atmel chip.
To start pin 4 must be in high state as in simples driver without modes.
I took another picture of the driver board, showing the 6-pin chip, but the number on it is not easy to see - it may look like CF80Q...
Is the same as in the C78 and Hugsby P31 , pam 2803, the last letters are year and month,
Two components was obstructing the clip. Had to unsolder them. Not an easy task for them old eyes.
But success!
4 files made:
flash-dump.hex
eeprom-dump.hex
hfuse-dump.hex
lfuse-dump.hex
Hope you can use them, nkildal.
The 6 pin circuit on my driver clearly reads: CFB0Q
! Edited dec.9:
The above dumps cannot be used because the chip prevent reading!
Hi sixty545
Thank you for the files - they have safely arrived.
If anyone is interested in the original files - they can be downloaded from here as a zip file.
I will now try to flash my blf driver board back to the original software and see what happens :-)
Ok - this is weird:
I flashed the chip using sixty545's files - now the light just gives out 2 bright flashes when i turn it on, and then is constant on, at what seems like full level.
Here are the results from verifying the chip after flashing it with sixty545's files - perhaps you guys can see something from the fuse settings:
avrdude -P /dev/tty.usbserial-A600aSmp -p t13 -b 19200 -c arduino -v
avrdude: Version 5.8cvs, compiled on Jan 15 2010 at 17:27:01
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "/usr/local/CrossPack-AVR-20100115/etc/avrdude.conf"
User configuration file is "/Users/nicolai/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/tty.usbserial-A600aSmp
Using Programmer : arduino
Overriding Baud Rate : 19200
AVR Part : ATtiny13
Chip Erase delay : 4000 us
PAGEL : P00
BS2 : P00
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 5 4 0 no 64 4 0 4000 4000 0xff 0xff
flash 65 6 32 0 yes 1024 32 32 4500 4500 0xff 0xff
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 2 0 0 0 0 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
Programmer Type : Arduino
Description : Arduino
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us
avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny13
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.04s
avrdude: Device signature = 0x1e9007
avrdude: safemode: lfuse reads as 79
avrdude: safemode: hfuse reads as EF
avrdude: current erase-rewrite cycle count is 808531511 (if being tracked)
avrdude: safemode: lfuse reads as 79
avrdude: safemode: hfuse reads as EF
avrdude: safemode: Fuses OK
avrdude done. Thank you.
However - no real harm has been done - as I tried flashing back to the BLF-VLD without problems :-)
Edit: I forgot to write, that the light actually turns on with both NiMH and Li-ion with sixty545's files now - even if it first blinks twice and then is constant on...
nkildal, looking at the flash-dump.hex I would say that it is not program code. I will try again when I get the clip to stay put on the uP. It slides off all the time.
OK, it sits.
When I repeatedly dump the flash, every time one or two bytes have changed at random places.
I'm afraid there is some timing issue here.
Every time I also get: avrdude: warning: cannot set sck period (see earlier in the thread).
I removed two components at the ends of the uP. Could they be needed for proper functioning?
I also had problems getting the clip securely positioned on the chip - I ended up cutting a tiny bit of plastic away from one of the corners on the clip.
It is my impression, that reading & writing the chip should be possible regardless of its surrounding components - but perhaps Tido knows more on this subject ?
However - you don't have to mess too much around with this, if it is too tricky and you risk killing your driver board.
Thank you for your effort so far :-)
I tried to dump an AK-47 driver also. The same pattern here (not the same bytes, but almost).
Edited dec.8:
The chip prevents reading.
Hmm - that sounds weird.
I just got hold of another BLF AA-Y4E from a friend of mine, and he has allowed me to try dumping the data from it.
I will try this out tonight and report back my findings :-)
Unless the firmware does some silly things like self-modifying code (which would wear out the flash memory pretty fast), there should be no difference between dumps.
Components are, in general, not added purely for aesthetic reasons . If you removed the brown-ish capacitors, the driver will probably still work, but you might experience some instability due to voltage spikes. The black components look like diodes and I doubt that the PCB will still work without them.
So the PCB works with NiMH when programmed with sixty545's files but not with the BLF-VLD. That's weird. Could you check if there is a trace from the ATtiny to the driver chip? If it's really a PAM2803 (thanks to arenat for the tip, BTW), the µC could disable the boost circuit if it detects that it is run off a Li-Ion battery. If possible, please check if the chip's pin 4 (closest to the PCB's centre) is connected to a pin on the µC.
Well, I did'nt remove any components from the AK-47 and it had the same behaviour.
Now I have seen some hope in the horizon:
I took the 2.8Amp regulator from KD that I programmed the other day with BLF-VLD2-variable. It still has the leads with plug in the end soldered to it. And I tried to dump that.
I think that it was a success, because the flash dump starts with the same bytes as the original hex file and the fuses dump look just right.
Either I still have a clip issue or the KD print behaves better than the others. I will persue the clip failure thought.
Edited dec.8: It was not an clip issue.
Yes - that is weird. But perhaps the files from sixty545 was corrupt - cause the driver did not at all act like it should.
I will try to read out the 4 files from another BLF AA-Y4E I borrowed from a friend today, and see if I can get consistent files out of it.
Hmm - it is hard for me to see, whether pin 4 of the PAM is connected to the µC. It looks as if it is connected to a through hole - right on the "+" mark.
(The big blob of solder right above the "+" sign, is the positive connection to the LED)
I think I may have mislead you guys :-( :
I just now tried to flash my driver board again, with the BLF-VLD software. I used my own 5-mode version (1/255 -> 32/255 -> 255/255 -> Strobe -> "Soft Beacon") and all of a sudden it worked with both NiMH and Li-ion.
Searching for a possible explanation, I saw that there perhaps had been a short - between pin 4 of the PAM and the positive LED pad (see picture below).
This evening I unsoldered the wire from the positive LED pad, and removed a bit of excess solder - this may have shorted the two previously.
The good news is that Tidos BLF-VLD seems to work fine with both NiMH and Li-ion, in the BLF AA-Y4E :-D
But I succeeded in getting my friends BLF AA-Y4E read out 3 times in a row, every time generating identical files.
If anyone is interested in these files, I have placed them for download here (Removed the link again, because it showed up, that the files were invalid)
So - sorry for - sort of - wasting your time sixty545, having you try to read out your driver board, when it was probably a mistake on my part, for the BLF VLD driver apparently not working on NiMH's...
And now I have found out, where pin 4 of the PAM is connected to:
It actually is connected directly to the positive battery spring on the other side of the board...