2. is possible; I might have simply forgotten to flash the firmware. That’s rare, but it happened once, it may happen twice.
1 & 3 may be, the incident emptied the whole cell in 30s, some ugly things may have happened.
Maybe you can swap in the MCU from the previously sent driver that was damaged by the mail service?
Why didn’t I think of that? I kept the parts from that driver and it didn’t cross my mind that the mcu is still flashed with your firmware. At this point swapping the mcu is probably what I need to do. I will have to hand solder it. I’ve not yet done that. Hopefully I don’t turn it into a junk yard of components:) I’ll let you know when I attempt this and how it goes.
If anyone still has an idea how to salvage or test the mcu of the driver I ruined, please let me know.
Is there a way to tell if the mcu is flashed or not. If so, it would be good for me to check before I mess with it. I have all of the hardware required to flash drivers myself so I could connect the clip and sub programmer to chech. HOWEVER, I have not yet learned how to do it. Maybe now is the time for me to learn. Anyway… Thanks to everyone who has replied to this thread!
Yes, I believe so. If the lock/protection bit(s) are set then DrJones has flashed something onto that MCU. If a mistake was made it could have been either no firmware or the wrong firmware; so just because the MCU was flashed doesn’t mean that it should work. An empty chip should look different from a programmed chip when attempting to dump. I have no personal experience with dumping these chips (only flashing them), but see here for some information: AVR Basics: Reading (and writing) flash contents | Evil Mad Scientist Laboratories
Personally I think you’ve already done all the testing you need to at this point. The driver does not function and DrJones has suggested an MCU swap using an MCU you already have… so that’s probably a good next step.
Personally I do not think that a shorted battery in the body of the light would normally damage a driver like this one. A mistake sounds like a good explanation, or maybe corruption of the memory if the DrJones firmware depends on that.
Thank you for those videos! They are of great help! I am going to attempt to swap mcu’s then. Not knowing what happened to the other one really bugs me though :SICK: well not that extreme but I do wish to find out exactly what I did to it.
You are welcome. Two things I neglected to mention in my previous post:
The ATtiny MCUs are very hardy as far as I know. Destroying them accidentally is not easy. I think that other members will agree with me on that point. Other than a very high voltage (>6v or so) or ripping legs off they seem to survive fine. You probably did not kill yours.
The videos I linked to don’t necessarily show all best practices! They are merely demonstrations, so please take them as such.
Well I will report back. White, you were right. I swapped the mcu out for the other one I had left from a damaged board. The results are the same.
There is not much left that could have happened. I’m hoping I will be embarrassed by overlooking a small but important detail. Like connecting the led backwards or something like that. Now let me ask… The lead from batt+ is a common path for each die’s pos+ terminal. Right? Then each separate lead from the boards four outputs goes to each neg- trrminal of the emitter. Correct?
The only other components on the board are the diode and the capacitor in series from batt+ to gnd(the mcu Vcc pin is connected to a trace from between these two components. Could one of those components have gone bad and would that affect wether or not the mcu will turn on? I think these are for reverse voltage protection and off time memory. IDK but maybe one or the others is causing a problem.
You’ve already shown that the LEDs are hooked up correctly by doing the test comfychair suggested.
The capacitor you are referring to is a “decoupling capacitor”, it is not for offtime. If you get battery voltage (or battery voltage minus ~0.2v) at the MCU’s Vcc/Vdd/whatever pin then you do not have a problem with the protection diode.
Post large, detailed photographs of everything involved. The LED MCPCB, the wiring from the MCPCB to the driver, both sides of the driver, pictures specifically showing your soldering job on the swapped MCU, etc.
Strange; that I forgot to flash the driver 2 times in a row sounds unlikely to me. Hm.
But indeed, usually the ATtinies survive a lot: Someone accidentally applies 2*16340 to H17F, the LED died, the driver survived.
Oh, just reread #13, your pin numbering is wrong: 1 is lower left, 4 (GND) is lower right, 5 is upper right, 8 (Vcc) is upper left. Pin 3 is the switch.
A few more tests…
Measure voltage between pin 8 (Vcc, upper left) and 4 (GND).
Use a small jumper wire or fine tweezers to directly connect pin 8 (Vcc) to pin 7 or 6 or 5 or 2.
Maybe it’s the switch?
Test continuity between pin 3 (switch) and 4 (GND) when pressing the switch.
Use a jumper wire or fine tweezers to connect pin 3 to pin 4.
Oh yes. I wasn’t thinking when numbering the pins.
3.75
Jumping 2,4,6,7 to pin8 turns on the corresponding color. Fully bright.
There is continuity between pins 3 and 4 only when the switch is pressed.
Jumping pin 3 to pin 4 does nothing.
This circuit is very simple so this is confusing to me. I can’t see what else could be wrong. I’m going to retest everything I can, review my methods and see if I’m missing something.
PPDB22 - as far as determining for certain what’s wrong… I would say that we’re back at the point you brought up earlier. That is to say, can we determine whether the MCU is blank? We can. (We just can’t determine whether the MCU is programmed incorrectly.)
Once that’s out of the way, adjust the command for the ATtiny85 and for dumping rather than flashing. I believe that it would look something like this: The guide actually covers this and provides a command, so all that’s required is swapping “T13” for “ATTINY85”….
Ok white. I think you are right. It’s time for me to learn to flash. Pffff… It’s something I really want to learn to do(especially because I have a handful of attiny drivers with flashy modes) but I’ve been a bit intimidated.
One of my challenges is that my days resemble the move “ground hogs day”. Don’t know if you’ve seen it, but the actor tom hanks wakes up and it is Groundhog Day everyday. He experiences thing over and over but every morning when he wakes up he has accomplished nothing. In the movie, it is everyone else that forgets(never new) all that has been accomplished. Which is what it is kind of like for me. Every night my brain resets and I forget most of what I’ve learned. So I read things over and over again until I am able to learn fast enough to cover it all in one day. Once I’ve learned something it seems to stick around but the process of learning is difficult.
I’ve worked out a little system now where I stash the things I learn throughout the day. Learning to flash will put my system to the test;)
Dr Jones
You are MORE than generous! I fear it’s me who has messed up at your expense. I will continue trying to figure out the problem here and if in the meantime you are willing to send another, pm me with shipping and parts expenses. I thank you for your help!
What caused the original dead short, just the nose of the battery pushing the button too deep and then contacting the ground part of the retainer? And then it was totally unrelated that there was also some other problem with both MCUs?
It’s highly unlikely those two (three?) are unrelated, but not impossible. ‘Highly unlikely’ things happen all the time.
What does your meter show, checking ohms from the battery spring to the ground ring? It should be some very high number but not a complete ‘O/L’. Like 30k-50k or something.
Those last tests showed that everything else but the MCU is working; further tests on anything else are probably wasted. I can think of two possible reasons: a) You killed them. But that’s quite improbable; the first with 10Wh from the cell blowing out in 30s (that would be 1200W, hm, probably not, instead the cell probably killed itself. There must be still some energy left in there), that might have done something, but the second? b) I actually forgot to flash BOTH drivers. Not very likely either, as they weren’t made on the same day. However one of those reasons it must be, and since everything else survived the ‘incident’, a) is even more unlikely than b). Quite embarassing.
I’ll additionally send you a (flashed!) MCU to swap in, so you’ll have 2 working drivers then. And a H17F+ (you’ll be the first to have one).
Ya. Idk? There really isn’t much to the circuit component wise. Which says a lot about your abilities to create such firmware that is stable with so little components. Like you said, every possibility seems unlikely. This was the first time I transfered an mcu, but I watched a number of videos beforehand and it when quite smoothly. I did not have to use much heat. I soaked it with flux, wicked the solder, then jently popped up one side at a time by dragging my iron from one pin to the next. To reinstall, I aligned and clipped the mcu, then one pin at a time I touched the iron tip to the board, then to the pin and then pulled away the iron. After, I checked for continuity between each pin and the end of its lead to ensure they had latched to the board. I also checked for shorts. So, I think I did ok. That said, things can go wrong even when doing good. I have been biting my nails waiting for the H17F+! I don’t know what to say! You are being very kind to me. Thank you! I’d like to say more… I’ll start preparing a review right now:)
Comfychair, I measured infinate resistance between spring and gnd. I measured 4.67k from Vcc to gnd. But I don’t trust my measurements on this one. It doesn’t seem right to me? That was without power applied.
