These are the fuses I used when flashing through avrdude. They are straight from tks bistro tripledown .c file. So not sure if it’s correct or not?
Low: 0xd2
High: 0xde
Ext: 0xff
Thanks. The brown out detection at 1.8V is enabled with those fuses. In that case my guess about what your issues could have been are probably incorrect.
I don't know. It's not clear that we've established that 1.8V is a valid BOD level for non V chips. It seems to me corruption could be possible on random chips at that level if that's what you're getting at.
Are there different fuses that you would suggest using instead?
Not sure who you're asking. I think Mike C was getting at the possibility that if BOD is not turned on the chip can run at voltages where it starts to operate unpredictably and anything can happen, including I guess (not sure) corrupting some memory (my guess of his idea). I guess your fuses are pretty typical.
My point, and we discussed it earlier, is that it is very unclear in the documentation if the 1.8V brown out detection is actually guaranteed to prevent this for the chips that are not rated to operate that low, ie the standard non-V chips. I guess the fuse to suggest then could be the one corresponding to the 2.7V BOD. I'd have to plug it into a fuse calculator. The BOD threshold has a loose tolerance and this could marginally impact how low you can take your battery. More importantly it would limit the ability to run at low voltages for this new off-time trick, OTSM or whatever we're calling it.
Still, it's just not clear (to me at least) that setting BOD at 1.8V is really "legal" or entirely safe. I don't think there's wide spread evidence of any problem with it. But that doesn't mean there aren't occasional problems with it either.
Yeah, you are both right, it’s corruption I was thinking about. When working with the OTC less design I had some intermittent issues while stress testing that I couldn’t explain or weed out, no matter what I did. I saw erratic behavior maybe once in 20 or 30 continuous off presses of different durations. I finally managed to figure out that it was flash corruption after one of my mode bytes got corrupted from 10 to 255 (or close). During this test I was not using EEPROM at all, all modes where hard coded, and having the light off for extended period didn’t reset it. So that particular mode byte in the FLASH memory had been corrupted while everything else was OK. Other times the light wouldn’t start, wouldn’t change modes etc etc, even after having it off for ages, and I couldn’t figure it out. That single corrupted mode byte was the key.
So I enabled brown out detection at 1.8V (I am using 85Vs) and have stress tested it for ages, and all those weird issues I’ve experienced are a thing of the past. Now I’ll get a brown out induced reset as soon as the voltage drops too low. Brown out detection does draw power though, so I’ve had to increase cap capacity. 100uF can give me a second or so, but almost all of my driver designs can actually fit 1206 caps so I can go higher. Only one driver couldn’t fit a 1206, but it could fit another 0805 so on that one I’ll be using 2 x 100uF 0805 caps.
In a normal flashlight when you switch the voltage off, the MCU looses power rather quickly. With the OTC less design the MCU lingers a lot longer in that low voltage danger zone, increasing the chances of these kind of issues, but it got me thinking that the corruption probably still can happen on a standard OTC driver with 2.7V MCU, perhaps with near drained cell, turbo mode and/or multiple off clicks after the other. The chance of corruption issues with a normal OTC driver is much smaller than with the OTC less design, but still possible I think.
Depends on the firmware, and I haven’t looked into the other firmware versions that are out there. If the above is what happened to your driver, than you would have to be using the standard 2.7V MCU. You could set brown out detection at 2.7V instead of 1.8V by setting the high fuse to 0xdd. I’m guessing that there won’t be any changes to overall functionality of your driver, but I won’t guarantee it so you’d have to do some testing.
I’ve been listening in and even though I have no clue, trying to learn a bit. So basic question, are 1.8 and 2.7 minimum opporating voltage for different mcu’s? Then the fuses should be set according to the minimum mcu voltage? Speaking in general. As it sounds it’s not always that simple…
There are regular the ATtiny25/45/85 MCUs. These have a minimum voltage requirement of 2.7 volts to guarantee stable operation. Then you have the V versions, ATtiny25V/45V/85V. They have a minimum voltage requirement of 1.8 volts. Although the regular ones can usually run below 2.7 volts, they aren’t guaranteed to.
Brown out detection is basically a hardware safe guard against weird things happening if the voltage goes too low. With it enabled, the MCU will reset itself at the level set by fuses. If brown out detection is not set, the MCU will not reset and will continue doing what ever it was doing (or at least try to). If it is allowed to carry on while the voltage is too low, the flash memory can become corrupted (flash memory is where the firmware is stored). I’ve read it in the datasheet before and didn’t care less about it, having never had an issue with “normal” lights probably because the MCU goes off at once and doesn’t have time to do anything.
With the OTC less design the MCU lingers for quite some time in the low voltage area. Even with a firmware induced reset on low voltage, the MCU still has to run that firmware in order to perform the reset… and as I found out, running software in lower than lowest specified voltage really can cause flash memory corruption.
Thanks for taking the time to explain. I understand much more now. If I run into trouble again, I will play with it some.
If set to 2.7 can it be relied upon for over discharge protection?
If your over discharge protection is above 2.7 volts, then everything should work as before.
The thing about these issues is it’s hard to know what’s going on. In your case it could have been an interrupted EEPROM save by an off click, or something with EEPROM corruption. I haven’t looked at how Bistro works so it’s hard to say. I do know what happened in my case as I was using a very simple firmware with no EEPROM usage at all, and stress testing always produced issues within 30 or so longer off presses.
I would think a BOD shutdown will kill the gate drive voltage and shutoff the light. Maybe voltage recovery would cause some oscillation. I don't know if BOD allows any cleanup routine or sets any flag that can be read on startup, potentially allowing control over hysteresis.
BOD performs an AVR reset, exacty the same as pulling the reset pin low, and sets the brown out reset flag in the MCU status register. THe MCUSR can be read any time after startup as it’s user cleared.
I was wondering if it would keep from over draining the battery on e switch lights that have a parasitic drain when sleeping.
During my tests with running the MCU from a capacitor in the OTC less design, I can see a big difference with brown out detection enabled. With it enabled the MCU will draw several hundred percent more than just having the MCU in sleep mode with a watchdog or pin interrupt enabled. And as far as I know, the detection will not stop drawing power when voltage goes low, so I see only disadvantages with BOD enabled in regards to parasitic drain.
What if yo you used the manual reset you were using but raised the voltage up to say ~2v? Would it net you longer runtimes without the corruption issues?
Ah, ok. That’s unfortunate. Are there any methods out there that keep this over discharge from happening. I’m ignorant on the matter so there might be a common tool that prevents this. Idk?
That’s exactly was I was doing. The manual reset I used was by enabling the watchdog with reset on timeout. As far as I know it’s the only way to induce a reset by software. The problem with that is that on every startup after reset you have to immediately stop or reset the watchdog, because if you don’t the watchdog will just endlessly keep resetting the MCU, even when the power is back on. So you have to have software that stops/resets the watchdog on every startup after reset, and then check if the power is back on. You can’t stop the MCU from doing this when voltage goes below 2V, it will continue to do this check until it can no longer do so. Without BOD the MCU will be trying to run firmware, even if it’s just a simple pin check, and that is enough for flash memory to get corrupted. I did a whole bunch of things which helped minimize the issues but I could never get rid of them entirely.
The only way to stop the MCU from running anything in flash memory during low voltage is by BOD, that’s what it is there for. If you could stop it by any other way, they wouldn’t have needed to make BOD in the first place. I guess you could muck about with the reset pin, but with BOD you don’t have to.
I don’t have any E-switch only lights myself so I haven’t researched it much. It would have to be a hardware change to the driver though, you can’t prevent parasitic drain without some additional component to cut the power supply. I did some early unsuccessful tests once, but haven’t resumed as other projects have taken priority.
I guess an entirely different protection circuit is needed. Aka: protected cells:)
The problem with protected cells is the circuit is in the LED current path. We'd rather have something that isn't. Something roughly like an LTC1440 possibly wired to the input of the ldo or diode could do the trick. Ideal would be to have a package that does it all in the Vcc isolation position: ldo/diode/voltage-threshold. Maybe something exists.
Edit: oh I guess that still doesn't address the cap drain during off-time sleep though. You'd maybe need two levels of isolation for that. A diode with the cap behind it, then powering a voltage supply with an input threshold. Seems too complicated.
Is this something that could be added to the triple channel,drivers running narsil?
I’ve build a couple lights for friends and they have run the batteries down to nothing. I think it’s cause of parasitic drain when the light turned off after extended use and then unattended for a while. I’m not certain though. Is this a common problem with eswitch lights. Or do some lights not do This? Maybe it’s just the BLF drivers and not lights like olight? I wouldn’t think production lights would do this… just trying to inform myself;)