Attiny25/45/85 FW Development Thread

^

So is it the driver board that is the problem? I don't know what " I buzzed out the legs and all looked good." means. I've been flashing chips on the 17mm board without issue, but I don't recall if I have flashed any on 22mm boards.

Tom E wrote:

. . . ImA4Wheelr - what is that hugh part on that driver pic? . . . .

That is a LDO Voltage Regulator. It's an LM2936. I'm using it instead of doing the Zener mod so that I can have a momentary switch and greater than 1S cells and not have to worry about parasitic drain if I accidentally forget to lock out.

EDIT: Fixed my the above quote. Pasted the wrong text.

Sorry, updated post #243 - I tried a different driver altogether - a 17mm as opposed to a 22mm, both wight designs, both FET+1 boards, both have the same verification problem: can't seem to write/program anything to the 85V when mounted.

- The 22mm is fully populated

- the 17mm is bare with only the 85V mounted

I edited my post above as I had quoted the wrong text.

Hmmm, Could you provide a clear pic of one of the offending boards/drivers? I wonder if there is a trace error. I know I have repeatedly flashed the 17DD+1 with no problems. I think I have flashed the 22mm too, but not sure. I tend to "air" flash first before building a board because it is easier. But I have reflashed several other drivers without issue. So it seems like it may be the batch of boards you got.

I will try to flash one of my 22mm drivers today and report back.

I buzzed out all traces on both boards, so the one 22mm board works 100% perfect - always has, with both a 13A that it had, and later a 45, then a 85 (it works with a known good version of firmware - what I'm testing now is new). The 17mm is a bare one I had around - never had a bad one and I've built maybe a dozen or so. I'll take pics of both and poste them.

I still don't know what "buzzed out" means. I'm assuming it means you checked for continuity from pin to end of each trace and lack of continuity to the other pins.

I looked at my programmer. Instead of saying "Lcsoft Studios" like in the picture Halo... posted in Post 241, mine says "LC Technologies".

I think that (checked continuity) is what he meant.

I haven’t been following this thread closely but is Tom E’s problem that he can program the 85 chips when they are not connected to anything, but when he solders the 85 chip onto a populated driver board, he cannot program the 85 chip anymore?

^

You are correct Ohaya, but he is not having the problem with every board. He has at least one that works fine. Right now it's a mystery as to what is causing the problem.

Ahh - no, I don't have any board where programming on it worked repeatedly... Even when I worked with the 25's and 45's, I sometimes could get it to work the first time on a board, then never again. Maybe buzzed out is an 80's term - yes: put your probes on the board, if the DMM buzzer sounds, it's got continuity . I also checked for ground shorts, cross shorts, etc. Everything looks good on the board, and certainly the one 22mm driver I've been working with all along, it works.

Been doing a bit more research and it almost acts like I soon as I program it, the "lock" bits are getting programmed, or the serial dnld is being disabled (fuse bit). Yet, when I take the MCU off the board, I can program it fine.

I only have one flashlight I deployed my new firmware in, and that's a EE X6R with a 45 in it.

Have you shared your X6R firmware somewhere? I’m looking for something with temp monitoring that would work on a 25v for my 7g3cs (dual switch).

I’m also looking for a very simple (3-4 modes) clicky firmware with temp monitoring for a different project.

No - I've done nothing w/temp monitoring, and my adv. e-switch/brownout development is stalled til I can figure how to get the dnld working reliably.

So I had a attiny85 (not 85v) and did a couple tests. I don’t have any of wight’s boards. I do have a different 17mm fet + 7135 board. Beta test design meant for attiny45/85, so no bending legs.
Air clipped, flash verifies ok.
Tiny85 soldered onto the board (otherwise unpopulated)…. flash verifies ok!
Added the diode and 7135, flash verifies ok.

I did buzz out :smiley: all the soldered connections just to be sure all components so far are making contact to the board / soldered ok.

I’m afraid I have no insight into why mine is flashing fine while yours isn’t Tom. :ghost: Except the previously suggested… madness! I also don’t have any other tiny85s, just the one. My programmer is the common usbasp clone, blue (LC Technology) version. Clip from aliexpress $1.80 link (but the clip received actually matches this one instead).

Thanks Halo. Interesting... Ordered the $2 clip from your AliExpress link - for $2, it's worth to use it at least for a backup. I did order a similar one off of eBay, shipped from China and not here yet.

I got 2 other driver OSHPark boards with the widened footprint, but didn't want to try them since they are both new untested - one from PD68 for the X6R, one from Richard. I'm thinking of cutting traces 1 by 1 on the bare board (throw-away anyway) to see if the leg traces has anything to do with it.

Hoping I'll have more time today. Yesterday I had a couple hundred Habanero peppers form the garden to take care of - got a batch jarred up.

Could you provide what fuse settings you used, maybe the full AVRDude command to dnld? Thanks!

Oh yea, I did flash the fuses separately first. Fuses are just 8mhz; startup +64ms (default), SPI enabled, brown out detection disabled. Everything programmed at 3.3v.
sudo avrdude -c usbasp -p t85 -P usb -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m
sudo avrdude -c usbasp -p t85 -P usb -U flash:w:./blf-a6.r155-85test.hex

Ohh - never did it that way - I'll try.

I usually do fuses separate out of habit, since you don’t necessarily need to change them each time. If different fuses aren’t called for then I don’t do fuses when flashing a new hex.
Just tested flashing fuses on my half populated board. Flashed and verified without error.

The problems I have had with not being able to flash the MCU on a board have been components, in particular capacitors. In my case the capacitor has been enough to screw up the flashing process. Took me a while to figure this out, but once that capacitor was removed I could flash fine.

So what components do you have on what pins? AMC7135s don’t appear to interfere with the flashing process, I’ve been able to have them on any pin, but not so with capacitors.

I have a 85V on a bare board - no components at all, accept the MCU, and it won't flash. The bare board is a wight FET+1 driver.

^

When reading about how to make ground plane polygons, one reference said certain configs can create capacitance in the PCB. I think wight used ground plane polys in some of his later boards. Not saying this is the issue, but it might be something to consider. I seems unlikely though as we all should be having the same issue (assuming our programming and computer equipment are working about the same).

I guess you could set your DMM to measure capacitance and then measure between pins. If you do this, short the pins (without power connected) to discharge and any stored charges that may be in the PCB before taking each measurement.

EDIT: Corrected typo

Ok, I "think" I fixed the problem. I'm not too excited cause time will tell... The apparent big major problem is the pinouts of the USBASP V2.0 is not as documented, maybe... flashlightwiki seems to be wrong, at least not matching my USBASP. Also the Protostack "AC-PG-USBASP USBASP AVR Programmer" manual seems to have it wrong, even though that's where I bought the USBAVR from! Also, the ProtoStack doc and flashlightwiki don't match each other for pins #3 and #4. Ground pins are #8 and #10, pins #3 and #4 are something else -- 8 and 10 check for continuity, #3 doesn't. Both my USBASP's are labeled Lcsoft Studio, one bought from FastTech, one from ProtoStack.com, and both show no ground continuity on pins #3 or pin #4.

Ok, so change the ground pin from #3 on the dongle to #10 -- all flash programming issues seemed to have gone away. So far I haven't bricked any MCU's also, and it works multiple times without a hitch. What I'm doing now is setting the fuses separately from doing firmware dnld - two different batch files, ala Halo (thanks!). This in itself though did not help, did not fix the problem, but somehow it recovered an 85V I thought might have been bricked (no longer programmed in air).

Someone please confirm, or not, this insanity -- if we all have been wiring this up wrong and getting away with it for the 13A's...

I'm really, really hoping this is legit. WinkSmileCool

I can confirm, no ground on pin 3 of my blue LC Technology version. Pin 10 and 8 are ground. By the way pin 4 is suppose to be txd, goes along with pin 6 rxd on the LC Technology / LCsoft version. It was broken out for future use or alternative use of the board.