Has anyone had any luck getting this to work?
JJ
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
 |
Try asking the question again, I'm not sure what your problem is. Try posting your code and describe what you want to happen and what is happening. You will get a better response asking specific questions, rather then a generic "why does this not work?"
JC
I fear you may have mistaken Joey for a beginner ;-)
(it's a pretty fair bet he, of all people, knows exactly how to program the BOD so if it doesn't appear to work there's a strong chance there's something wrong with its implementation in the chip).
The BOD is controlled by the fuses. So there usually is no way to change or disable BOD in software - except for having a second µC doing reprogramming the fuse.
So there usually is no way to change or disable BOD in software...
• Bit 2 – BODSE: BOD Sleep Enable
BOD disable functionality is available in some devices, only. See “Limitations†on page 37. The BODSE bit enables setting of BODS control bit, as explained on BODS bit description. BOD disable is controlled by a timed sequence.This bit is unused in devices where software BOD disable has not been implemented and will read as zero in those devices.
• Bit 7 – BODS: BOD Sleep
BOD disable functionality is available in some devices, only. See “Limitations†on page 37.In order to disable BOD during sleep (see Table 7-1 on page 35) the BODS bit must be written to logic one. This is controlled by a timed sequence and the enable bit, BODSE in MCUCR. First, both BODS and BODSE must be set to one. Second, within four clock cycles, BODS must be set to one and BODSE must be set to zero. The BODS bit is active three clock cycles after it is set. A sleep instruction must be executed while BODS is active in order to turn off the BOD for the actual sleep mode. The BODS bit is automatically cleared after three clock cycles.
In devices where Sleeping BOD has not been implemented this bit is unused and will always read zero.
7.2.1 Limitations
BOD disable functionality has been implemented in the following devices, only:
• ATtiny25, revision E, and newer
• ATtiny45, revision D, and newer
• ATtiny85, revision C, and newer
Revisions are marked on the device package and can be located as follows:
• Bottom side of packages 8P3 and 8S2
• Top side of package 20M1
I fear you may have mistaken Joey for a beginner ;)
So, the first step is to verify the chip revision?
Bottom side: 1F7 415 --> Fab / lot number B5 1P -->1236 e3 --> Date code(yyww) / revision of the device
As it happens all the ATtiny85 I have on hand have the same back-side labelling.
If the fellow at Atmel who responded was wrong, this may not be an 'E'. Maybe it's a 'B'? Was 'B' still manufactured in September 2012? Does anyone have any '85s on hand to check? I would expect the date codes to increase from revision to revision (within the same fab).
Looking at the above-linked post again, I reference someone else's post within regarding an ATtiny45 containing:
8H7 509 G 1P 0580 e3
... which according to Atmel would be revision 'E' manufactured in the 80th week of '05. Come to think of it, 2005 was an especially long year for me ;)
Anyone have the real skinny on deciphering back-side labelling on these wee beasties?
As for my code:
#include#include int __attribute__ ((__OS_main__)) main(void) { ACSR = (1<<ACD); PRR = (1<<PRTIM1) | (1<<PRTIM0) | (1<<PRUSI) | (1<<PRADC); DDRB = 0x3F; set_sleep_mode(SLEEP_MODE_PWR_DOWN); sleep_enable(); sleep_bod_disable(); sleep_cpu(); while (1); }
This is the recommended sequence.
Assembly:
bods_test.elf: file format elf32-avr Disassembly of section .text: 00000000 <__vectors>: 0: 0e c0 rjmp .+28 ; 0x1e <__ctors_end> 2: 15 c0 rjmp .+42 ; 0x2e <__bad_interrupt> 4: 14 c0 rjmp .+40 ; 0x2e <__bad_interrupt> 6: 13 c0 rjmp .+38 ; 0x2e <__bad_interrupt> 8: 12 c0 rjmp .+36 ; 0x2e <__bad_interrupt> a: 11 c0 rjmp .+34 ; 0x2e <__bad_interrupt> c: 10 c0 rjmp .+32 ; 0x2e <__bad_interrupt> e: 0f c0 rjmp .+30 ; 0x2e <__bad_interrupt> 10: 0e c0 rjmp .+28 ; 0x2e <__bad_interrupt> 12: 0d c0 rjmp .+26 ; 0x2e <__bad_interrupt> 14: 0c c0 rjmp .+24 ; 0x2e <__bad_interrupt> 16: 0b c0 rjmp .+22 ; 0x2e <__bad_interrupt> 18: 0a c0 rjmp .+20 ; 0x2e <__bad_interrupt> 1a: 09 c0 rjmp .+18 ; 0x2e <__bad_interrupt> 1c: 08 c0 rjmp .+16 ; 0x2e <__bad_interrupt> 0000001e <__ctors_end>: 1e: 11 24 eor r1, r1 20: 1f be out 0x3f, r1 ; 63 22: cf e5 ldi r28, 0x5F ; 95 24: d2 e0 ldi r29, 0x02 ; 2 26: de bf out 0x3e, r29 ; 62 28: cd bf out 0x3d, r28 ; 61 2a: 02 d0 rcall .+4 ; 0x302c: 15 c0 rjmp .+42 ; 0x58 <_exit> 0000002e <__bad_interrupt>: 2e: e8 cf rjmp .-48 ; 0x0 <__vectors> 00000030 : #include int __attribute__ ((__OS_main__)) main(void) { ACSR = (1<<ACD); 30: 80 e8 ldi r24, 0x80 ; 128 32: 88 b9 out 0x08, r24 ; 8 PRR = (1<<PRTIM1) | (1<<PRTIM0) | (1<<PRUSI) | (1<<PRADC); 34: 2f e0 ldi r18, 0x0F ; 15 36: 20 bd out 0x20, r18 ; 32 DDRB = 0x3F; 38: 3f e3 ldi r19, 0x3F ; 63 3a: 37 bb out 0x17, r19 ; 23 set_sleep_mode(SLEEP_MODE_PWR_DOWN); 3c: 45 b7 in r20, 0x35 ; 53 3e: 47 7e andi r20, 0xE7 ; 231 40: 40 61 ori r20, 0x10 ; 16 42: 45 bf out 0x35, r20 ; 53 sleep_enable(); 44: 55 b7 in r21, 0x35 ; 53 46: 50 62 ori r21, 0x20 ; 32 48: 55 bf out 0x35, r21 ; 53 sleep_bod_disable(); 4a: 85 b7 in r24, 0x35 ; 53 4c: 84 68 ori r24, 0x84 ; 132 4e: 85 bf out 0x35, r24 ; 53 50: 8b 7f andi r24, 0xFB ; 251 52: 85 bf out 0x35, r24 ; 53 sleep_cpu(); 54: 88 95 sleep 56: ff cf rjmp .-2 ; 0x56 <__SREG__+0x17> 00000058 <_exit>: 58: f8 94 cli 0000005a <__stop_program>: 5a: ff cf rjmp .-2 ; 0x5a <__stop_program>
All timing requirements appear to be met:
sleep_bod_disable(); 4a: 85 b7 in r24, 0x35 ; 53 4c: 84 68 ori r24, 0x84 ; 132 4e: 85 bf out 0x35, r24 ; 53 50: 8b 7f andi r24, 0xFB ; 251 52: 85 bf out 0x35, r24 ; 53 sleep_cpu(); 54: 88 95 sleep
Two cycles between (1<<BODS)|(1<<BODSE) and (1<<BODS) (requires <= 4 cycles). One cycle between (1<<BODS) and SLEEP (requires <= 3).
I tried this code both with and without BOD enabled by fuse, just to be sure I wasn't leaving some other Vbg-dependent feature enabled. DMM confirms that Vbg does not run while asleep when BOD is fuse-disabled, but does run when BOD is fuse-enabled. Ergo software BOD disable isn't working...
... or have I missed something obvious?
JJ
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
All timing requirements appear to be met:
BODS is set along with BODSE. Does the 3-cycle "clock" start then?
The BODS bit is active three clock cycles after it is set.
Yes, puzzling. (How are you checking Vbg with a DMM? Indirectly, via current draw?)
The only way I can think of to save a cycle would be to use another register (if indeed the timing is that critically tight).
IN reg1, MCUCR ORI reg1, 0x84 MOV reg2, reg1 ANDI reg2, 0xfb OUT MCUCR, reg1 OUT MCUCR, reg2 SLEEP
BODS is set along with BODSE. Does the 3-cycle "clock" start then?
In order to disable BOD during sleep (see Table 7-1 on page 33) the BODS bit must be written to logic one. This is controlled by a timed sequence and the enable bit, BODSE in MCUCR. First, both BODS and BODSE must be set to one. Second, within four clock cycles, BODS must be set to one and BODSE must be set to zero. The BODS bit is active three clock cycles after it is set. A sleep instruction must be executed while BODS is active in order to turn off the BOD for the actual sleep mode. The BODS bit is automatically cleared after three clock cycles.
Also, does "within three clock cycles" mean < 3 or <= 3?
In support of this interpretation, I point out that the timed sequence must complete within 4 cycles. If the 3-cycle-before sleep limit began with the first write of the timed sequence, it would technically be possible to succeed in setting BODS with the second write of the timed sequence, but be too late with the sleep. Does that sound likely?
>>If<< I'm wrong and the 3-cycle limit does in fact begin with the first write of the timed sequence, >>and<< 'within 3' means 'less than 3', then this code should work:
ldi r16, (1<<BODS)|(1<<SE)|(1<<SM1)|(1<<BODSE) ldi r17, (1<<BODS)|(1<<SE)|(1<<SM1) out MCUCR, r16 out MCUCR, r17 sleep
It does not.
EDIT: I just saw your next post ;)
How are you checking Vbg with a DMM? Indirectly, via current draw?
JJ
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
Sorry to resurrect an old thread, but I'm having this same exact problem, and all the searching that I've done, could not find a working solution.
I'm now using the macros define in the sleep.h, sleep_bod_disable(), in this sequence:
sleep_enable();
sleep_bod_disable(); // try to disable Brown-Out Detection to reduce parasitic drain
sleep_cpu(); // go to sleepy beddy bye
sleep_disable();
It's a recently purchased Tiny85 MCU (from Mouser), so I'd assume it's rev C or higher. The backside revision ID is still a mystery to me - seems no one got any definite way to find it in confidence.
Since the 25/45/85 have so much in common, I'd assume this issue is common across them as well. I know the BOD disabling is not working from my measured amps - pretty much the exact delta of uA JJ found above.
Anyone ever get the BOD disable working on any these MCU's?
I never resolved either of these issues. Although I would be happy if they ever do get resolved... ;-)
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
I really dunno what's going on. I tried with both an 85 and 85V version. I've seen posts where it was working on other ATMEL family MCU's. I can't find any evidence anyone ever got it working on 25/45/85's.
I'm using it in a flashlight driver (on BudgetLightForum, thread here: http://budgetlightforum.com/node/41067), so power drain is important. We are hoping to use it in a Group Buy light (http://budgetlightforum.com/node/45915) that has close to 500 sign-ups and get it manufactured in China. Right now I'm measuring 0.016 mA if BOD is disabled via the fuses, 0.037 mA if enabled. It's not a hugh problem - we could live with the 0.037 mA drain, just it's always better to have it as low as possible. People tend to keep flashlights laying around for months. I needed the BOD enabled because without it, I was getting lockups' and other bad behavior if there are power fluctuations cause by intermittent connections when installing batteries, for example, threading on a battery tube that may have intermittent connections while threading it on.
Interesting project.
I'd say that since you can't predict when a power fluctuation will occur, you need to keep BOD enabled all the time anyway.
But it's true, I haven't seen any evidence anyone has ever managed to get software BOD disable working on the t25/45/85. Doesn't mean there isn't a way, though.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
sleep_bod_disable(); // try to disable Brown-Out Detection to reduce parasitic drain
I see I participated in this discussion earlier. ;) I'm out of town so can't play with it, but indeed I have an app where I'll probably use BOD disable (but not on this model).
Anyway, have y'all looked at what the infinite-value toolchain generated for this model for that macro? Does it make sense?
Anyway, have y'all looked at what the infinite-value toolchain generated for this model for that macro? Does it make sense?
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
Also sorry from me for resurrecting this old thread but I'm actually having the same issue (I cant get the BOD disabled by software) and I was wondering if someone found out something new?
I would greatly appreciate.
Thanks
Still no.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
Still no.
I'd guess that your troubles in 2014 were caused by a misinterpretation of the chip markings. The datasheet currently on Atmel website (from 2013) lists 'C' as the latest tiny85 revision, so what you had back then probably wasn't an 'E'. And 'B' doesn't have that functionality.
Still no.
I'd guess that your troubles in 2014 were caused by a misinterpretation of the chip markings. The datasheet currently on Atmel website (from 2013) lists 'C' as the latest tiny85 revision, so what you had back then probably wasn't an 'E'. And 'B' doesn't have that functionality.
Where did you find this information in the datasheet (that revision C is the most recent) - the errata? And do you have any information how to interpret the markings?
Where did you find this information in the datasheet (that revision C is the most recent) - the errata?
Yes, I was looking at the errata. And assumed that any newer revision would be listed there. Now that you pointed it out, that assumption might of course be wrong.
And do you have any information how to interpret the markings?
The way I'd interpret the markings in post #6 is that joeymorin's tiny85 is 'B' (as in B5 on the second row), and the example tiny45 markings would be from a rev 'G' part. Again from the second row. Based on the errata section of the datasheet, these would be plausible fairly recent revisions in 2014.
I'd guess that your troubles in 2014 were caused by a misinterpretation of the chip markings.
No misinterpretation on my part. Atmel couldn't even answer the question. I contacted them before even opening this thread See post #6, and follow the trail of links. They had this to say:
Bottom side: 1F7 415 --> Fab / lot number B5 1P --> 1236 e3 --> Date code(yyww) / revision of the device
Atmel were never able to tell me (or point me to documentation which would) unequivocally how to determine revision. It's all just inference and supposition, a terrible way to conduct business. The likelihood is that it is not E, but by no means is it certain to be B. What is the '5' for, then?
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
I was in contact with Microchip yesterday asking how to identify the revision.
They told me it's the first letter on the bottom side (PDIP package).
Turned out that he meant the second line, first letter which is a "B" in my case. That would explain why it's not working.
Now my problem is where to get a "C" revision of the Attiny85...
Now my problem is where to get a "C" revision of the Attiny85...
You mean "C or newer"? With several respondents to this thread, IMO it would be strange for all of you to have early batches.
Indeed I never noticed the Limitations note:
7.2.1 Limitations
BOD disable functionality has been implemented in the following devices, only:
• ATtiny25, revision E, and newer
• ATtiny45, revision D, and newer
• ATtiny85, revision C, and newer
The datasheets I have downloaded don't put dates on the chip revisions in e.g. Errata section. But can we do a bit of "interpolation"?
(below refers to datasheet rev letters)-- Datasheet revision history updated that section (or at least subchapter) in datasheet rev. K in early 2008. That is the last note about BOD in datasheet revision history. [I lied; "Limitations mentioned rev. N see below]
-- ...and the Software BOD Disable was added rev. G/May 2006
-- Indeed rev. C/2006 has no Software BOD Disable section
-- ...nor does rev. F/April 2006
-- Rev. G has the subchapter, but not the Limitations table
-- Rev. K indeed updated the section and added Limitations Notice that Limitations is now a bit different, although no note of that Tiny45 change in later Dataqsheet Revision History summaries:
7.2.1 Limitations
BOD disable functionality has been implemented in the following devices, only:
• ATtiny25, revision E, and newer
• ATtiny45, all revisions
• ATtiny85, revision C, and newer
-- Rev. N /April 2011 has the Limitations table as it is now. And a note in revision history
28.1 Rev. 2586N-04/11
...
2. Updated:
– Document template.
– Removed “Preliminary” on front page. All devices now final and in production.
– Section “Limitations” on page 37.
...
OK, here is the point I'm trying to get at: I find it hard to believe that the good 'Freaks digging into this are all using Tiny85 chips or others in the model family that are all ~10 years old or older. I'd speculate that when the Limitations paragraph was added, it was based on some testing results. Apparently not...
Atmel also told me that 0580 was a date code. I don't have a lot on confidence in a support team that thinks there are more than 52 weeks in a year, so I don't have much confidence in what revision they think I have.
Neither do I have much confidence in the errata, since the 'OC1B' erratum isn't listed as affecting the t85, yet it clearly does.
I do wish someone from Microchip would come along and put to rest the question of what each part of the under-side writing means. Unequivocally
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
I am sure I recently linked to a Micromel document which showed how it works. It was in a thread about identifying chips. Were I not on a phone I would try and find it.
I remember about 5 years ago or whenever the new revision came out (and I didn't know about it), I ordered 300 dip tiny85 from farnell.
And was very surprised that I received about 30 tubes with different sizes.
I'm sure that they was clearing the stock of old revision parts.
And I sure that parts you get (at least the big places) are a new revision.
I just asked at microchipdirect.com which revision they are having in stock.
They replied with "Rev. A".
It seems to be impossible getting a Rev. C Attiny85. I gave up and switched to an Attiny84A which works perfectly fine with disabling BOD by software.
They replied with "Rev. A".
Perhaps they've started doing the same thing with revision numbers that they've done with datasheets?:
https://www.avrfreaks.net/forum/whose-stupid-idea-was-it-restart-revision-ids
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
