Menü
Aktuelles
Von:
Filter

RESET cause: watchdog

Hi ich habe heute ein paar resets gehabt, nachdem ich die pull-up-Widerstände abgelötet habe, die ich direkt auf den M4 gelötet hatte (ich habe das board 1.4 und bis jetzt die pull-up-Widerstände auf der Hauptplatine UND auf dem M4). Ich habe die Lötbrücken und die 4,7kOhm Widerstände jetzt noch einmal nachgelötet und durchgemessen.
Außerdem habe ich die RX und TX Kabel am RTK-Rovermodul mal nachgesetzt, da ich nach dem ständigen rein und raus bauen schon knickstellen in den kabeln hatte und sowieso, wie ich finde, viel zu viele GPS Checksum Errors habe (ca 1-2 pro Stunde). Dieses scheinen aber dem Mähvorgang nicht wirklich zu beeinflussen, aber die regulären pull-up-Widerstände schon. ich habe mal in Schaltplan geschaut: und wenn es nicht an den Widerständen selbst liegt, können es nur noch die SN74LVC1T45DBV oder die PCA9517ADP sein. Hat dort schonmal jemand Probleme gehabt? Ich kann mir irgendwie nicht vorstellen, dass diese Dinger kaputt gehen. Eventuell ist es auch ein anderes Gerät, welches auf dem I2C-Bus hängt, welches den Bus "blockiert" und so den M4 zum stocken bringt. Geht der eingebaute SD-Kartenslot auch über den I2C-Bus? So könnte auch einZusammenhang bestehen...
Da ja die SD-Karten-Problematik ziemlich vielversprechend ist, werde ich nochmal auf die SD-Karte schauen und versuchen, sie nochmal zu formatieren oder gar gegen eine andere Karte zu tauschen.
 
Wenn du weiter mit der SD-Karte experimentieren willst, dann gucke dir mal die robot.cpp an und suche dort nach
Code: 
  // state saving
  if (millis() >= nextSaveTime){ 
    nextSaveTime = millis() + 5000;
    saveState();
  }
das müsste so in Zeile 877 sein und ersetze das durch
Code: 
  // state saving
  if (millis() >= nextSaveTime){ 
    if(!robotShouldMove()){
      nextSaveTime = millis() + 5000;
      saveState();
    }
  }
Dadurch wird nur noch gespeichert, wenn der Mäher gerade keine Linearbewegung macht, sondern sich nur noch um die eigene Achse dreht. Eigentlich habe ich das gemacht, um das Erschütterungsniveau beim Speichern zu reduzieren. Das hat auch soweit funktioniert. Bei mir gibt es mit diesem Workaround keinerlei Probleme mehr. Sollten aber doch Resets auftreten, dann hat der der Workarround den positiven Nebeneffekt, dass der Mäher bis zum Reset nicht mehr ins Beet oder sonstwohin fahren, sondern sich nur noch 16 Sekunden lang um die eigene Achse drehen kann. Das halte ich für einen deutlichen Sicherheitsgewinn.
 
Das ist natürlich eine feine Sache. Aber es ändert natürlich nichts am Problem selbst. Ich habe die sd-Karte neu formatiert, aber von den 8GB Speicher waren gerade einmal 4kB belegt. Ich habe heute mal den esp32 auf dem Tisch gehabt. Gereinigt ?und alle Lötstellen nachgelötet. Ich hatte nämlich seit gestern das Phänomen, dass ich der Mäher beim fernsteuern über die App nicht mehr angehalten hat. Das Problem konnte ich lösen. Als nächstes würde ich einfach die zusätzlichen pull-up-Widerstände einlöte. Damit hat es 100% funktioniert. Ich würde es auch mal ohne die lötbrücken versuchen. Kann ich das gps-Modul auch woanders anschließen? So könnte ich Probleme auf der Hauptplatine ausschließen.
 
ein weiteres Update: Der Roboter ist mit formatierter SD-Karte wieder liegen geblieben und nun habe ich wieder die beiden 2,2kOhm Widerstände eingelötet. Nun mit den parallel geschalteten pull-up-Widerständen läuft der Mäher wieder wie am Schnürchen. dafür gibt es zwei mögliche Erklärungen:

1. Der Widerstandswert ist beim PCB 1.4 mit 4,7kOhm zu hoch, sodass die Signalflanke nicht steil genug ist und das Signal unsauber ist.
2. Der pull-up-Widerstand ist beim PCB 1.4 nicht nahe genug am Prozessor und durch die Länge der zusätzlichen Leiterbahn kommt es zu Störungen.

eventuell ist es auch eine Mischung aus beiden Varianten und ich benötige je einen pull-up am Anfang und am Ende der Signalstrecke.
Wo liegen eigentlich die Grenzen der pull-up-Widerstände bzw. ist ein Widerstandswert von 1,725kOhm auf Dauer problematisch?
 
Inzwischen habe ich ein wenig recherchiert und bin zu dem Entschluss gekommen, dass 1,725kOhm zumindest bei mir bleiben. Warum auch immer es nicht mit 4,7kOhm geht aber der DUE hat 1,5kOhm pull-up-Widerstände drauf und in einem anderen Forum habe ich gesehen, dass jemand 1,8kOhm für den M4 nutzt. Der berechnete Strom liegt bei mir knapp unter 2mA (für atmegas gibt es wohl empfohlene Mindestströme, aber darüber habe ich nicht viel gefunden) und je niedriger der Widerstand, desto schneller der Bus.
 
Das ist schon sehr merkwürdig bei dir. Eigentlich sollen die PullUps nur für einen definierten Zustand sorgen. Von daher sollten sehr hochohmige Widerstände ausreichen. Vielleicht hast du an irgendeiner Lötstelle Kriechströme… oder deine Steckerleiste zwischen AGCM4 und PCB macht keine saubere Verbindung.
 
Also die 3,3v und die beiden datenleitungen für den Bus haben eine 100% sichere Verbindung. Die habe ich gemessen. Das mit den Kriechströmen kann ich nicht ausschließen, aber durch Schmutz auf der Platine ist das ziemlich unwahrscheinlich. Die Platine wurde erst mit isopropanol gereinigt und sieht aus wie neu… unter die Bauteile kann ich zwar nicht gucken, aber das müsste ich durch den Austausch sämtlicher Komponenten ausschließen. Anderes Board, anderes GPS Modul, anderer esp, andere imu. Was ich noch machen könnte, sind die beiden GPS-Module umflashen (Rover und base tauschen), denn das Base-Modul braucht keine Datenverbindung zum Laufen… eine andere IMU und einen esp habe ich noch da. Dann könnte ich noch alle Elemente vom i2c Bus auslöten, alles darunter reinigen und wieder einlöten. Das ist aber ein Riesen-Aufwand, und wäre mMn eher ein Winterprojekt. Vielleicht kann ich mit dem oszilloskop etwas auf dem i2c-Bus messen
 
Nein, das würde ich gar nicht machen. Durch das Aus- und Einlöten wird das alles auch nicht besser. Mit dem Oszi macht schon mehr Sinn. Das Signal muss dann auch mit dem 4.7kOhm-PullUp sauber auf 3.3V gehen. Tut sie das nicht, ist da etwas faul. Ggf. auch mal an den Komponenten wackeln und dabei das Oszi beobachten.
 
ich kann mir nicht vorstellen, dass es eine kalte lötstelle sein soll oder so, da das Problem erst seit dem upgrade von DUE auf M4 besteht. eher defekte Bauteile auf dem i2c Bus, welche jetzt ein unsauberes Signal durchschalten oder eine erhöhte störanfälligkeit des M4 gegenüber Motoren und Treibern. Glücklicherweise habe ich in einem anderen Forum die bauteilbezeichnung der SOT-23-6 Bauelemente auf dem RTK2B-F9P board gefunden: SN74LVC1G3157DBVR (falls das jemand wissen möchte :p )
Ich habe die Vermutung, dass die GPS Checksum errors bei mir in direktem Zusammenhang mit den Resets stehen. denn die treten in der gleichen häufigkeit auf, wie die resets. mit 4,7kOhm pull-ups kommt es zum reset, mit 1,7k Pull-ups kommt einfach "nur" ein gps checksum error. da die Probleme eher mit unter Last laufenden Motoren auftreten, wird das Problem im Labor nur sehr sehr schwer zu reproduzieren sein. Aber wie schon gesagt, vielleicht kann ich mit dem Oszi etwas erkennen...
 
GSP Chscksum errors können auch von defekten Koaxialkabeln kommen, so hatte ich das dieses Frühjahr. Oder auch Kabelverbindung zwischen Rover und Ublox Karte, da hatte ich auch einen gesteckten Kontakt mit Unterbrechung. Und die Kiste ist dann nach 10 - 15 Mähbahnen immer stehen geblieben.
 
Darf ich fragen, welches koaxialkabel bei dir defekt war? Und vor allem: kann dadurch ein Watchdog Reset kommen? Die Software könnte jaan jeder X-beliebigen Stelle hängen bleiben und einen Reset auslösen... Mich beschleicht das Gefühl, dass das Problem mit dem Watchdog extrem Vielschichtig und sehr individuell ist...
 
Zuletzt bearbeitet:
Heute habe ich mir mal die Mühe gemacht und bin auf Fehlersuche gegangen:
1. die zusätzlichen pull-up-Widerstände ausgelötet
=> Wieder Watchdog resets
2. den ESP32 gegen einen neuen getauscht
=> Wieder Watchdog resets
3. die Batterie aus der Uhr genommen
=> Wieder Watchdog resets
4. die IMU getauscht
=> Bis jetzt kein einziger Reset mehr
Soll es letztendlich die blöde IMU gewesen sein?
Bis jetzt war die MPU6050 verbaut, nun habe ich die MPU9250 eingebaut. Die IMU wird zwar von sunray nicht erkannt, aber es kommen keine resets mehr… ich habe Ersatz bestellt und werde dann weiter sehen…
 
Die neue MPU6050 ist heute bei mir eingetrudelt. Neues Kabel dran, hat sich nach dem starten kalibriert und es kam wieder zum Reset... also ist es nicht die IMU selbst. Ziehe ich die IMU ab, läuft alles wunderbar. Tatsächlich sind das GPS-Modul und der ESP32 nicht über I2C angeschlossen. Aber die DS1307+ ist am I2C-Bus angeschlossen, wird allerdings nicht von Sunray genutzt. Ich habe die Uhr entfernt und mit dem Multimeter die Datenleitungen durchgemessen. SDA1 gegen 5V+ hatte 780 Ohm. SCL1 gegen Masse hatte 22 Ohm. Bei den anderen I2C Anschlüssen habe ich irgendwas im MOhm-Bereich gemessen. Nun habe ich den I2C Repeater von der Uhr (PC1: PCA9517ADP,118) ausgelötet und nochmal alle die Datenleitungen durchgemessen. Jetzt sind alle Leitungen wie erwartet hochohmig und bis jetzt läuft der Mäher. ich überlege nur, ob es Sinnvoll ist, die Uhr mit einem neuen I2C-Repeater wieder einzubauen...
 
Ich habe anstatt des RTC zwei pull up Widerstände SDA -> VCC und SCL -> VCC verbaut. Funktioniert.
 
Zuletzt bearbeitet:
Heute habe ich wieder resets gehabt. Der i2C repeater war definitiv Schrott, aber nicht Verursacher des Problems… ich muss wohl doch nochmal alles mit loggen und schauen, wo der Kollege hängt. Vielleicht ist ja noch ein anderer i2c repeater hin. Ich werde auch mal die Bus-translater vom GPS und WLAN überprüfen. Kann doch nicht wahr sein
 
Nachdem mein Ardumower unerklärliche Aussetzer hat, habe ich auch mal nachgemessen.
Laut Schaltplan ist SDA/SCL mit jeweils einem 4,7KOhm Widerstand bei geschlossenen Brücken an IOREF angebunden.
Das heißt, ich müsste zwischen den jeweiligen Brücken, bzw. zwischen SDA und SCL vom M4 (Pin20/21) und IOREF den Widerstandswert messen. Tut es aber nicht, es ist hochohmig. Von Pin 20 bzw. Pin 21 des M4 zu den Brücken messe ich Durchgang.
Mir scheint es, das die beiden Lötbrücken keine Verbindung zu den Widerständen oder die Widerstände keine Verbindung zu IOREF haben.
Oder habe ich da einen Gedankenfehler?
 
Miss mal die Widerstände selbst durch (links neben den Brücken) Aber ich bezweifle, dass beide Widerstände gleichzeitig kaputt gehen… was ich eher vermute, dass etwas mit dem Brücken nicht stimmt… Versuch sie mal nachzulöten und dann miss nochmal. Falls du dann immernoch keinen Erfolg hast, kannst du mal die Brücken entfernen und den mod wie beim pcb 1.3 machen…
 
Danke. Fehler gefunden: Beide Lötbrücken waren nicht einwandfrei, IOREF war bis hinter Widerstand okay, bei Lötbrücke nicht mehr. Nachgelötet, jetzt bis zum M4 okay. Und das mir als Elektrotechniker ist das ja jetzt echt peinlich. Trotz Lupe sahen die Lötbrücken eigentlich gut aus.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben