Hallo zusammen, der Reset Pin an meinem ATmega wird lediglich zum Programmieren benutzt und ist abgesehen davon nicht beschaltet. Es gibt also nur den internen Pull-up Widerstand. Die Leitungslänge zur Programmierbuchse beträgt mehrere cm. Die Anwendung enthält auch ein sendendes Funkmodul, für das die Reset-Leitung evtl. eine Antenne darstellt. Der Controller hängt sich jetzt alle paar Tage auf. Nach Neuanlegen der Betriebsspannung funktioniert alles wieder wie erwartet. Die Frage: Kann es sein, dass durch Einkopplung über die Reset-Leitung ein undefinierter Zustand eingenommen wird? Ich würde meinen, dass das nicht der Fall sein kann, da entweder sporadisch ein Reset ausgelöst wird oder eben nicht. Ein Aufhängen würde ich nicht erwarten. Oder habt ihr andere Erfahrungen gemacht? Besten Dank. Sören
Sören schrieb: > Die Frage: Kann es sein, dass durch Einkopplung über die Reset-Leitung > ein undefinierter Zustand eingenommen wird? Nein. Es liegt an der Spannungsversorgung. Alles andere fällt in den Bereich der Spekulation.
Die Schaltung wird von einer Batterie versorgt und liegt bei > 3V mit einem 8MHz Quarz. Wenn gesendet wird, fällt die Spannung kurz auf 2,7V, was laut Datenblatt des ATmega aber im grünen Bereicht ist (8MHz bis 2,4V).
Sören schrieb: > Die Schaltung wird von einer Batterie versorgt und liegt bei > 3V mit > einem 8MHz Quarz. Wenn gesendet wird, fällt die Spannung kurz auf 2,7V, > was laut Datenblatt des ATmega aber im grünen Bereicht ist (8MHz bis > 2,4V). Oder auch tiefer. Wie misst du das? Multimeter oder Oszi? Versuchs doch mal mit dem Brwon-Out-Detector, der reagiert auf Spannungseinbrüche und startet deinen Controller neu.
Sören schrieb: > Der Controller hängt sich jetzt alle paar Tage auf. Definiere "Aufhängen". > Die Frage: Kann es sein, dass durch Einkopplung über die Reset-Leitung > ein undefinierter Zustand eingenommen wird? Löte einfach mal einen richtigen Pullup da ran oder wenigstens einen Kondensator. Kostet ja nicht viel... > Es gibt also nur den internen Pull-up Widerstand. Mein EMV-Spezi sagt: alles hochohmiger als 5k ist offen. Und aus eigener Erfahrung: EMV-technisch wird deine Steuerung beim Burst-Test durchfallen. > Oder habt ihr andere Erfahrungen gemacht? Solche Effekte kommen zu über 98% von Software, die nicht mit "unerwarteten" Signalenwechseln (z.B. auch EMV-Spikes) oder fehlerhaften Übertragungsdaten (z.B. umgekipptes Bit) zurechtkommt und sich verheddert..
:
Bearbeitet durch Moderator
Zur Messung verwende ich ein digitales Oszilloskop. Der Brown-out Detector ist in der Anwendung nicht möglich, da der zuviel Strom frisst (Batteriebetrieb). Für einen Test wäre es evtl. aber eine Option. Das Problem bei der Sache ist nur, dass es Tage dauert, bis der Fehler auftritt...
Lothar Miller schrieb: > Sören schrieb: >> Der Controller hängt sich jetzt alle paar Tage auf. > Definiere "Aufhängen". Der Controller reagiert nicht mehr auf Zustandswechsel der Eingangspins und zeigt auch von sich aus keine Aktivitäten (Versenden eines Heartbeats). >> Die Frage: Kann es sein, dass durch Einkopplung über die Reset-Leitung >> ein undefinierter Zustand eingenommen wird? > Löte einfach mal einen richtigen Pullup da ran oder wenigstens einen > Kondensator. Kostet ja nicht viel... Kann ich mal machen. >> Es gibt also nur den internen Pull-up Widerstand. > Mein EMV-Spezi sagt: alles hochohmiger als 5k ist offen. > Und aus eigener Erfahrung: EMV-technisch wird deine Steuerung beim > Burst-Test durchfallen. Was heisst durchfallen? Wenn dadurch ein Reset ausgelöst wird, ist das in dieser Anwendung in Ordnung. Es werden quasi-statische Zustände überwacht, die sich nur alle paar Minuten ändern. Wenn zwischendrin ein Reset geschieht und eine Zustandsänderung etwas verzögert erkannt wird, ist das kein Problem. >> Oder habt ihr andere Erfahrungen gemacht? > Solche Effekte kommen zu über 98% von Software, die nicht mit > "unerwarteten" Signalenwechseln (z.B. auch EMV-Spikes) oder fehlerhaften > Übertragungsdaten (z.B. umgekipptes Bit) zurechtkommt und sich > verheddert.. Grundsätzlich ja. Spielt in dieser Anwendung aber keine Rolle, da nur gesendet wird. Trotzdem muss ich die Software nochmal genau prüfen.
Sören schrieb: > Der Brown-out Detector ist in der Anwendung nicht möglich, da der zuviel > Strom frisst (Batteriebetrieb). Das habe ich neulich schon mal gelesen und verstehe die Argumente immer noch nicht. Gerade bei Batteriebetrieb geht die Versorgung irgendwann unvermeidlich in den Keller und sorgt für irritierendes Verhalten des MC. Was glaubst du, wofür der BOD ist? Wenn deine Schüssel zu viel Strom verbraucht, sind entweder die Batterien zu klein, du hast den falschen MC gewählt, oder dein Design ist für Batteriebetrieb schlicht ungeeignet.
Die Spannung wird von einem weiteren Baustein überwacht, der sowieso mitlaufen muss. Damit kann der Strom für die Bandgap eingespart werden. Eine leere Batterie wird zuverlässig erkannt und ein fälliger Batteriewechsel angezeigt. Das beschriebene Problem tritt bei vollen Batterien auf.
Sören schrieb: > Wenn zwischendrin ein Reset geschieht und eine Zustandsänderung etwas > verzögert erkannt wird, ist das kein Problem. Jeder Reset, der nicht vom Entwickler gewollt ist, ist definitiv ein Problem. Es kann nur sein, dass er sich zufällig nicht problematisch auswirkt...
> Die Schaltung wird von einer Batterie versorgt und liegt > bei > 3V mit einem 8MHz Quarz. Wenn gesendet wird, fällt > die Spannung kurz auf 2,7V Das ist Ok. Ich habe mal Spielzeuge mit ATtiny13V gebaut, die mit CR2030 Batterien versorgt wurden. Immer wenn eine LED leuchtete, brach die Spannung deutlich ein (bis runter auf 2V - mit den billigen Batterien von Tedi). Klappt trotzdem problemlos. Allerdings hatte ich das nur mit 128kHz und 1Mhz Takt ausprobiert.
Und wenn wir schon dabei sind, mach doch auch gleich noch den Watch Dog an. Dann resetet dein ATmega sobald es hängt, unabhängig davon, an was es lag. Ich vermute aber ehrlich gesagt eher dass dein Program in einen Zustand gelangt aus dem es nicht mehr rauskommt -> Programmierfehler. Wenn es ein Zustandsautomat ist, solltest du versuchen den jeweils aktuellen Zustand in EEPROM abzulegen und nach dem Abzturz auslesen (Dann aber ohne WD oder BOD).
PS.: Kontrollierst du eigentlich auch dein Funkmodul ob es gesendet / empfangen hat? Und wenn ja, was passiert ein unvollständigen Übertragungen oder Übertragungsfehlern? Hängt es evtl. da?
Sören schrieb: > Die Schaltung wird von einer Batterie versorgt und liegt bei > 3V mit > einem 8MHz Quarz. Ist die Versorgung sauber abgeblockt? (Sorry, du zeigst uns keine Bilder vom Aufbau, sonst würde sich die Frage u. U. erübrigen.)
Den Ressetpin sollte man nit einem 10k Pullup und 100nF gegen GND beschalten...
Sören schrieb: > Der Brown-out Detector ist in der Anwendung nicht möglich, da der zuviel > Strom frisst (Batteriebetrieb). Für einen Test wäre es evtl. aber eine > Option. Die P- und PA-Typen der Atmegas zeichnen sich u.a. dadurch aus, dass sie so konfigurierbar sind, dass der BOD im Sleep-Mode abgeschaltet wird. Damit wird die Batterie durch den BOD, dessen Stromverbrauch im Sleep verhältnismässig gross ist, nicht durch diesen zusätzlich belastet wird. Nach dem Aufwachen geht er bei nicht mehr ausreichender Spannung in den Reset und verharrt dort. Jetzt Nicht schrieb: > Den Ressetpin sollte man nit einem 10k Pullup und 100nF gegen GND > beschalten... Ja, zumindest schadet es nicht. Wenn die Schaltung nicht mehr ständig nachprogrammiert werden muss, ist es das sinnvollste, den Reset fest an Vcc zu legen. Das ist über jeden Zweifel erhaben. mfg.
:
Bearbeitet durch User
Danke für alle Hinweise. Jetzt hab ich mal einen 10k Pull-up für die Reset-Leitung eingefügt. Auf einen Kondensator habe ich verzichtet aus Sorge, dass dann das Programmieren oder debugWire Probleme macht. Außerdem habe ich noch meinen externen BOD auf eine höhere Schwelle gesetzt (2,6V), was gegenüber den 2,4V Mindestspannung bei 8 MHz genügend Reserver bietet. Der externe BOD benötigt ~2uA gegenüber den ~15uA des ATmega. Die übrigen Punkte stellen kein Problem dar: - Die Versorgung ist großzügig geblockt, Verbraucher ebenso. - Dem Funkmodul wird ein String übergeben, der dann versandt wird. - Eine Prüfung findet nicht statt. - Beim nächsten Zyklus wird das Funkmodul eingeschaltet und neue Daten übergeben. Was bleibt: - Prüfung der Software auf evtl. Programmierfehler. - Weitere Tests mit Aufzeichnung des letzten Zustands vor dem Aufhängen. - Testweise Aktivierung des Watchdogs. Schöne Grüße Sören
Jetzt Nicht schrieb: > Den Ressetpin sollte man nit einem 10k Pullup und 100nF gegen GND > beschalten... Warum denn nit? ;-) MfG Paul
Paul Baumann schrieb: > Warum denn nit? Dei 100nF stören das Debugwire, falls der unbekannte AVR dieses benutzt.
Peter Dannegger schrieb: > Dei 100nF stören das Debugwire, falls der unbekannte AVR dieses benutzt. Anscheinend tut er das, denn Sören schrieb: > Auf einen Kondensator habe ich verzichtet aus Sorge, dass dann das > Programmieren oder debugWire Probleme macht. Das Programmieren macht mit einem 10nF Kondensaotor keine Probleme. Beim Debuggen schon. Aber derselbe Sören schrieb: >>> der Reset Pin an meinem ATmega wird lediglich zum Programmieren benutzt Ja was denn nun? Wenn er nur zum Programmieren benutzt wird, dann muss der Kondensator dort hin. Und wenn man über den RST-Pin debuggen will, dann kann man ihn auslöten oder deaktivieren. Und natürlich muss man den BOD einschalten. Wenn man das EEPROM verwendet sowieso, und bei Batteriebetrieb natürlich auch. Sonst ist das wie Autofahren nachts um 2 ohne Licht: kann gut gehen, muss aber nicht...
:
Bearbeitet durch Moderator
Falls der BOD zuviel Strom zieht, gibt's externe Reset Detektoren von zB Microchip wie den MCP111T, der weniger als 1uA zieht
Momentan wird tatsächlich nur programmiert, die Option debugWire sollte aber offen bleiben. Aber dafür kann das C dann auch ausgelötet werden. Aber nochmal zurück zur ursprünglichen Frage: Wenn der Reset-Pin wie beschrieben ohne äußere Beschaltung betrieben wird, mit welchen Auswirkungen ist dann zu rechnen? Mehrfachnennungen möglich. A keine B sporadisches Reset C sporadisch undefinierter Zustand Ist es tatsächlich möglich, dass der letzte Fall auftreten kann?
Die AVRs haben ein Register, wo die Resetquelle abgespeichert wird. Ob ein externes Reset ausgelöst wurde, kann man damit erkennen. Ich habe auch oft eine LED in der Mainloop blinken. Damit kann man erkennen, ob die Mainloop noch läuft und vielleicht nur ein Peripheriebaustein abgestürzt ist (z.B. Dein Funkmodul). Das Programm schreibe ich auch immer so, daß nie in einer Unterfunktion auf etwas gewartet wird (bis zum St. Nimmerleinstag). Gibt es nichts zu tun, gehts zur Mainloop zurück.
Sören schrieb: > Aber nochmal zurück zur ursprünglichen Frage: Nochmal zurück zum ursprünglichen Vorschlag: - Mach mal ein Foto von dem Aufbau - poste mal das Layout - poste mal deinen Quellcode
Sören schrieb: > Kann es sein, dass durch Einkopplung über die Reset-Leitung > ein undefinierter Zustand eingenommen wird? Kann es sein, dass Du für irgendeinen (scheinbar sehr seltenen) Interrupt keine ISR angelegt hast? Und wieso beschaltest Du Reset nicht einfach so, wie Atmel (AVR042) es empfiehlt? Da (im ersten Satz) steht übrigens auch die Antwort auf Deine Frage: The reset line has an internal pull-up resistor, but if the environment is noisy it can be insufficient and reset can therefore occur sporadically. Refer to datasheet for value of pull-up resistor on specific devices. Connecting the RESET so that it is possible to enter both high-voltage programming and ordinary low level reset can be achieved by applying a pull-up resistor to the RESET line. This pull-up resistor makes sure that reset does AVR Hardware Design Considerations [APPLICATION NOTE] Atmel-2521M-AVR-Hardware-Design-Considerations_ApplicationNote_092014 5 not go low unintended. The pull-up resistor can in theory be of any size, but if the Atmel AVR should be programmed from e.g. STK® 500/AVRISP the pull-up should not be so strong that the programmer cannot activate RESET by draw the RESET line low. The recommended pull-up resistor is 4.7kΩ or larger when using STK500 for programming. For DebugWIRE to function properly, the pull-up must not be smaller than 10kΩ. To protect the RESET line further from noise, it is an advantage to connect a capacitor from the RESET pin to ground. This is not directly required since the AVR internally have a low-pass filter to eliminate spikes and noise that could cause reset. Applying an extra capacitor is thus an additional protection. However, note that this capacitor cannot be present if DebugWIRE or PDI is used. If not using High Voltage Programming it is recommended to add an ESD protecting diode from RESET to Vcc, since this is not internally provided due to High Voltage Programming. Alternatively, or in addition, a Zener diode can be used to limit the RESET voltage relative to GND. The Zener diode is highly recommended in noisy environments. The components should be located physically close to the RESET pin of the AVR. Figure 2-1 shows the recommended circuit on the RESET line.
Thomas schrieb: > Nochmal zurück zum ursprünglichen Vorschlag: > - Mach mal ein Foto von dem Aufbau > - poste mal das Layout > - poste mal deinen Quellcode Nicht alles hier muss nun zwanghaft opensource sein, und wenn er schreibt, dass genügend abgeblockt ist, dann glaub' ich das auch mal.
Jörg Wunsch schrieb: > schreibt, dass genügend abgeblockt ist, dann glaub' ich das auch > mal. Dann muss es laufen! Ohne source kann man nicht prüfen was an seiner perfekten hardware passiert
Sören schrieb: > der Reset Pin an meinem ATmega wird lediglich zum Programmieren benutzt > und ist abgesehen davon nicht beschaltet. Es gibt also nur den internen > Pull-up Widerstand. Jörg Wunsch schrieb: > Nicht alles hier muss nun zwanghaft opensource sein, und wenn er > schreibt, dass genügend abgeblockt ist, dann glaub' ich das auch > mal Wo schreibt er das denn? Sören schrieb: > Jetzt hab ich mal einen 10k Pull-up für die Reset-Leitung eingefügt. Auf > einen Kondensator habe ich verzichtet aus Sorge, dass dann das > Programmieren oder debugWire Probleme macht. Da schreibt er nur, dass er einen 10K Pull-up spendiert hat - nicht mehr. Ob das etwas bewirkt hat wird nicht mitgeteilt ... Ganz am Anfang schreibt er auch von einem Sender ...und einer relativ langen Leitung zur Programmierbuchse ... Sören schrieb: > Die Leitungslänge zur Programmierbuchse beträgt > mehrere cm. > Die Anwendung enthält auch ein sendendes Funkmodul, für das die > Reset-Leitung evtl. eine Antenne darstellt.
Es ist tatsächlich so, dass ich die Schaltpläne und Quellen nicht veröffentlichen möchte bzw. darf. Ich hab jetzt noch einen Kondensator mit eingebaut und lasse das ganze über das lange Wochenende laufen. Eine LED für die Main Loop kommt dann noch, wenn's weiter Probleme geben sollte. Was mir aber immer noch unklar ist, ob es prinzipiell überhaupt möglich ist, dass der uC über die mehr oder weniger offene Reset-Leitung in einen undefinierten Zustand geht. Danke mal soweit. Jetzt ist erst mal Feierabend.
NoPlanNoPrg schrieb: > Sören schrieb: >> Die Frage: Kann es sein, dass durch Einkopplung über die Reset-Leitung >> ein undefinierter Zustand eingenommen wird? > > Nein. Es liegt an der Spannungsversorgung. Alles andere fällt in den > Bereich der Spekulation. Das ist eine kühne Behauptung! Sein kann es natürlich, müssen muss es aber nicht. Es kann auch sein, dass die Firmware schlecht programmiert ist und der Stack ab und zu crasht (auch nur eine Möglichkeit von mehreren). Um den Einfluss auf die Resetleitung per EMV sicher auszuschließen, würde ich diese einfach einmal versuchsweise auf Vcc löten und ein paar Tage abwarten, was passiert. Vermuten würde ich so wenig wie Ihr, dass ein Einfluss auf der Resetleitung undefinierte Zustände hervorruft, aber wenn man man auf die Idee gekommen ist, stellt man den Verfolgungswahn am einfachsten durch ein ausschließendes Experiment ab, finde ich.
Sören schrieb: > Was mir aber immer noch unklar ist, ob es prinzipiell überhaupt möglich > ist, dass der uC über die mehr oder weniger offene Reset-Leitung in > einen undefinierten Zustand geht. Dieter Frohnapfel schrieb: > The reset line has an internal pull-up resistor, but if the environment > is noisy it can be insufficient and reset can > therefore occur sporadically. Zur Not kannst Du ja Google-Sprachtools zur Übersetzung benutzen.
Wobei - ein HW-Reset würde ja (soweit mir bekannt) komplett durchstarten. Sören schrieb: > Nach Neuanlegen der > Betriebsspannung funktioniert alles wieder wie erwartet. Wie nach einem HW-Reset ... Ich tippe daher eher auf einen unbehandelten Interrupt ...
Vielen Dank jedenfalls und ein schönes Wochenende! Der Threat kann geschlossen werden!
Sören schrieb: > Der Threat kann geschlossen werden! Erst, wenn Du vom Interrupt zurück bist. ;-) MfG Paul
Sören schrieb: > Der Threat kann geschlossen werden! Schön - und was war die Ursache? Würde sicher alle Beteiligten interessieren ..
Dieter Frohnapfel schrieb: > Sören schrieb: >> Was mir aber immer noch unklar ist, ob es prinzipiell überhaupt möglich >> ist, dass der uC über die mehr oder weniger offene Reset-Leitung in >> einen undefinierten Zustand geht. > > Dieter Frohnapfel schrieb: >> The reset line has an internal pull-up resistor, but if the environment >> is noisy it can be insufficient and reset can >> therefore occur sporadically. > > Zur Not kannst Du ja Google-Sprachtools zur Übersetzung benutzen. Einen Reset sehe ich nicht als einen undefinierten Zustand. Das Aufhängen des µC, von dem der TE im Ausgangspost schreibt ist kein Reset und kann sonstwo her rühren. Ich habe keine weitere Idee dazu als alle Vorsichtsmaßnahmen und Schutzbeschaltungen für die Ports auszuprobieren. µC tauschen?
NoPlanNoPrg schrieb: > Dieter Frohnapfel schrieb: >> Sören schrieb: >>> Was mir aber immer noch unklar ist, ob es prinzipiell überhaupt möglich >>> ist, dass der uC über die mehr oder weniger offene Reset-Leitung in >>> einen undefinierten Zustand geht. >> >> Dieter Frohnapfel schrieb: >>> The reset line has an internal pull-up resistor, but if the environment >>> is noisy it can be insufficient and reset can >>> therefore occur sporadically. >> >> Zur Not kannst Du ja Google-Sprachtools zur Übersetzung benutzen. NoPlanNoPrg schrieb: > Einen Reset sehe ich nicht als einen undefinierten Zustand. Das > Aufhängen des µC, von dem der TE im Ausgangspost schreibt ist kein Reset > und kann sonstwo her rühren. > > Ich habe keine weitere Idee dazu als alle Vorsichtsmaßnahmen und > Schutzbeschaltungen für die Ports auszuprobieren. µC tauschen? Schön wäre es, wenn Du vollständig zitieren würdest - es fehlt nämlich der Folge-Post ... Dieter Frohnapfel schrieb: > Wobei - ein HW-Reset würde ja (soweit mir bekannt) komplett > durchstarten. > > Sören schrieb: >> Nach Neuanlegen der >> Betriebsspannung funktioniert alles wieder wie erwartet. > > Wie nach einem HW-Reset ... > > Ich tippe daher eher auf einen unbehandelten Interrupt ... was ich auch schon einige Posts weiter oben bemerkt habe ..
Lustigerweise hat sich der TO ja ausgeschaltet - das tue ich dann auch, da das Thema / der Post wohl beendet ist ... Also vermute ich mal, dass ich richtig lag ... :-)
Sören schrieb: > Was mir aber immer noch unklar ist, ob es prinzipiell überhaupt möglich > ist, dass der uC über die mehr oder weniger offene Reset-Leitung in > einen undefinierten Zustand geht. Selbstverständlich ist es das. Wenn er sich durch die Antenne Spikes einfängt, die jenseits der Specs liegen, dann gibt's über die Schutzdioden einen Impuls in die Versorgungsspannung, davon kann schon mal ein Flipflop falsch kippen.
Jörg Wunsch schrieb: > Nicht alles hier muss nun zwanghaft opensource sein, und wenn er > schreibt, dass genügend abgeblockt ist, dann glaub' ich das auch > mal. Jörg Wunsch schrieb: > Sören schrieb: >> Was mir aber immer noch unklar ist, ob es prinzipiell überhaupt möglich >> ist, dass der uC über die mehr oder weniger offene Reset-Leitung in >> einen undefinierten Zustand geht. > > Selbstverständlich ist es das. Wenn er sich durch die Antenne > Spikes einfängt, die jenseits der Specs liegen, dann gibt's über > die Schutzdioden einen Impuls in die Versorgungsspannung, davon kann > schon mal ein Flipflop falsch kippen. Ja. S.o.
Dieter Frohnapfel schrieb: > Ja. S.o. Das mit dem „genügend abgeblockt“ bezog ich jetzt auf die Versorgung, denn danach hatte ich zuvor gefragt. Dass der Reset-Pin offen ist, war ja unzweifelhaft.
So, jetzt ist die Schaltung fünf Tage am Stück durchgelaufen. Das ist mit Abstand ein Rekord! Es sieht also ganz so aus, als ob die Maßnahmen erfolgreich waren (10k Pull-up Widerstand und 100nF Kondensator an der Reset-Leitung). Alles andere blieb unverändert, es wurden auch keine neuen Batterien eingesetzt. Vielen Dank nochmal für die Hinweise. Wenn ich trotzdem weiter fragen darf: In den Beiträgen tauchte immer wieder die Vermutung nach unbehandelten Interrupts auf, was grundsätzlich natürlich sein kann. Ist es aber nicht so, dass der AVR-GCC eine default Interrupt Tabelle anlegt, indem jeder Interrupt-Vektor vorkommt? Oder muss dazu ein bestimmtes Compiler-Flag gesetzt werden? Außerdem: Jetzt nehmen wir mal an, dass die Batteriespannung einbricht, wenn das Funkmodul zu senden beginnt. Ohne weitere Maßnahmen verstolpert sich der Controller und hängt sich auf. Wenn jetzt der Brown-out Detector aktiv ist, wird ein Reset ausgelöst. Der Controller läuft neu an bis zur gleichen Stelle, an der wieder der Brown-out Detector zuschlägt. In beiden Fällen habe ich nun keine Funktion mehr. Oder anders gefragt, was hilft hier der Brown-out Detector?
Sören schrieb: > Es sieht also ganz so aus, als ob die Maßnahmen erfolgreich waren (10k > Pull-up Widerstand und 100nF Kondensator an der Reset-Leitung). Dann solltest du vielleicht ja auch noch die in der Appnote genannte Diode (Eingang nach Vcc) mit anbringen. Der Grund für diese Diode ist, dass der Reset-Eingang eine solche nicht bereits integriert hat, da er ja 12-V-fähig (für HV-Programmierung) sein muss. > In den Beiträgen tauchte immer wieder die Vermutung nach unbehandelten > Interrupts auf, was grundsätzlich natürlich sein kann. > Ist es aber nicht so, dass der AVR-GCC eine default Interrupt Tabelle > anlegt, indem jeder Interrupt-Vektor vorkommt? Das macht nicht der Compiler, sondern der Startup-Code der Bibliothek. Der wiederum würde allerdings (by default) zu einem Neustart ab Adresse 0 führen, was bei dir ja nicht der Fall war. Insofern war der entsprechende Hinweis inkorrekt. > In beiden Fällen habe ich nun keine Funktion mehr. Oder anders gefragt, > was hilft hier der Brown-out Detector? Du könntest nach dem Reset feststellen, dass der Brownout-Detektor zugeschlagen hat und entsprechend reagieren, also gar nicht erst wieder versuchen zu senden.
Jörg Wunsch schrieb: > Der wiederum würde allerdings (by default) zu einem > Neustart ab Adresse 0 führen, was bei dir ja nicht der Fall war. > Insofern war der entsprechende Hinweis inkorrekt. Das sehe ich nicht so. Der unbehandelte "Bad-Interrupt" erzeugt (i.d.R., falls nicht anders definiert) einen Sprung an den Programmanfang. Das Programm fängt von vorne an - und wenn der Auslöser für den unbehandelten Interrupt immer noch da ist wiederholt sich das bis St. Nimmerlein ... Hast Du übrigens auch im Thread Beitrag "was passiert bei Interrupt ohne Routine" am : 24.08.2008 21:37 so geschrieben :-)
Sören schrieb: > In den Beiträgen tauchte immer wieder die Vermutung nach unbehandelten > Interrupts auf, was grundsätzlich natürlich sein kann Jetzt bin ich aber neugierig - gibt es in Deinem Programm unbehandelte Interrupts? Vermutlich werde ich diesbezüglich dumm sterben ... :-(
Dieter Frohnapfel schrieb: > Das Programm fängt von vorne an - und wenn der Auslöser für den > unbehandelten Interrupt immer noch da ist wiederholt sich das bis St. > Nimmerlein ... OK, in einem solchen Falle stimmt es natürlich. Allerdings löschen sich die meisten Interruptbedingungen beim Eintreten in die ISR selbst. (Der im verlinkten Beitrag genannte UART-Interrupt ist eine der wenigen Ausnahmen in dieser Hinsicht.)
Jörg Wunsch schrieb: > Allerdings löschen sich die meisten Interruptbedingungen beim Eintreten > in die ISR selbst. Wenn es diese denn gibt - aber weder Du noch ich wissen um den - möglicherweise - betroffenen Interrupt. Und bei einer "Bad Isr-Routine" - ohne RETI - würde ich nichts verwetten ...
Dieter Frohnapfel schrieb: > Und bei einer "Bad Isr-Routine" - ohne RETI Der RETI ist wurscht, das ist kein Z80, bei dem die Peripherie den Opcode dechiffriert und dann die Daisy-Chain rücksetzt. Der einzige Effekt des RETI ist das Erlauben der Interrupts, aber das würde beim Reinitialisieren der Applikation nach einem Sprung auf Adresse 0 durch einen späteren SEI genauso passieren. Sören wird sich da einfach nur Spikes eingefangen haben, die die CPU in einen undefinierten Zustand verbracht haben. Dafür brauchen die keine umständlichen Interrupts erst. :-)
Diese Auskunft möchte ich nicht schuldig bleiben: Für jede Interrupt-Quelle, die aktiviert wurde, gibt es auch einen Handler. Allerdings keinen, der die übrigen Interrupts einfangen würde. Also, vielen Dank nochmal!
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.