On mine, I managed to either cut the voltage divider’s trace or cook the resistor; not sure which. So, mine now has no LVP or battcheck and it takes forever for the SRAM to decay since it has no path to bleed off its charge. Oops. At least I finally got it to flash though. 
The nanjg/qlite drivers are much easier to deal with.
Thanks for the link, gchart. Appreciate. I already made couple of new USBASP yesterday, well, just in case.
About the drivers, I’ll consider it. For now, I just take some pictures, at least the 2 drivers I’ve taken out from the original flashlight to play.
Here the pictures, one show FX-12, the other just Convoy in the back of the driver.
And the zooming out of the MCU PIN as below:
However, to be frankly I don’t know what is the grounded trace between the mcu pin 5 and the other stuff. Is that the “darker green” on the pcb ?
Because what I thought so far about the ‘trace’ is only some soldering which connected between some part, not the ‘trace’ under layer pcb.
Thanks for all the help and information.
The trace is like a thin copper wire, most of which is covered up by “solder mask” to prevent accidental contact. It shows up as the lighter area.
I’m on my phone, but let me see if I can find something to sketch on your image with in a sec.
Thanks before. If the “lighter green”, just like shown by ToyKeeper, this picture?
So I need to cut like the yellow line?
Cut here
Edit: just follow this curve. Cutting where you have the yellow line won’t quite do the trick.
I get it know. But it doesn’t have to ‘rounded’ cut, right?
I can make 90 degree cut for the same purpose?
I’d like to try, but seems it’s more easy for me to make that way.
Thanks a lot, gchart!
Edit:
Okay, I try to make similar like this, just same as your sketch.
Yup, that works! Try keeping it close to the MCU pin. You don’t want to separate the resistor from the 7135. And if it doesn’t work after your first cut, go over it another time or two just to make sure it’s cut all the way through.
And no problem. Good luck and happy flashing!
For me a straight cut has worked best.
Thanks for the real example, Lopan. :sunglasses:
I try to flash driver but got error and not working driver as result. :cry:
Also tryed to flash original fw I saved from driver but same error.
Error
What I flash
What I read
Any advice?
Sorry, I don’t have any experience with that software. I use Linux for my building and flashing.
I apologize if you’ve done these already, but here’s a few questions to try and isolate the issue:
It looks like probably a pin mismatch between the clip and the flashing device. That can allow flashing to appear like it’s working until the verification step.
Weird thing is I can write fuse settings and EEPROM and even erase chip, but when I write Flash i get mismatch.
Forget it. Tryed now with MVH AVR which newer worked for me before and it flashed it. :+1:
Maybe my PC has some problems I don’t know about. :person_facepalming:
Thank you for you help anyway.
I really like this thread, but I feel the numbering of the pins would be much easier if all the diagrams were consistent. There is no need to have different numbers in different diagrams for the same pins. I found this pretty confusing when trying to wire up the clip, and it took me a minute to realize the numbering was not consistent.
Also PLEASE add a note that if you use the wrong fuse #'s you will brick your board (Like I just did trying to flash my atiny25 version of the MTN board). The fuse values for atiny25 were not in the .c file but in the bin/flash-25.sh file http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/head:/bin/flash-25.sh The values in the .c file appeared to be the same, I figured I would give it a go and just re-wipe the chip if something went wrong, I didn't know this was irreversible and would brick the board if you used the wrong values and thus I have bricked my driver. Boy do I feel stupid now!
If you use tiny13 fuse values on tiny25, it’ll configure things like this:
It looks like that tells it to use external clock divided by 8… and with no external clock it might just … stop? Would probably not be recoverable without a high-voltage serial programmer like RMM has, since the usual flashing procedure requires the MCU to be running at a few MHz.
It’s worth noting that one should remove the MCU from the driver before using a HVSP. The extra voltage can fry other driver components.
I did see some /8 in the source code but had no idea what it was for. Just thought I would be able to wipe the MCU if something went wrong, so I moved forward with it. Ooops time for a new driver, or new MCU and hot air reflow station. I'm a bit worried about trying to flash something again, boy do I feel stupid now.
ToyKeeper Can you translate what your seeing in the link above that would indicate a red flag? Nice link BTW, seems useful if I could understand it :)
Mostly, that it’s set to use an external clock… but there is no external clock. So it won’t tick. If it doesn’t tick, it won’t respond. The MCU must be active and running at a suitable clock speed during reflashing. I discovered this when I under-clocked one to 128 kHz for a test and then couldn’t change it back. RMM has equipment to recover from these things, but I don’t.
Link to HVSP fuse resetter:
http://homepage.hispeed.ch/peterfleury/avr-hvsp-fuse-restore.html
That’s all I can tell you, though, because I’ve never built one myself.
Take note of Toykeeper’s warning in an earlier post: remove the MCU from the driver first, or the high voltages are liable to damage other components on the driver.