Forum: Mikrocontroller und Digitale Elektronik "Prellende" Spannungsversorgung


von Andreas P. (andyp17)


Lesenswert?

Hallo allerseits,

Ich habe eine Frage zur Spannungsversorgung in Verbindung mit einem 
Mikrocontroller (AVR). Und zwar benutze ich eine Klemme zwischen meinem 
Labornetzteil und meinem DC/DC-Wandler. Nun ist mir folgendes 
aufgefallen: Wenn die Spannung bereits an den Klemmen anliegt, wenn ich 
die Kabel darin befestige, kommt es vor, dass sich der uC mehrmals ein 
und ausschaltet. Ist mir auch klar warum, aber nun ist es einmal 
passiert, dass sich dabei das Programm darauf gelöscht bzw. verändert 
hat! Auf jeden Fall macht es nicht mehr das, was es machen soll. Nach 
einem erneuten Bespielen des Flashs funktioniert aber wieder alles 
einwandfrei. Danach hab ich versucht, das Problem zu rekonstruieren, 
indem ich absichtlich in der Klemme mit einem Kabel "gewackelt" habe. 
Und siehe da, das Programm war wieder defekt.

Nun meine Frage: Warum passiert das. Was geschieht da im uC. Und vor 
allem: wie kann ich das verhindern? Kann ja mal passieren, dass das beim 
Anschließen passiert, und dann soll ja nicht gleich das Programm futsch 
sein!

Vielen Dank für eure Hilfe!!

mfg
Andy

von Klugscheisser (Gast)


Lesenswert?

Das würde mich jetzt auch mal interessieren:
>Und siehe da, das Programm war wieder defekt.
Hast Du das Prg. mal zurückgelesen und mit dem Originial verglichen?

Was ist das für ein Programm? Prozessor? Bootloader?

von Andreas P. (andyp17)


Lesenswert?

Hallo,

Ja, ich gerade das Programm zurückverglichen. Aber AVRStudio meldet, 
dass es "equal to file" ist, obwohl es nicht macht, was es machen soll. 
Aber sonst wie vorher. Nach erneutem Flashen gehts wieder.

Ich verwende AVRStudio in Verbindung mit WinAVR und einem Mega168.

von Carsten (Gast)


Lesenswert?

Ich denk mal da ist was anderes Faul!

Wie sieht denn Deine Reset-Beschaltung aus?

von Andreas P. (andyp17)


Lesenswert?

Naja, wie immer: mit 10k Pull-Up zum Programmer.

von Carsten (Gast)


Lesenswert?

... und 47n zur Masse?

von Andreas P. (andyp17)


Lesenswert?

Nein, die hab ich nicht, weil ich hier schön oft gelesen habe, dass die 
eigentlich unnötig sind. War das falsch?

von Carsten (Gast)


Lesenswert?

probiers mal aus.

von Andreas P. (andyp17)


Lesenswert?

OK, i werds probieren. Ich versteh aber nicht ganz, was das damit zu tun 
haben könnte! Könntest du mir Einblick in deine Gedankengänge gewähren 
:-) :-)...

von Kachel - Heinz (Gast)


Lesenswert?

Hast Du BOD aktiviert?

KH

von J. K. (rooot)


Lesenswert?

Andreas Posch wrote:
> OK, i werds probieren. Ich versteh aber nicht ganz, was das damit zu tun
> haben könnte! Könntest du mir Einblick in deine Gedankengänge gewähren
> :-) :-)...

der C bewirkt, dass der Reset-Pin vorerst (kurze Zeit) low bleibt, und 
der µC noch nicht gleich zu arbeiten beginnt. erst wenn sich der C 
auflädt geht der Reset-Pin HIGH = µC arbeitet.
In der Zeit des Prellens ist der µC also noch nicht aktiv, erst wenn die 
Spannung stabil ist!

>Nein, die hab ich nicht, weil ich hier schön oft gelesen habe, dass die
>eigentlich unnötig sind. War das falsch?

ja, wo hast du das gelesen?

mfg
J.K

von Simon K. (simon) Benutzerseite


Lesenswert?

J. K. wrote:
>>Nein, die hab ich nicht, weil ich hier schön oft gelesen habe, dass die
>>eigentlich unnötig sind. War das falsch?
>
> ja, wo hast du das gelesen?

Eine Verzögerung vom Reset-Eingang ist nicht zwingend notwendig, wenn 
man BOD aktiviert hat und noch einen großzügigen Startup-Delay benutzt 
und die Umgebung nicht sehr verschmutzt ist (zum Beispiel durch Motoren, 
Relais, bzw. andere induktive Lasten) bzw. die Versorgungsspannung 
schnell genug ansteigt beim Einschalten. Wenn man aber auf Nummer Sicher 
gehen will schaut man sich u.a. die AppNote 042 an: 
http://atmel.com/dyn/resources/prod_documents/doc2521.pdf
Atmel hat ne Menge solcher Design Considerations auf Lager.

von Ronny F. (ronny)


Lesenswert?

Und noch ein Tipp am Rande:

In der Initalisierungsphase der Software sollte man z.B. Schreibzugriffe 
aufs EEPROM oder in den Flash generell vermeiden.

Grundsätzlich muss man davon ausgehen, dass bei unsauberer 
Reset-Beschaltung der Startup-Code einige male teilweise ausgeführt 
wird, bevor der Controller sein Programm stabil abarbeitet.

von Simon K. (simon) Benutzerseite


Lesenswert?

Ronny F. wrote:
> Und noch ein Tipp am Rande:
>
> In der Initalisierungsphase der Software sollte man z.B. Schreibzugriffe
> aufs EEPROM oder in den Flash generell vermeiden.

Wo steht denn das?

> Grundsätzlich muss man davon ausgehen, dass bei unsauberer
> Reset-Beschaltung der Startup-Code einige male teilweise ausgeführt
> wird, bevor der Controller sein Programm stabil abarbeitet.

Bitte was? :O Dann ist es aber höchste Zeit den Reset zu verlängern!

von Andreas P. (andyp17)


Lesenswert?

OK, danke für eure Hinweise. Werd ich gleich mal beachten. Das mit der 
BOD-Einstellung funzt wunderbar. Hab jetzt diese Einstellung aktiviert 
und der Fehler ist nicht mehr aufgetreten! Ich glaub, das wars!

Besten Dank!!


mfg
Andy

von Ronny F. (ronny)


Lesenswert?

@Simon:

> > Und noch ein Tipp am Rande:
> >
> > In der Initalisierungsphase der Software sollte man z.B. Schreibzugriffe
> > aufs EEPROM oder in den Flash generell vermeiden.
>
> Wo steht denn das?

Nirgendwo. Es erhöht aber im Falle von unsauberen Reset-Beschaltungen 
oder EMV-bedingten Störungen/Resets die Überlebenswahrscheinlichkeit 
deines Systems.


> > Grundsätzlich muss man davon ausgehen, dass bei unsauberer
> > Reset-Beschaltung der Startup-Code einige male teilweise ausgeführt
> > wird, bevor der Controller sein Programm stabil abarbeitet.
>
> Bitte was? :O Dann ist es aber höchste Zeit den Reset zu verlängern!

Jup. Wenn man noch Einfluss auf die Schaltung hat, sollte man das 
tunlichst tun.

Gruß,

Ronny

von Simon K. (simon) Benutzerseite


Lesenswert?

Ronny F. wrote:
> Jup. Wenn man noch Einfluss auf die Schaltung hat, sollte man das
> tunlichst tun.

Ja, das ist natürlich die Voraussetzung *Räusper

von Carsten (Gast)


Lesenswert?

>Das mit der BOD-Einstellung funzt wunderbar

Du doktors and den Symptomen rum. Sicher geht das ein
par hundertmal gut aber nicht wirklich sicher!

von Maria (Gast)


Lesenswert?

Der Mega168 wird über den RESET Pin programmiert und debugt (debugWIRE).
Da darf keine C Beschaltung gemacht werden.

Die Reset Verzögerung und Logik ist im Chip.
Zusätzlich ist der Brown-out Detector zur Spannungsüberwachung 
vorhanden.

von Carsten (Gast)


Lesenswert?

@ Maria

Auszug aus dem Datasheet:

1.1.5 PC6/RESET
If the RSTDISBL Fuse is programmed, PC6 is used as an I/O pin. Note that 
the electrical characteristics
of PC6 differ from those of the other pins of Port C.
If the RSTDISBL Fuse is unprogrammed, PC6 is used as a Reset input. A 
low level on this pin
for longer than the minimum pulse length will generate a Reset, even



"if the clock is not running."



The minimum pulse length is given in Table 28-3 on page 308. Shorter 
pulses are not guaranteed
to generate a Reset.
The various special features of Port C are elaborated in “Alternate 
Functions of Port C” on page
82.

best regards Carsten

von Andreas P. (andyp17)


Lesenswert?

@Carsten:
Danke für deinen Hinweis. Ich habe aber leider bei dieser Schaltung 
keine Möglichkeit mehr ein C dazuzugeben. Ich werde das aber für meine 
nächsten Projekte mit Sicherheit berücksichtigen.

Vielen Dank... Andy

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.