Attiny25/45/85 FW Development Thread

I don’t know which MCU the Bistro firmware was written for. Since you said you have memory problem, it is not likely to be a fuse problem. Instead, it points to one of the main difference between the MCU’s:

The ATTINY13 has 64 byte EEPROM
The ATTINY25 has 128 byte EEPROM
The ATTINY45 has 256 byte EEPROM
The ATTINY85 has 512 byte EEPROM

Therefore:
ATTINY13 and ATTINY25 can compile with uint8_t or int8_t and use only LOW byte address.
ATTINY45 may fail with int8_t and should use the unsigned uint8_t only.
ATTINY85 may fail with int8_t and uint8_t and should use int16_t or uint16_t. Both EEARH and EEARL must be set. When using C, EEAR should work (but of course depends on the C compiler versions).

You can expect memory may not work properly across all three MCU’s. Unless the Bistro firmware is limiting itself to the first 128 bytes of EEPROM, it may be storing your memory in nonexisting eeprom locations.

When I reworked my ATTINY13A firmware for the ATTINY85, I had to modify my EEPROM functions accordingly.

Suggestion:

- Re-burn your firmware with the fuse setting you are using, which should reset all your memory pointers and erase your EEPROM. If it works immediately after re-flashing, do an eeprom dump. Save that file.

- If re-burning doesn’t temporarily remove the problem (and you are using ATTINY25 and 0xe2, 0xdf, 0xff), eeprom space is not the problem. If it works immediately after reburn, continue.

- Keep changing so it keeps updating eeprom. After just under 64 times do another eeprom dump.

- Keep changing so it keeps updating eeprom. At just under 128 times do another eeprom dump.

- You get it, do it at before 256 times and before 512 times.

- If it fails before then, make sure you do an eeprom dump immediately after you noticed the failure.

  • After the eeprom dump immediately after failure, try changing mode a couple of times (and note how many times), do another dump. This is the last one needed.

I don’t know what you use to flash, so I cannot give you the whole command, but after your burner specific stuff, it should be like:
avrdude avr_burner_specific_params -U eeprom:r:readin.hex:i
This run saves your eeprom into file readin.hex. Since you will be saving more than one, name it read128.hex, read256.hex, etc.

With that info, one can determine if it is overrunning the existing eeprom. When you do have those hex files, upload it. I’ll take a look.

Bistro is written for the 25. The Group buy for the X6-X5 pair is using Bistro on a 25.

Bistro builds for me on Atmel Studio 7.0 at 2038 bytes Program memory, 28 bytes Data memory. Tight on code, only 21.8% of data memory used.

Any idea how it reads the eeprom? Does it have wear leveling?

With my own home-made firmware (ATTINY13 version), gcc reports I use only 6 to 8 bytes of memory of 64 bytes. But in my eeprom read routine, I use 38 bytes of buffer (plus more local variables). It actually fails when I use >38, the total 64 byte RAM is not adequate. Stack-full! Stack usage is not part of “data” but certainly use RAM space. The compiler cannot always determine how much stack you are using. So total DATA is not the same as total RAM usage.

EDIT:
One more thought. If it is a group-buy, is it a fully made flashlight or buyer-modified?
The same fuse setting and the same software should work exactly the same. The only variable there is start-up condition and/or hardware issues. That it is a memory problem (he is not calling out other issues) points to probably it calling different functions (start up condition) being different or hardware problem. Calling other functions will mean different stack_usage which may affect eeprom reading function.
Is there any star selected options? If so, what are they? Does it fail with default options only?

Yes - all our recent firmware versions use wear leveling (mode memory and config settings).

Oh boy lots of Q's... In some of our recent BLF Group buys, we try to get a true "modded light", and it's performance/function, to the masses, and this group buy for the BLF SE X6 v2 and X5 is exactly that - cannot be bought anywhere, no modding required, fully working at high performance, but to tweak it out fully, you need to add bypass's on the springs. It's also somewhat high-end for a budget light - X6 is SS/Cu and the X5 is 100% Cu body, so these are very special. But you can also buy the pair in regular black anodized alum for cheaper.

Not sure bout star options - I don't use them - might be a compile option.

Tom E, thanks for the many answers.

I think Pablo E.’s flashlight failure will need some deep debugging - perhaps hardware. While less likely, even factory-made stuff can have dry joints. Hopefully he will find some solution here.

I am just not experience enough to draw it closer to help Pablo given the limited info. I am suspicious of the eeprom reading function. I made my eeprom wear-level codes use the stack because I was RAM-short with the ATTINY13A. With eeprom read, it needs a large buffer to reduce the number of reads. Since it needs to be done just once at the start, it makes perfect sense to allocate it on the stack and once finished, the rest of the program has lots of stack space to use. The original Bistro developer likely made the same choice I did since he uses only 28 bytes of fixed data. Stack issues is harder to debug as each extra step may depend on condition and thus not always taken. One of those extra step might just mess up the stack enough for stack space to run out, or overwrite something.

TK wrote bistro and she's a she Smile, but she also based it on previous open source driver code. Well the bistro firmware itself is well proven - Halo for one has it installed, and I think the X6/X5 sample units received in the group buy are running bistro.

I've gone thru the eeprom code once before, looked again nnow. We do eeprom_read_byte() calls in a loop (in Bistro that way), so no need to buffer anything. Why do you care to reduce the # of reads? It's write cycles that are limited, and didn't think any issues with reads?

In my Tiny85 Narsil firmware, think I use 2 bytes to store config data w/wear leveling.

re: “Why do you care to reduce the # of reads?”
Speed. The datasheet said it take 1.8ms per read. Reading 512 bytes one at a time will take almost a full second (0.92 seconds). That is a visible delay before the flash light turn on. So, I went for a block-read to (hopefully) reduce the time it takes.

re: “In my Tiny85 Narsil firmware, think I use 2 bytes to store config data w/wear leveling.”
I am a damn optimist. I use 256 for each byte. I also have two bytes of long-term memory using up all of 512 bytes of eeprom! That would be 25.6million clicks. I want to make sure it would last till I meet my maker, if my click switch itself lasts that long… Like I said, I am a damn optimist.

By the time you click 25 million times, we'll be getting 5000 lumens in a keychain light with no heat Smile - time for an upgrade has long past.

Hi Rick,
i don’t discard a hardware failure.

I thought also i have been sold wrong capacitors as, if i am not wrong, too big cap could explaing “next mode” memory; right?.

As for dry joints, i am planning to do a second driver, this should shed some light on the subject.

Tom, could you confirm your mode memory doesn’t work properly?

I got no modes at this point, so can't test mode memory - all I get is config mode - that's it.

Ahem, it is 25.6 million. Failing at 25 million will be a premature failure. Like I said, I am an optimist…

re: “I thought also i have been sold wrong capacitors as, if i am not wrong, too big cap could explaing ”next mode” memory; right?”

I have not peeked inside the Bistro firmware code, so I would not be able to definitely answer that. I have read JonnyC’s OffTime capacitor code. If Bistro is like JonnyC’s work:

- an oversize capacitor will length the bleed-off time. It should have the effect of lengthening the duration of what it calls quick-click. So a longer wait between click is accepted as the “quick”.

- an undersize capacitor will shorten the bleed-off time. It should have the effect of speeding up time. If it is too-awful-small (too far below 1uF), you would not have quick click at-all. the fastest on/off would still be seen as power-off-too-long.

Do you have a DMM with capacitor measurement?

As for me, I did not use an off-timer capacitor. During my testing, I found my capacitors to be varying too much. With multiple flashlights, I do not want to individually calibrate each capacitor for the “off timer count.

So, in my code, I set a flag at power on and increment the mode and save. After a delay, I cleared the flag before I restore/store the mode memory. So I know with the flag whether it was turned off quickly last time (before the delay expired), or not.

ToyKeeper has a code repository. :bigsmile: In addition to her own code, she has also archived lots of other peoples open source code. http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files All of her code would be in “bin” and “ToyKeeper”. Other people’s code is under their respective BLF usernames.

Bistro in her normal repository: trunk/files/head:/ToyKeeper/bistro/
Bistro in her testing repository: tiny25/files/head:/ToyKeeper/bistro/

Thanks for the link! There is a lot I can learn from in there.

Given what Tom E said, I no longer think the eeProm routine is possible the source of the issue. I think Pablo E’s issue perhaps lies in the capacitor as he suspected, and perhaps other hardware issue.

I am going to dig into those source code and see what trick I can learn.

As far as I can tell rev.165 from her firmware trunk, worked for me. X6SE XM-L2, wight’s A17DD-L with ATtiny25, bistro rev 165, command line to flash:

Those are the fuses TK wrote she uses in this revision. So that’s BOD@1.8V enabled, 8MHz +4ms

Now with that revision 208 from her testing trunk, there are no significant differences as far as fuses should be concerned, right? Diffchecker

Fuses mentioned in bistro are just in the comments. Fuses in /bin/flash-25.sh is active code. I’d go with those as the newest. But the different fuses are located in the repository branch that she said was for “testing”. So only try code in that branch if you want to test out new code. Be aware that it might not have been tested much, if at all. No complaints if it doesn’t work, bricks your chip or eats your cat. :smiley:

EDIT-see additional info also.

The difference in the high fuse settings of 0xD2 vs 0xDF is enabling two BOD.

If memory serves (from reading the datasheet a couple of weeks ago), BOD should trigger interrupt, but in quick scan of the code with the repository link given earlier, I didn’t find BOD interrupt handler. It may be there and I missed it.

If I am right (again, from memory of what I read two weeks ago of the datasheet, and did not do a detail read of the code, just a quick scan), it will, during power out, trigger interrupt. If interrupt handler is in the code and I missed it, it will do what the code is designed to do. Without interrupt handler, the jump table should jump to a clear-interrupt and return. So it will either do a job, or do nothing if nothing is implemented.

So there should be no harm done.

EDIT: I reviewed the datasheet. The BOD generates a RESET interrupt.
After rereading how the BOD works, I would go with BOD disable instead of enabled unless I have a plan of what should happen when brown out occurs. The datasheet (Section 7.4.3) recommends BOD turned off if not needed.

That’s what i was afraid of, that even the longest click acts as a quick -clik, it would explain next mode memory; but after being the flashlight off all the night, it still starts in next mode, so i think i may discard this possibility as there is no so big 0805 cap.

That’s is the problem, i have no one.
I have tried to have access to one with no luck for now.

Interesting, but too advanced for me :open_mouth: software is something i have started to study this year, maybe at the end of the grade i could follow you :bigsmile:

Thanks, i’ll test it.

Actually, overnight may not fully discharge a capacitor because the bleeding off slows down a lot as the charge get lower and lower. Before trying what is below, give your cap 24-48 hours to discharge. See if it makes a difference. When I was testing (10uF), I certainly did not bleed it dry at 4 hours.

Also during my testing, I was continually reading my capacitor. It never discharge to below a certain point. Just the spikes was able to refill the capacitor enough to prevent it from dropping further. A large percent of charge remaining on a 1uF is a much much smaller percentage of (perhaps spike-refilled) charge on a 22uF. Since you don’t program yet, you can’t change the trigger point and test.

If 24-48hr discharge doesn’t work, pursuit other avenues first. Go try your fuse settings (I made some comment about that near the end of this reply), if that makes no difference, try this:

You may also be shorted to V+ or another voltage source like the PWM pin or the ADC pin. So, once you turn it on, it immediately see a lot of voltage where the off-time cap is.

The short could be at the capacitor or at your chip. Visually check with a loupe or any kind of magnifier you can get a hold of. It may be visible. At times, it is very hard to see.

To confirm, best would be with a DMM, but since you don’t have one:

Do you have an SMD resistor around 10K that you could “borrow” from another board? If not and you have another NANJG105c, borrow the 19.1K or the 4.7K, whichever is easier to remove. Replace your capacitor with this borrowed resister.

- If you have a short at the chip’s legs, your MCU would still “see the world” as if your capacitor is full.

  • If your short was at the (now removed) capacitor, with the resistor only, your MCU would “see the world” as a capacitor that is always empty.
    That would tell you if you need to desolder the chip and re-do.

If you can’t even get a hold of a resistor to do the test above…See if you can find #6 pencil. Draw a thick line across the two ends of the capacitor - thick as in 0.5mm thick, thick enough to be visible. The carbon from the pencil would serve as a crude resistor, but you really have no control of the resistance beyond the thickness of the line. Make it thick line, and report the result. It should discharge your capacitor sooner. If only you have a DMM, you can test if your home-made capacitor is making good contact and what is the resistance. Now we have to do it blind…. Try that and report the results. (If you do try this, clean up afterward. The bits of carbon left could shake loose and could mess you up else where.)

You can also skip the pencil and just to assume your have a short somewhere and try again. De-solder the chip and the capacitor and try again.

Well, if you are not 3000 miles from New Jersey USA, I’d say come-on by and use mine. If you can, get a cheap one. Get one with capacitor measurement would help. I don’t know if you guys can order stuff from China cheap. A $10USD meter would do nicely since –1% or even–2% is adequate for this kinds of stuff.

Next to the screw driver, DMM is just about the most important tool whenever you start digging around with things like this.

Software is important if you are interested in playing with electronics and the kinds of things like a driver. The knowledge of one software-language is very transferable to another. So, you may actually start with picking up some concepts using something like JAVA (not JAVA script) with tons of resources so you can do things like declare large arrays with disregard. Freed from most resource constrains, you may learn quicker than always having to squeeze the last byte to the last bit.

After JAVA, Arduino is a good stepping stone to the ATTINY. An AVR based Arduino like the UNO is cheap. It has more tools and resources to learn than trying to learn with the TINY right off the bat.

Good luck with that…

Good luck, it is unlikely BOD has anything to do with the problem, but you never know. If there is a dry-joint or some hardware problem, it could be that it does a double start: crash first time, then start again. That would advance to the nest mode.

Hi Rick,
thanks for all you effort.

I’ll leave the light off 48h to see what happens.

I meant i have no DMM with capacitor measurement, of course i have a DMM :bigsmile: , but without this feature.
Sorry i’ve made you write all that.
I thought only the most expensive ones had this option, now i am looking for my credit card :money_mouth_face:

Ha ha i haven’t used a pencil for that since my computer overclocking era, I have good memories of that time.

JAVA is the main subject in the grade i am studing, i hope in 6 month i can help in this kind of threads, if C is not much different.

I’ll try all the possibilities, i hope to back only with satisfactory results.