Tom E wrote: Madness I Tell You!! Sheer Madness!
Which usbasp do you have? Blue one with a slow SCK jumper?
I think the chinese usbasp firmware might not respond to the avrdude -B command. I'd recommend trying the slow jumper.
xkcd.com/1603 Li-ion battery safety 101.
I feel for you Tom E. I cant offer you any help except my support for what your doing.
My current and or voltage measurements are only relevent to anything that I measure.
Budget light hobby proudly sponsored by my Mastercard and unknowingly paid for by a hard working wife.
djozz said "it came with chinese lettering that is chinese to me".
old4570 said "I'm not an expert , so don't suffer from any such technical restrictions".
Old-Lumens. Highly admired and cherished member of Budget Light Forum. 11.5.2011 - 20.12.16. RIP.
Hhhmmm, I got two dongles - quite unusual I would think... I think they are the same config - I'll check, after another beer. I do not have a drinking problem - or a flashlight problem...
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? . . . .
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".
ImA4Wheelr wrote: 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 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.
My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03
Major Projects: Illuminated Tailcap, TripleDown/TripleStack Driver
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’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.
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.
Did a little more searching, and in Hoop's useful thread on how to flash a Nanjg (http://budgetlightforum.com/node/36216), he references the flashlightwiki page, which I have to assume is wrong for the USBASP's we are buying now, but in his Post #1 he lays out the wiring for ground to go to the proper pin #10 in one set of pics/info (the clearest defined one), so maybe lots of guys have it right. Back when I started, we used flashlightwiki as the ultimate guide/ref.
Here: http://www.protostack.com/accessories/usbasp-avr-programmer, is a link to Users Guide that shows pin #3 as ground, pin #4 as TXD, but it seems clearly the doc is wrong about pin #3.
Protoshack, $18 for a usbasp clone?! At least double check and fix your pinout for $18.
Halo... wrote: Protoshack, $18 for a usbasp clone?! At least double check and fix your pinout for $18.
Yes - I bought mine before I knew of FastTech, and the "Perfect Modes" thread and flashlightwiki were the only sources of info, so it was posted there ProtoStack had them. I got my latest AVRDude version from their site - drivers that work under Win 10. They actually have manuals, support, etc. , but after we found them on FastTech for cheap, we all got them from there. My FastTech one though has a bent USB connector - poor mount on the board.
This is great btw... I'm off writing code, testing, debugging, etc. Already re-dnlded 3-4 times without a hitch !!
I’m cheap, I like searching ebay and now aliexpress. They sometimes have better prices than FT / BG. Plus it’s easier to get a refund on ebay if the item never arrives or is doa.
Ok - got my 8 * 2 * 2 mode configurations working. Didn't take long once I could dnld. Works awesome so far - 8 sets of modes in lo->hi or hi->lo order, and mode memory or not. Just under 2K of code space.
I like how it works so far. I can add a couple more options now.
Are you running at 8mhz on the tiny85? Have you tried 4mhz? I think 4mhz should increase reliability for the tiny85 (non-v) at lower voltages than it’s official 2.7v min. Then we can use the cheaper non-v 85s.
I don’t know if there reallyis the need, I mean is anyone going to want a LVP cutoff below 2.7v anyway? And official specs are usually conservative anyway, jeelabs sells atmel boards that run outside of specs and have never had a problem. But still I’d idea of helping to keep it reliable at lower voltages, just in case.
Yes - 8 Mhz. No, didn't try 4, but tried 6.4 Mhz, and even though I set F_CPU for 6.4, the timing of _delay_ms() was way off, like a factor of 5 times slower. Not sure why...
[Back to Top] [Home]