Flashy mike are you using the voltage interrupt to wake from sleep or you're still waking periodically? My reading of the manual is you can wake on a pin interrupt. I don't trust ANY awake time in low voltage with BOD disabled. Making it short only reduces the odds of problems. But you've still got normal low voltage scenarios just from low battery to deal with with your BOD fuse disabled. Maybe just using 1.8V chips solves that. But what about while the capacitor is first charging up during a "clean" start and it's still at low voltage. Isn't than a non-protected low voltage code operation time when corruption is still possible? Really guaranteeing you never execute code during low voltages seems possibly difficult.
And you've still got to nail all these voltage issues if it's going to be guaranteed trustable. That can be done but it's more piece meal than some liked and in the end I worry about the voltage tolerances on the internal references. If the Bod disable works though it's a clean solution without caveats. And it looks like people have gotten it to work. The code is there in my link above and looks simple enough. I'm not sure why Tom E couldn't get it to work. Maybe he had the wrong chip version? (and that might be a big irritation still if there are still many chips on the market).
Either I don’t have late enough revision of the 85V (can’t see as revision number is on bottom side), or software BOD disable just doesn’t work. There is no time difference at all.
The datasheet specifies that the BODS bit should remain active for three clock cycles after performing the timed set sequence. So I did a test where I check if that bit is active directly after setting it, and it never is. So either my 85V can’t do it, or the C compiler can’t compile the instructions well enough so they are performed within those three clock cycles. I tried different speed fuses and the clock division, but no difference.
Maybe picoPower compatible versions of the MCUs are the next step. If anyone want’s to take that next step I’m all ears, but until then I’ll carry on with BOD enabled as I have plenty of 85Vs at home and driver boards with 1206 or double 0805 cap capacity.
I’ve not been able to combine pin testing with the voltage divider pin reliably. I haven’t tested those lower resistance values he suggested though. With BOD enabled I have to bump up the capacity anyway, as this is the big power eater. I did a quick pin check on a free pin and the gain wasn’t very significant. If you don’t run BOD the gain is huge.
It sound a bunch like you have a non-compliant chip. The datasheet says it will never read back as set in the uncompliant chips. On the other hand if it's so difficult/random to find chips with this feature, it may not be a very practical solution. I do wonder if a larger fraction of 45's in the wild have this feature. Oh well, you're not the first to have this not work.
actually I had wondered about the compiler issue too. Maybe Jack Christensen had a different compiler. Something like this should probably be done in assembly really. There was mention of some library, I think in Tom's previous discussion. He never got that to work either though, on his chips at least as far as I followed.
It's worth noticing that the only reported instance of someone making this work, was with an attiny45. At the time the datasheet apparently said it should work for all revisions of the 45. Oddly now it says only revision D and beyond (maybe they retroactively released pre-D chips into the market?)
From Jack Christensen:
"I could never make heads or tails out of the markings on the back of the package, either. I concluded that the ATtiny85s that I had were not revision C, since the current in power down mode only dropped to 20µA or so, whereas an ATtiny45 running the same code dropped to under 0.5µA."
That was in 2012 referring it seems to tests in 2011, and another thread hints that the 85 he had was made maybe in 2010.
Yeah, read those threads and did some searching of my own, same same. Like you and Tom E, I can’t find anyone stating that it is actually working on a 85.
Intensive work trips starting tomorrow and I won’t be taking any development stuff with me so I’m out for a few weeks.
Jack posted maybe more mature code on git (maybe not so different), a nice looking open source implementation of a skeleton BODS sleep cycle (wakes on external interrupt, not watchdog). That could really be possibly be pretty useful for someone wanting to add some of this to Bistro, Narsil, etc. Still the comments in the code only seem to indicate successful testing on 45, but also seem to indicate that he discovered that his 85 was in fact a revision B specifically.
I just noticed the interrupt disable, possibly an important element for timing stability, but it's a bit strange. (updated: I just realized/read that sei() executes one following command--sleep in this case--before allowing any interrupt to be serviced. Now it makes sense.)
What it doesn't seem to have, that could be useful, is a little test code that sets BODS, instantly reads it back, and flashes out the result, to test for BODS support in the chip. He seems to do testing just by measuring power draw.
So My attiny 25 appears, I think, to be a revision F. I'd be willing to flash something to it to test BODS. Shoot maybe sooner or later I'll even write something simple and try it. Got to start somewhere.
So you can't actually measure low-power sleep time right, you can only wake at certain intervals with the watchdog timer. If you wake with an interrupt, like when voltage comes back, you can't just wake up and ask "how long has it been?" because you can't actually directly read the watchdog timer. That last answer by bigjosh provides a seemingly very theoretical/untested method to effectively read the watchdog timer at any random time (by scanning the timeout threshold and seeing if it's triggered, if I understand right).
In principle this would allow the digital method, flashy mike's, to not need periodic wakes at all. It could just wake on an interrupt and then find out what time it is. It's not clear that this solves any actual problem. In principle though it could allow sleep times of something like 8 minutes without BOD. I could actually think of a use for that but, nevermind.
Not exactly on leave from BLF, just on leave for any development tests
I had a look through those sleep examples, it’s the same code I used so I wouldn’t even bother trying. When I’m home again I’ll see if I can read the chip revision of my unused 85Vs.
About that digital method, I can’t see any use for it myself. As mentioned before, with BOD enabled I tested digital input in a free pin, and it makes little difference. The bottom line is that if I can’t turn off BOD during sleep, I need it on all the time to avoid corruption issues.
Using digital pin reading or ADC, and how often I wake the MCU up to test power, make so little difference. It’s like adding a table spoon of water to a full bucket. Now, without BOD it’s like adding a table spoon to a few drops. These are the kind of differences we are talking about.
Yeah, my digital comment was just about if we CAN get BOD turned off. Then wakes become the limiting factor and that funny trick could in prinicple eliminate wakes too, using a digital interrupt.
Not bother trying? we already know that it failed for a b version 85 bought in 2011 when it seems it seems this BODS was released in 2006, but it worked for a 45 bought at the same time. I also know my 25 is a late version (although still from 2013 from the looks of it). I'd say there's every reason to believe that code should work on my 25. I'm now where near ready to accuse the datasheet of being wrong and I don't think there is any evidence of that at the moment.
Now I can be astronomically slow at getting around to non-work/family/fitness things these days, but it's definitely in my sights. If nobody else has tried it in a year, you may be hearing from me lol. I did just compile bistro though, so that's a start.
No. Why bother trying when those methods where basically the exact same code I’ve already tried. Sure, would be worth trying if any of those methods where somewhat different from I’ve tried, but they aint.
You're missing the point Mike C. As for method I'd try both the direct bit setting and the library and I see now the comments have the alternative in them. BUt the point it is documented by the datasheet and the person who wrote that that those methods work on late model chips but not on early model chips. It's true that it has never been shown to work on any 85 chip(that we know of). So either it doesn't work on 85 chips or nobody has actually tried a late model 85 chip. But what's more, mine is a 25, not an 85. Sure I'd be even more hopeful if it was a 45. But then setting up for trying is the hard part. Ordering and swapping a 45 chip is relatively easy. Now if you pulled your chip and found that it is a revision F, then I'd definitely be ready to conclude that method doesn't work on 85's.
At lightrider, Mike C and Flashy Mike are doing all the work so far. I'm just theorizing a bit.
By the way, AVR studio allows to view the assembly code in debug, so it's possible to tell exactly how many instructions really get produced in the sequence. Translating that to actual cpu cycles may be more involved, but I'd almost have to assume the required instructions are capable of fitting in the required number of cycles, and the assembly gets a step closer.
You seem to think I haven’t actually viewed the code, comments and the rest in those links? I think you are missing the point. I have tried those methods already, so I won’t try them again.
I’m in need of some quick help. I’m building a light for a guy who’s bday is tomorrow. I’m using Narsil for the first time and installed it onto an adapted PD triple stack driver. I have everything working besides the voltage readings. They are WAY off.
I’m using 220k and 47k resistors. On a full cell. When I enter battcheck mode I get two slow blinks a pause and two slow blinks and pause and so on. Can someone offer some help? I’m thinking it must be more that just adc values cause it’s so far off. But if it is reading 2v I would think the light would shut down because of lvp. So I’m really not sure what to try and fix. Thanks for any help!
