Moin, ich habe einen ATMEGA88 mit dem ich ein Drehencoderinterface bauen will. Ich habe am PORTC zwei Drehencoder angeschlossen. Der Erste verwendet PC0,1 der Zweite PC2,3. Die Pins sind als Eingänge konfiguriert, die Pullups sind aktiviert. Die Encoder schalten gegen GND. Ich habe mich an dem Beispiel vom Drehencoderartikel bei der Softwaregestaltung inspirieren lassen. Soweit so gut, Drehencoder 1 an PC0,1 arbeitet ohne Probleme. Sobald man jedoch einen Rastpunkt des Encoders an PC2,3 weiterdreht wird sofort der RESET des Mikrocontrollers ausgelöst. Ich habe mittlerweile herausgefunden, dass der RESET durch die BOD ausgelöst wird. Bei deaktivierter bzw. BODLEVEL = 1V8 funktioniert alles ohne Probleme. Bei einem BODLEVEL > 1V8 wird der Reset beim drehen des zweiten Encoders ausgelöst. Des Weiteren habe ich herausgefunden, dass NUR der Pin PC2 hierfür verantwortlich ist. Das Phänomen ist durch direktes Kurzschließen von PC2 gegen GND mit aktivierter BOD reproduzierbar. Ich stehe etwas auf dem Schlauch und weiß um ehrlich zu sein nicht so recht weiter. VCC und AVCC haben jeweils einen eigenen 100nF kondensator, der knapp 2mm neben den Pins liegt. AREF hat einen 100nF Stützkondensator. (Irgendwo habe ich mal gelesen, dass dieser installiert werden soll, auch wenn der ADC nicht genutzt wird.) So wirklich erklären kann ich mir das nicht. Die beiden VCC Pins und der AVCC Pin wurden von mir schon mal mit dem Oszi beobachtet, keinerlei Peaks oder Einbrüche auf der Versorgungsspannung. Der Controller wurde auch schon versuchsweise einmal getauscht, ändert nichts an der Situation. Hat jemand eine gute Idee, was noch dafür verantwortlich sein könnte, dass der BOD-Reset ausgelöst wird?
:
Bearbeitet durch User
Hi Vielleicht sind deine Eingänge doch Ausgänge. MfG Spess
Moin, spess53 schrieb: > Vielleicht sind deine Eingänge doch Ausgänge. Habs gegengecheckt.
1 | DDRC &= ~((1<<DDC0) | (1<<DDC1) | (1<<DDC2) | (1<<DDC3)); |
2 | PORTC |= (1<<PORTC0) | (1<<PORTC1) | (1<<PORTC2) | (1<<PORTC3); |
Das ist die Einstellung für den Port. Wenn es Ausgänge wären, dann würde das Drehencoderinterface ja auch mit ausgeschalteter BOD nicht funktionieren. Sobald diese aus ist arbeitet es aber einwandfrei. Ich habe auch schon probiert externe Pullups zu verwenden. Verändert leider auch nichts.
:
Bearbeitet durch User
Hi
>Sobald diese aus ist arbeitet es aber einwandfrei.
BOD kennt nicht nur ein- oder ausgeschaltet. Bei welchem BOD-Level
funktioniert es nicht mehr? Wie sieht deine Stromversorgung aus?
MfG Spess
spess53 schrieb: > BOD kennt nicht nur ein- oder ausgeschaltet. Bei welchem BOD-Level > funktioniert es nicht mehr? Wie sieht deine Stromversorgung aus? Das habe ich in meinem ersten Post bereits geschrieben. Helge O. schrieb: > Ich habe mittlerweile herausgefunden, dass der RESET durch die BOD > ausgelöst wird. Bei deaktivierter bzw. BODLEVEL = 1V8 funktioniert alles > ohne Probleme. Bei einem BODLEVEL > 1V8 wird der Reset beim drehen des > zweiten Encoders ausgelöst. Sobald ein BODLEVEL > 1V8 eingestellt ist löst die BOD beim herunterziehen von PC2 aus.
Helge O. schrieb: > Das habe ich in meinem ersten Post bereits geschrieben. Nö, da ist die Rede von Kondensatoren, aber nicht wie VCC bereitgestellt wird. Zeige doch einfach Schaltplan und Bild vom Aufbau und dann kann man auch schneller suchen.... Sonst bleibt nur: Lötfehler, Platine defekt, Programm defekt. LG Sven
Helge O. schrieb: > Sobald ein BODLEVEL > 1V8 eingestellt ist löst die BOD beim > herunterziehen von PC2 aus. Ich würde erst mal einen Gegentest mit einem möglichst einfachen Programm machen (wie kannst du Resets feststellen? Hast du irgendwo eine LED, die dazu dienen könnte?)
1 | #include <avr/io.h> |
2 | #include <util/delay.h> |
3 | |
4 | #define LED_DDR DDRB
|
5 | #define LED_PORT PORTB
|
6 | #define LED_PIN PB0
|
7 | |
8 | int main() |
9 | {
|
10 | LED_DDR |= (1<<LED_PIN); |
11 | |
12 | PORTC |= ( 1 << PC2 ); |
13 | |
14 | LED_PORT &= ~(1<<LED_PIN); |
15 | _delay_ms( 1000 ); |
16 | LED_PORT |= (1<<LED_PIN); |
17 | _delay_ms( 1000 ); |
18 | LED_PORT &= ~(1<<LED_PIN); |
19 | |
20 | while( 1 ) |
21 | ;
|
22 | }
|
und dann den Pin PC2 nochmal auf Masse schliessen. An besagter LED darf sich nach dem ersten Blinker direkt nach Anlegen der Versorgung nichts tun. Wenn doch, dann hast du ein Hardwareproblem. Irgendwas mit deiner Stromversorgung. Wenn sich nichts tut, dann würde ich mal nicht ausschliessen, dass du in deinem Encoderprogramm einen Fehler hast und dir irgendwo die Portkonfiguration zerschiesst.
:
Bearbeitet durch User
Angehängte Dateien:
-
sch.png
8,8 KB
Sven schrieb: > Nö, da ist die Rede von Kondensatoren, aber nicht wie VCC bereitgestellt > wird. Zeige doch einfach Schaltplan und Bild vom Aufbau und dann kann > man auch schneller suchen.... Quelle ist ein DF-1730SB Labornetzgerät welches auf 5V eingestellt ist. "Minimalschaltplan" habe ich angehängt, eine zusätzliche LED ist auch noch vorhanden. Karl Heinz schrieb: > Wenn doch, dann hast du ein Hardwareproblem. Irgendwas mit deiner > Stromversorgung. Lötfahnen oder sonstige Kurzschlussverursacher kann ich ausschließen. Der µC wurde schon von der Platine heruntergenommen (ist nen TQFP), alle Pins wurden Gegeneinander gemessen. Karl Heinz schrieb: > Ich würde erst mal einen Gegentest mit einem möglichst einfachen > Programm machen > (wie kannst du Resets feststellen? Hast du irgendwo eine LED, die dazu > dienen könnte?) So etwas ähnliches habe ich mir geschrieben:
1 | #include <avr/io.h> |
2 | |
3 | int main(void) |
4 | {
|
5 | DDRD |= (1<<DDD6); // LED Ausgang |
6 | DDRC &= ~(1<<DDC2); // Eingang |
7 | |
8 | |
9 | PORTC |= (1<<PORTC2); // Pullup ein |
10 | |
11 | while(1) |
12 | {
|
13 | PORTD |= (1<<PORTD6); |
14 | }
|
15 | }
|
Mittlerweile habe ich gerausgefunden, dass offenbar die steile Flanke durch den Inkrementalgeber an PC2 schuld ist für das Auslösen der BOD. Die Versorgungsspannung habe ich direkt am µC-Pin Oszilloskopiert, da sieht man leider absolut gar nichts.
Helge O. schrieb: > Mittlerweile habe ich gerausgefunden, dass offenbar die steile Flanke > durch den Inkrementalgeber an PC2 schuld ist für das Auslösen der BOD. Sowas ähnliches haben sich die meisten hier wohl schon gedacht. Du hast aber nicht 'zufällig' an den Encoderpins ein paar kleinere Kondensatoren zur Entprellung angebracht? > Die Versorgungsspannung habe ich direkt am µC-Pin Oszilloskopiert, da sieht man leider absolut gar nichts. Ist nicht weiter verwunderlich. Ein paar einzelne Spikes im Nanosekundenbereich wirst du dort auch nicht sehen können. Aber die BOD spricht darauf an.
:
Bearbeitet durch User
Karl Heinz schrieb: > Du hast aber nicht 'zufällig' an den Encoderpins ein paar kleinere > Kondensatoren zur Entprellung angebracht? Anfangs hingen da 100pF dran, die sind mittlerweile runtergeflogen. Hat nichts verändert. Karl Heinz schrieb: > Ist nicht weiter verwunderlich. Ein paar einzelne Spikes im > Nanosekundenbereich wirst du dort auch nicht sehen können. Aber die BOD > spricht darauf an. Versteh ich aber dann trotzdem nicht. Selbst wenn ich einen externen Pullup, sagen wir mal 10k, verwende dann passiert das.
Hmm, dann würde ich testweise die Stromversorgung tauschen gegen einen 7805 mit Hühnerfutter drumherum. Ganz sicher das es auch 100nF keramische Kondensatoren sind ? Nicht dass diese einen zu kleinen Wert haben...... LG Sven
Sven schrieb: > Ganz sicher das es auch 100nF keramische Kondensatoren sind ? > Nicht dass diese einen zu kleinen Wert haben...... Jap 100nF Keramik. So wie es aussieht habe ich den Fehler gefunden: Der im Schaltplan vorhandene C15. Den habe ich eben aus lauter Verzweifelung heruntergeschmissen, mit dem Ergebnis, dass die BOD nicht mehr ausgelöst wird. Warum ausgerechnet der daran die Schuld trägt ist mir jedoch schleierhaft...
>Warum ausgerechnet der daran die Schuld trägt ist mir jedoch >schleierhaft... Du hast es mit Elektronik zu tun.... Wer da nicht an Wunder glaubt, ist kein Realist. Jruß Jüntha
Karl Heinz schrieb: > Ist nicht weiter verwunderlich. Ein paar einzelne Spikes im > Nanosekundenbereich wirst du dort auch nicht sehen können. Aber die BOD > spricht darauf an. Ist das so? "The BOD circuit will only detect a drop in VCC if the voltage stays below the trigger level for longer than tBOD given in “System and reset characteristics” on page 307" und dort "tBOD, Min pulse width on brown-out reset, 2 µs"? Ich frage, weil mich die brown-out-Logik zur Zeit bei meinem Projekt auch umtreibt ... Helge O. schrieb: > So wie es aussieht habe ich den Fehler gefunden: Der im Schaltplan > vorhandene C15. Den habe ich eben aus lauter Verzweifelung > heruntergeschmissen, mit dem Ergebnis, dass die BOD nicht mehr ausgelöst > wird. > > Warum ausgerechnet der daran die Schuld trägt ist mir jedoch > schleierhaft... Hast du die interne 1.1V-Referenz als ADC-Input ausgewählt und dadurch an AREF angekoppelt? Dann bekonnst du eventuell Störungen auf GND (z.B. durch den Drehencoder) durch C15 auf die interne 1.1V-Referenz eingekoppelt, die dann ja auch für die BOD-Erkennung benutzt wird ("The Atmel ATmega48/88/168 features an internal bandgap reference. This reference is used for brown-out detection, and it can be used as an input to the analog comparator or the ADC"). Jüntha schrieb: > Wer da nicht an Wunder glaubt, ist kein Realist. Ich glaube an Wunder. Es ist z.B. ein Wunder dass es uns gibt. In Bezug auf Elektronik bevorzuge ich allerdings weniger wunderliche Erklärungen. LG, Sebastian
:
Bearbeitet durch User
Moin, Sebastian Wangnick schrieb: > Hast du die interne 1.1V-Referenz als ADC-Input ausgewählt und dadurch > an AREF angekoppelt? ne, beim ADC ist gar nichts kofiguriert (siehe Software, die ich oben gepostet habe). Jüntha schrieb: > Du hast es mit Elektronik zu tun.... > > Wer da nicht an Wunder glaubt, ist kein Realist. Jeder vertritt da seine eigene Meinung. Ich glaube eher, dass es zu jedem praktischen Problem auch einen theoretischen Ansatz gibt. Man muss nur den richtigen finden.
Ich bleibe bei Problemen mit der Spannungsversorgung. C15 stabilisiert ARef. Intern wird sie benutzt für den BOD. Baust Du C15 aus, läuft die interen Refspannung mit der Spannung für BOD. Damit läuft der Prozessor. Das Problem ist aber nicht weg. Mein Vorschlag: C15 einbauen. 10µH an AVCC wie im Datenblatt von VCC + 100nF an AVCC. Spannungsquelle 7805 + Hühnerfutter! und 9V vom Netzteil oder Batterie. Gruß Sven
Sven schrieb: > läuft die interen Refspannung mit der Spannung für > BOD Damit meine ich mit-laufen / gleichlaufen
ich denke auch das es die Stromversorgung ist. Da fehlen sämtliche Puffer C's, der Filter für AVCC wurde ja auch schon genannt und wenn ein 10kOhm Pullup gegen GND schon für Probleme sorgt dürfte die Spannungsversorgung sehr schwach ausgelegt sein. Mit welcher Frequenz läuft dein AVR nicht das der mit Volldampf fährt und dann eine höhere Betriebsspannung braucht, war bei den älteren Typen so, da gingen 8 MHz z.B. nur mit 5V Versorgungssapnnung. JTAG ist deaktiviert(kann man per Software machen), falls es dieser Typ hat, sonst haben deine Pins vielleicht doch ne andere Funktion? Nicht das da ein Ausgang auf GND gelegt wird dann wäre es kein Wunder wenn die Spannung einbricht oder das Netzteil in die Strombegrenzung geht.
Ein Möglichkeit wäre noch: Sven schrieb: > C15 stabilisiert ARef. > Intern wird sie benutzt für den BOD. > > Baust Du C15 aus, läuft die interen Refspannung mit der Spannung für > BOD. Damit läuft der Prozessor. Ein Möglichkeit wäre noch: Masseproblem. Wie hängen die Abblock-C's am µC? Ganz nahe? Ist der GND "solide"? Je nach Aufbau könnte der µC beim Arbeiten seinen GND "hüpfen" lassen, und diese Störungen werden über C15 in AREF eingekoppelt. Gruß Dietrich
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.