Atmel Attiny 44a funktioniert unter 3,8V nicht korrekt

[User 7. (user773)]

Hi Leute,
habe mein c programm in AVR studio 7 geschrieben und auch mit simulator 
geprüft. attiny läuft mit internen 8mhz osci.

Das Programm macht folgendes:
-Ein ausschalten per taster am INT0, dabei wird zwischen power down und 
active mode gewechselt. Der letzte status wird beim int0 betätigen aus 
dem eeprom gelesen.
Danach folgt ein LED blinken in 50ms schritten in einer while schleife
Durch klicken einens zweiten tasters wird eine pin change ISR ausgeführt 
und eine variable geändert. Anschließend kehrt er zurück zur while 
schleife.

Das ganze funktioniert mit 5V mit debugwire, simulator und ohne 
debugwire ständig einwandfrei. Nur unter 3,9v will das ganze überhaupt 
nicht klappen.

Mit debugwire ist mir aufgefallen, das nach dem pinchange ISR der int0 
ISR aufgerufen wird, aber die power taste(int0) wird nicht betätigt. das 
c programm tut für mich aber nichts zur sache, da es nur unter 3,9V 
immer auftritt.
Laut datenblatt müssen mit 3,3v die 8mhz möglich sein. habe ich etwas 
übersehen? oder hat vll. jemand einen tipp wie ich den bug eingrenzen 
könnte.

PS: hab zwischen zeitlich den clkdiv8 aktviert für die 1mhz, aber das 
problem tritt weiterhin auf.

[Jörg H. (sonichazard)]

Fuses / Brown-Out ?

[AVR-Preller (Gast)]

Ließt sich für mich wie:
Wenn du einen prellenden Taster am INT-Pin per Flanke oder Pin-Change 
auswertest, ist es Zufall, ob/wann/wie gut es funktioniert.
Glückwunsch: Der Simulation ist das egal.
Glückwunsch: Bei Zimmertemperatur und 5V Versorgung scheint es irgendwie 
zu gehen.
Pech: Mit anderer Betriebsspannung oder vielleicht im Winter nicht mehr.

Und auch eine Hardware-Entprellung per RC-Glied löst das Problem nicht 
unbedingt, die (realen, nicht min/max-Werte aus dem DB) Schaltschwellen 
des AVRs sinken nicht unbedingt linear mit der Versorgungsspannung.

Also: Richtig machen. Keine Taster an Pin-Change oder 
Flanken-Interrupts.
Zum aufwachen Level-IRQ. Auswertung mit Entprellung in Software.

Und warum speicherst du im EEPROM, ob der µC grad läuft oder schläft? 
Das weiß der auch so, wenn er läuft schläft er nicht, ganz einfach....

[Stefan F. (Gast)]

Wo kommt denn die Versorgungsspannung her? Ist sie stabil? hast du einen 
Abblock-Kondensator an VCC und GND (direkt am IC)?

[Peter D. (peda)]

User 7. schrieb:
> hat vll. jemand einen tipp wie ich den bug eingrenzen
> könnte.

Divide et impera
Teile das Programm in einzelne Funktionen auf und prüfe die jede für 
sich.

Ich mache es immer so, daß ich zuerst die Funktion implementiere. Das 
Stromsparen kommt dann erst hinzu, wenn alles andere einwandfrei läuft.
Zum Aufwachen nehme ich einen leeren Pin-Change-Interrupt, denn das 
Tasten entprellen und auswerten macht ja bereits der Timerinterrupt.

EMPTY_INTERRUPT(PCINT_vect); // wake up from power down

Beitrag "AVR Sleep Mode / Knight Rider"

[User 7. (user773)]

> Ließt sich für mich wie:
> Wenn du einen prellenden Taster am INT-Pin per Flanke oder Pin-Change
> auswertest, ist es Zufall, ob/wann/wie gut es funktioniert
> Also: Richtig machen. Keine Taster an Pin-Change oder
> Flanken-Interrupts.
> Zum aufwachen Level-IRQ. Auswertung mit Entprellung in Software.
am Int0 hab ich low level auslösung um den power status zu ändern. An 
pin change aber nur eine flankenauslösung. Dieser wird nur ausgeführt, 
wenn der uC an ist. Nach beiden tastendrucks erfolgt eine 
tastenentprellung.

> Und warum speicherst du im EEPROM, ob der µC grad läuft oder schläft?
> Das weiß der auch so, wenn er läuft schläft er nicht, ganz einfach....
damit er die tastenentprellung beim starten nicht mehrmals durchläuft. 
prüf ich ob der uC an ist und leite in an die while schleife mit der 
led. dort bleibt er solange bis wieder int0 gedrückt wird. Ist mir auf 
die schnelle nichts anderes eingefallen.

>Wo kommt denn die Versorgungsspannung her? Ist sie stabil? hast du einen
>Abblock-Kondensator an VCC und GND (direkt am IC)?
Labornetzteil und 100nF sind am uC.

>Fuses / Brown-Out ?
ist aus.

[Stefan F. (Gast)]

Peter D. schrieb:
> Teile das Programm in einzelne Funktionen auf und prüfe die jede für
> sich.

Ich würde erst einmal checken ob es eher ein Softwarefehler oder ein 
Hardwarefehler ist. Softwarefehler kommt mir auf den ersten Blick recht 
unwahrscheinlich vor.

Man könnte mal eine LED in der Hauptschleife toggeln und eine andere per 
Timner-Interrupt. Dann mal schauen, ob eine oder beide aufhören, zu 
blinken.

[Peter D. (peda)]

Stefan ⛄ F. schrieb:
> Ich würde erst einmal checken ob es eher ein Softwarefehler oder ein
> Hardwarefehler ist.

Da beides ja streng geheim ist, läßt sich das nicht feststellen.
Meine Glaskugel sagt, daß bei VCC=3,9V an nem IO-Pin immer noch 5V 
anliegen. Dann hat der MC selbstverständlich das Recht, allen möglichen 
Unsinn auszuführen.

[User 7. (user773)]

Peter D. schrieb:
> User 7. schrieb:
>> hat vll. jemand einen tipp wie ich den bug eingrenzen
>> könnte.
>
> Divide et impera
> Teile das Programm in einzelne Funktionen auf und prüfe die jede für
> sich.
>
> Ich mache es immer so, daß ich zuerst die Funktion implementiere. Das
> Stromsparen kommt dann erst hinzu, wenn alles andere einwandfrei läuft.
> Zum Aufwachen nehme ich einen leeren Pin-Change-Interrupt, denn das
> Tasten entprellen und auswerten macht ja bereits der Timerinterrupt.
>

> EMPTY_INTERRUPT(PCINT_vect); // wake up from power down
>

>
Ohne sleep funktion läuft der uC bei 5V als auch 3V. also musste etwas 
mit den 3V und sleep funktion zusammenhängen.



Peter D. schrieb:
> Da beides ja streng geheim ist, läßt sich das nicht feststellen.
> Meine Glaskugel sagt, daß bei VCC=3,9V an nem IO-Pin immer noch 5V
> anliegen. Dann hat der MC selbstverständlich das Recht, allen möglichen
> Unsinn auszuführen.
Deine Glaskugel hätte ich gern :).
Am Int0 pullup waren bei nicht gedrücktem Taster nur 1,55V messbar. Es 
war eine LED+10k in reihe geschalten. Nachdem ich 220R + LED in Reihe 
und den 10K parallel zur LED gemacht hatte, waren es genau 3V Vcc. Und 
damit hat es perfekt funktioniert. leichtsinns fehler.


Danke für eure guten Ratschläge.