Attiny85: Brown-Out-Detection via Software ausschalten

[Tobi X. (ranger81)]

Hallo,

wie im Attiny85 Datenblatt auf Seite 35 genannt möchte ich gerne via 
Software die Brown-Out-Detection deaktivieren, bevor ich in den 
Power-Down Schlaf gehe. Diese Möglichkeit soll laut Datenblatt für 
Attiny85 ab Rev. C existieren. Hierfür benutze ich den "empfohlenen" 
Code von Atmel (ganz unten) 
http://www.atmel.com/webdoc/avrlibcreferencemanual/group__avr__sleep.html

Der Stromverbrauch nach dem Wechsel in den Power Down Sleep-Modus 
beträgt allerdings noch immer ca. 18.7uA. Wenn der BOD tatsächlich 
abgeschaltet wäre, würde ich hier aber unter 1uA erwarten. Somit scheint 
die Abschaltung nicht zu funktionieren. Fuse Settings des Attiny85 sind 
übrigens E:FF, H:DD, L:62. )Brown Out Detection auf 2.7V ist via Fuse 
aktiv, sonst Standard Fuses)

Habe inzwischen mehrere Attiny85 mit unterschiedlichen Date-Codes 
vergeblich getestet.

Könnt ihr das ggf. mal testen mit einem Attiny85, ob das bei euch 
funktioniert, oder mache ich etwas falsch?

PS: Testaufbau ist nur der blanke Attiny85, keine ext. Komponenten.

Danke,
Grüße

[Karl M. (Gast)]

Tobi Xx,

warum zeigst Du deinen Code nebst Makefile nicht ?

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Schalte den BOD doch mal bitte per Fuse ab und messe dann den 
Stromverbrauch.
Beachte, das 'floating' Pins den Stromverbrauch rapide ansteigen lassen, 
es sollten also alle Pins definiert auf high oder low liegen.

[Dietrich (Gast)]

Karl M. schrieb:
> Tobi Xx,
>
> warum zeigst Du deinen Code nebst Makefile nicht ?

Warum plenkst du?

[Karl M. (Gast)]

Dietrich schrieb:
> Warum plenkst du?

Aha, die neue Rechtschreibung möchte es anders. Ok?

[Tobi X. (ranger81)]

Matthias S. schrieb:
> Schalte den BOD doch mal bitte per Fuse ab und messe dann den
> Stromverbrauch.
> Beachte, das 'floating' Pins den Stromverbrauch rapide ansteigen lassen,
> es sollten also alle Pins definiert auf high oder low liegen.

Habe ich gemacht, dann liegt der Stromverbrauch bei den erwarteten ca 
200nA.

@Karl: Mein Code besteht ausschließlich aus dem genannten Beispielcode. 
Fuses sind genannt. Sollte also alles gesagt sein.

[S. Landolt (Gast)]

> 'floating' Pins den Stromverbrauch rapide ansteigen lassen

nicht bei Power-down

[Karl M. (Gast)]

Hallo,

bei mir liefert der gcc eine Fehlermedung.
"<m o d e>" , "(some_condition)"

set_sleep_mode(<mode>);
  cli();
  if (some_condition)
  {
    sleep_enable();
    sleep_bod_disable();
    sei();
    sleep_cpu();
    sleep_disable();
  }
  sei();

[Tobi X. (ranger81)]

Karl M. schrieb:
> Hallo,
>
> bei mir liefert der gcc eine Fehlermedung.
> "<m o d e>" , "(some_condition)"
>

set_sleep_mode(<mode>);
>   cli();
>   if (some_condition)
>   {
>     sleep_enable();
>     sleep_bod_disable();
>     sei();
>     sleep_cpu();
>     sleep_disable();
>   }
>   sei();

ersetze <mode> mit SLEEP_MODE_PWR_DOWN und entferne die if-Bedingung.

[S. Landolt (Gast)]

Schlecht: ich habe hier eine ganze Stange ATtiny85-20PU, also 50 Stück, 
von 1706, aber Rev. B.

[Tobi X. (ranger81)]

S. Landolt schrieb:
> Schlecht: ich habe hier eine ganze Stange ATtiny85-20PU, also 50 Stück,
> von 1706, aber Rev. B.

Woran erkennst du denn die Revision? Da gibts es ja unzählige Mythen und 
Vermutungen welcher der Codes die Revision sein könnte...

[S. Landolt (Gast)]

Das sind, wie gesagt, PU, also PDIP, auf der Unterseite steht:

A8V    B5A
B      1P
1706   e3

und da hatte ich jetzt einfach gedacht, das "B" in der Mitte links sei 
die Revision.

[S. Landolt (Gast)]

PS: Jedenfalls steht nirgendwo auf den Dingern ein "C".

[S. Landolt (Gast)]

> ... welcher der Codes die Revision ...
Sehe ich das richtig, Sie wissen gar nicht, welche Revision Sie haben?

[Tobi X. (ranger81)]

S. Landolt schrieb:
>> ... welcher der Codes die Revision ...
> Sehe ich das richtig, Sie wissen gar nicht, welche Revision Sie haben?

Naja ich habe auch das "B" auf der unteren Seite, aber ich glaube kaum, 
dass das die Revision ist. Der Datecode besagt Herstellungsjahr 2016 und 
anhand der Änderungshistorie des Datasheets gibt's die Software BOD 
Deaktivierung wohl schon sehr sehr lange (ca 2008). Von daher gehe ich 
eigentlich schon davon aus, dass wir mittlerweile die nötigte Revision 
haben.

[S. Landolt (Gast)]

Ich weiß nicht, vielleicht sah Atmel keine Notwendigkeit, die Produktion 
umzustellen; Papier, pardon PDF, ist geduldig.

[Thomas E. (thomase)]

> sleep_bod_disable();

Ohne mir jetzt angesehen zu haben, was da hintersteckt, gehe ich davon 
aus, daß damit die automatische BOD-Abschaltung aktiviert wird. Das 
haben aber nur die P-Typen der Atmegas. Der Tiny 85 kann das nicht. Du 
wirst den BOD daher zu Fuß abschalten und auch wieder einschalten 
müssen.

S. Landolt schrieb:
> eine ganze Stange ATtiny85-20PU, also 50 Stück,
> von 1706

1706 gab es noch keine Mikrocontroller.

[S. Landolt (Gast)]

Ich habe es mit einem von meinen probiert, die sind von diesem Jahr, 
aber BOD lässt sich nicht abschalten, die Stromaufnahme liegt bei 19 uA.
  Vielleicht sieht aber jemand einen Fehler im Programm:

.include "tn85def.inc"
.def    tmp0    = r16
    ldi     tmp0,(1<<SE)+(1<<SM1) + (1<<BODS)+(1<<BODSE)
    out     MCUCR,tmp0
    ldi     tmp0,(1<<SE)+(1<<SM1) + (1<<BODS)+(0<<BODSE)
    out     MCUCR,tmp0
    sleep

[Karl M. (Gast)]

Hallo,

soweit ich das sehe, kann jeder ein Programm schreiben, dass das Bit 
BODS im Register MCUCR überprüft.

Kann man MCUCR.BODS = 1 setzen und auch erfolgreich wieder 
(zurück)lesen,
dann gibt es die Funktionalität beim attiny85.
Natürlich muss man das weiter unter beschriebene Zeitverhalten beachten!

if (MCUCR & (1<<BODS)) {
// ok MCUCR.BODS = 1 kann man setzen.
} else {
// fehler
}

*MCUCR – MCU Control Register*
The MCU Control Register contains control bits for power management.
• Bit 7 – BODS: BOD Sleep
BOD disable functionality is available in some devices, only. See 
“Limitations” on page 36.

In order to disable BOD during sleep (see Table 7-1 on page 34) 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.

[Thomas E. (thomase)]

Thomas E. schrieb:
> Ohne mir jetzt angesehen zu haben, was da hintersteckt, gehe ich davon
> aus, daß damit die automatische BOD-Abschaltung aktiviert wird. Das
> haben aber nur die P-Typen der Atmegas. Der Tiny 85 kann das nicht. Du
> wirst den BOD daher zu Fuß abschalten und auch wieder einschalten
> müssen.

Gerade gesehen, daß das offensichtlich Blödsinn ist.

[M. K. (sylaina)]

Thomas E. schrieb:
> 1706 gab es noch keine Mikrocontroller.

KW 06 2017 solls keine Mikrocontroller gegeben haben? Wow, dann haben 
wir ja in den letzten 45 KWs ne Menge erreicht.

[Tobi X. (ranger81)]

Karl M. schrieb:
> Kann man MCUCR.BODS = 1 setzen und auch erfolgreich wieder
> (zurück)lesen,
> dann gibt es die Funktionalität beim attiny85.
> Natürlich muss man das weiter unter beschriebene Zeitverhalten beachten!
>

if (MCUCR & (1<<BODS)) {
> // ok MCUCR.BODS = 1 kann man setzen.
> } else {
> // fehler
> }

>
> In devices where Sleeping BOD has not been implemented this bit is
> unused and will always read zero.

Das habe ich mal versucht, scheint als würde er immer 0 zurück lesen, 
auch wenn ich zuvor das Bit auf 1 gesetzt habe. Hatte das aber schnell 
mit Arduino getestet, daher bin ich mir nicht sicher, ob ich da alles 
richtig gemacht habe. Kann das einer von euch auch nochmal verifizieren?

Danke!

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Tobi X. schrieb:
> auch wenn ich zuvor das Bit auf 1 gesetzt habe.

Innerhalb von 3 Cycles nach dem Setzen des Bits wird es sowieso von 
alleine gelöscht. Wenn man es also lesen will, muss man das direkt nach 
der 'Enable BOD' Prozedur machen.
Übrigens - wenn auf der Unterseite ein B steht, ist es lt. Datenblatt 
auch Revision B:

"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"

[Karl M. (Gast)]

Guten Morgen,

aus dem referierten Abschnitt des Datenblatts Attiny85 liest man:
"The BODS bit is active three clock cycles after it is set."

Darauf bezieht sich meine Anmerkung
> Natürlich muss man das weiter unter beschriebene Zeitverhalten beachten!

Somit kann man nur sicher testen, wenn man vorher immer den erzeugten 
Code C -> Assembler ansieht und die Zeiten eingehalten werden.
Man kann natürlich auch das Setzen und Zurücklesen aus in Assembler 
kodieren.

[Tobi X. (ranger81)]

Habe zum Thema mal bei Microchip angefragt... Lt. Microchip müsste es 
z.B. mit dem C-Code (siehe Listing oben) funktionieren. Voraussetzung 
ist eben die Chip-Rev. C oder neuer. Die Revision lässt sich wohl auf 
der Unterseite (zweite Zeile, erster Buchstabe bei PDIP Package) 
erkennen. Bei mir ein "B" und somit klar, warum es nicht funktioniert.

Jetzt stellt sich mir nur die Frage, woher ich Rev. C Chips bekomme...

[Ach Du (Gast)]

Danke! So ein Mist.

> In some devices it is possible to save power by disabling the BOD by software in 
Power-Down sleep mode.

Da wäre ein fetter Link auf

Matthias S. schrieb:
> 7.2.1 Limitations

schön gewesen ... und hätte mir viel rumprobieren erspart (3V, 5V, 
Pullup, PRR, ACSR). Ich dachte, ich hätte vielleicht einen "Schalter" 
übersehen.
Oder die Schreibsequenz (sleep_bod_disable(); 
http://www.nongnu.org/avr-libc/user-manual/group__avr__sleep.html).
Oder der AVR wäre defekt.
Ich hatte auch um die 15, 16, 17, 18 uA - bis ich den BOD in den 
BODLEVEL Fuses ausgeschaltet habe, dann 0.2 uA.

Zum Spielen:

// ATtiny85 @ 2V
// Fuses: E:FE, H:DE, L:E1

#define F_CPU 16000000UL
#include <stdint.h>

#include <avr/io.h>
#include <avr/sleep.h>
#include <avr/interrupt.h>
#include <avr/wdt.h>
#include <util/delay.h>

int main(void) {
    // init
    MCUSR = 0;
    GIFR = 0xFF;

    // watchdog
    wdt_disable();

    // POWER
    ACSR = (1<<ACD);
    PRR =  (1<<PRTIM1) | (1<<PRTIM0) | (1<<PRUSI) | (1<<PRADC);

    DDRB = 0;
    PORTB = 0xFF;

    // PCINT
    PCMSK = (1<<PCINT2);
    GIMSK = (1<<PCIE);

    set_sleep_mode(SLEEP_MODE_PWR_DOWN);
    // sei();
    for(;;){

        cli();
        if (1)
        {
            sleep_enable();
            sleep_bod_disable(); // ! 7.2.1 Limitations
            sei();
            sleep_cpu();
            sleep_disable();
        }
        sei();

    };
}

ISR(PCINT0_vect) {
}

[Benedikt M. (bmuessig)]

Tobi X. schrieb:
> Jetzt stellt sich mir nur die Frage, woher ich Rev. C Chips bekomme...

Das habe ich mich privat auch schon oft bei anderen Chips gefragt. Wenn 
in der Errata z.B. das beworbene I2S bei allen Revisionen, abgesehen von 
der Aktuellsten, defekt ist und man die Teile nicht direkt vom 
Hersteller bezieht, muss man wohl auf einen anderen Chip setzen (oder 
einen guten Draht zum Distributor haben).

[M. K. (sylaina)]

Benedikt M. schrieb:
> oder
> einen guten Draht zum Distributor haben

Einfach mal anrufen und nicht nur blind bestellen. Viele Distributoren 
sind doch sehr hilfsbereit, auch "Laien" gegenüber ;)