M4 verliert Betriebssystem

kaido

Member
Hallo,

Mein Ardumower resettet sich häufig und verliert sogar ztw. sein Betriebssytem. SD Karte wurde schon gegen eine neue
getauscht. Er lief zwei Jahre einwandfrei und macht jetzt fast täglich diesen Fehler.

Hat jemand eine Idee was ich da nochmal kurzfristig machen kann oder ist da ein neues Board fällig.

Evt. gibt es ja eine Möglichkeit den Chip mal komplett zu löschen bzw. zu formatieren. Wenn ja brauch ich dazu eine kleine
Anleitung.

MfG

Kai
 
Beim Reset würde ich zunächst das Uhrenmodul verdächtigen. Hast du noch eins drin und wie alt ist die Batterie? Batterie entfernen hilft da schon mal weiter.
 
Hallo an alle die mir die netten Tips gegebeben haben.
Ich bin zur Zeit im Urlaub und habe nur sporadisch Internet. Die Tips hatte ich alle befolgt und das System scheint drauf zu bleiben.

Mein eigentliches Problem ist das der Ardumower eigentlich über zwei Jahre seinen Dienst gut ausgeführt hat mit verschiedenen
Firmwares von Svolo und Mr. Tree.
Seit ein paar Wochen habe ich das Problem das er ztw. mal häufig und dann mal wieder garnicht im Idle stehen bleibt. Was vorher zu sehen ist das er ca. 2m schräg von der Spur abweicht, dann kurz aus der App ist und dann sofort im Idle steht incl einem Fix ohne Fehler in der App. Mit einem Start läuft er dann weiter teilweise 20m oder auch 2000m. In letzter Zeit leider nur noch 100m.
Ich habe verschiedene auch alte Firmwares durchprobiert jedoch tauch der Fehler überall auf. PCB 1,4 habe ich ausgebaut und alle Stecker und Lötstellen optisch überprüft. Module wie ublox etc. sitzen fest in ihren Halterungen.
Mr. Tree meinte da löst der Watchdog aus warum auch immer. Ich meine es müste ein Hardware Fehler sein nur wo soll ich anfangen zu suchen bzw. zu tauschen.
PS: Sd Karte ist neu und auch ohne bleibt der Fehler ...ich meine es wäre bei höherem Strombedarf.
Für jeten Tipp bin ich dankbar in der Hoffnung das ich das Ding nach dem Urlaub wieder zum laufen bekomme.

Hier mal Logs die ich gemacht hatte ich kann sie nicht deuten. :

MfG
Kai
 
I get a lot of i2c related watchdog resets, might be worth seeing if the problem persist if you remove IMU and temp sensor.
Also, logs say the watchdog was triggered manually a couple of times. Did you trigger those?
 
Okay, temp habe ich nicht und imu kann ich nach dem Urlaub mal deaktivieren. Die resets habe ich nicht gemacht. Die logs im Ordner log1 sind die wo der Fehler auftrat und ich ihn danach direkt ausgelesen habe. Im Ordner log2 habe ich einfach mitlaufen lassen. Danke schon mal für den Hinweis.
 
Persönlich bin ich ebenfalls massiv vom Watchdog-Reset betroffen gewesen. Mein Fazit nach 2 Jahren ist, dass ich die Ursache nicht herausfinden konnte. Ich habe aber einen Umgang damit gefunden, der den Resets den Schrecken nimmt. Folgendes habe ich gemacht:
  • Nach Hinweis von @EinEinfach habe ich von der aktuellen sunray-Version Abstand genommen und auf die V.298 gewechselt. Das war ein ziemlicher Kraftakt, da ich inzwischen sehr viele Modifikationen gegenüber der Originalsoftware vorgenommen habe. Aber es hat sich gelohnt. Der eine Ardumower hat gar keine Resets mehr, der andere deutlich weniger als früher.
  • Folgende Zeilen in der robot.cpp am Ende der void start() bewirken, dass der Ardumower nach einem Watchdog-Reset seine Arbeit fortsetzt.
activeOp->checkStop();
activeOp->run();
Aber VORSICHT, damit setzt der Ardumower auch dann seine Arbeit fort, wenn er mittels Notschalter im Mähvorgang abgeschaltet und danach dann wieder eingeschaltet wurde.​
  • Der Watchdog-Reset ist in sunray auf 16 Sekunden fest eingestellt. Das finde ich persönlich extrem gefährlich, da der Mäher 16 Sekunden lang ohne irgendeine Kontrolle weiter arbeitet und alles klein macht, was ihm in die Quere kommt. Diese Zeit habe ich auf 2 Sekunden verringert. In diesen 2 Sekunden passiert dann nicht mehr allzuviel. Mal sehen, ggf. werde ich die Zeitspanne auch noch weiter verringern. Wenn man das allerdings macht, dann muss in verschiedenen Prozessen -wie z.B. die Pfadberechnung- der Watchdog-Timer regelmäßig zurückgesetzt werden. Ansonsten schlägt der Reset z.B. bei der Pfadberechnung zu.
Durch diese Maßnahmen spielt der Watchdog-Reset bei mir nur noch eine sehr untergeordnete Rolle.
 
Die resets habe ich nicht gemacht.
Weird, two of your logs in folder 2 end with this:
hang test - watchdog shou

which comes from here:
and

I dont know if this is related, but maybe an AT+Y command is being sent somehow (?)


As a las resort, if you dont find the cause you can fix the firmware to continue mowing after a watchdog reset.
 
Zuletzt bearbeitet:
Danke für die Hinweise, werde mal alles ausprobieren wenn ich wieder zuhause bin in einer Woche. Incl. Belastungstest des Accus.
Ps: wo kann man die Zeit von 16 Sekunden verkürzen?
Ich finde es super das das Projekt noch lebt und so viel Unterstützung da ist.
 
Zuletzt bearbeitet:
in der WatchdogSAMD.cpp müssen die Zeilen 176 ff wie folgt aussehen.
//WDT->INTFLAG.bit.EW = 1; // Clear interrupt flag
WDT->INTENCLR.bit.EW = 1; // Disable early warning interrupt
//WDT->EWCTRL.bit.EWOFFSET = bits; // Early warning offset
//WDT->CONFIG.bit.PER = 0xB; // Set period for chip reset
WDT->CONFIG.bit.PER = bits; // Set period for chip reset
WDT->CTRLA.bit.WEN = 0; // Disable window mode
//WDT->INTENSET.bit.EW = 1; // Enable early warning interrupt
while (WDT->SYNCBUSY.reg)
; // Sync CTRL write
Danach kannst du den Watchdog-Timer in der robot.cpp mit
watchdogEnable(1000L);
einstellen.
Ich muss mich übrigens korrigieren. Ich habe den Watchdog-Timer bereits auf 1 Sekunde stehen.
 
Ich hatte nur 2 logs von kaido angesehen, dass mit dem Hang Test ist mir dadurch nicht aufgefallen, das ist wirklich mysteriös. Ansonsten sieht man meistens einen nicht vollendeten serial log, weshalb ich auf SD getippt hatte.
 
Würde den Bootloader nochmal neu aufspielen und danach nochmal komplett Sunray neu drauf spielen.
Wie man den Bootloader flashed ist hier erklärt.
Also das hat geholfen. Das System bleibt drauf, danke.
Persönlich bin ich ebenfalls massiv vom Watchdog-Reset betroffen gewesen. Mein Fazit nach 2 Jahren ist, dass ich die Ursache nicht herausfinden konnte. Ich habe aber einen Umgang damit gefunden, der den Resets den Schrecken nimmt. Folgendes habe ich gemacht:
  • Nach Hinweis von @EinEinfach habe ich von der aktuellen sunray-Version Abstand genommen und auf die V.298 gewechselt. Das war ein ziemlicher Kraftakt, da ich inzwischen sehr viele Modifikationen gegenüber der Originalsoftware vorgenommen habe. Aber es hat sich gelohnt. Der eine Ardumower hat gar keine Resets mehr, der andere deutlich weniger als früher.
  • Folgende Zeilen in der robot.cpp am Ende der void start() bewirken, dass der Ardumower nach einem Watchdog-Reset seine Arbeit fortsetzt.

Aber VORSICHT, damit setzt der Ardumower auch dann seine Arbeit fort, wenn er mittels Notschalter im Mähvorgang abgeschaltet und danach dann wieder eingeschaltet wurde.​
  • Der Watchdog-Reset ist in sunray auf 16 Sekunden fest eingestellt. Das finde ich persönlich extrem gefährlich, da der Mäher 16 Sekunden lang ohne irgendeine Kontrolle weiter arbeitet und alles klein macht, was ihm in die Quere kommt. Diese Zeit habe ich auf 2 Sekunden verringert. In diesen 2 Sekunden passiert dann nicht mehr allzuviel. Mal sehen, ggf. werde ich die Zeitspanne auch noch weiter verringern. Wenn man das allerdings macht, dann muss in verschiedenen Prozessen -wie z.B. die Pfadberechnung- der Watchdog-Timer regelmäßig zurückgesetzt werden. Ansonsten schlägt der Reset z.B. bei der Pfadberechnung zu.
Durch diese Maßnahmen spielt der Watchdog-Reset bei mir nur noch eine sehr untergeordnete Rolle.
Das war auch ein super Tipp der als Notlösung gut geht aber nicht das eigentliche Problem löst, danke.
Beim Reset würde ich zunächst das Uhrenmodul verdächtigen. Hast du noch eins drin und wie alt ist die Batterie? Batterie entfernen hilft da schon mal weiter.
Ist neu, die alte hatte auch noch volle Spannung, danke.

Jetzt zum eigenlichen Problem:

Nachdem ich die IMU und das M4 Board erneuert habe bleibt trotzdem der Fehler das er bei höherem Mow Strom das M4 Board zum Absturz bringt.
Das ganze konnte ich jetz auf dem Werktisch mit Accu und angeschlossenem Labornetzteil testen. Sobald der Strom des Mowmotors (Jdqy) etwas länger
über 1,4 A steigt resettet der M4 und bootet neu.
Die Spannungen bleiben alle stabil, zu sehen an den ganzen LEDs an denen sich nichts verändert. Den Bruslessadapter V1.1 habe ich auch gegen einen
noch vorhanden getauscht.
Mit dem alten A4931 passiert dieser Fehler nicht aber der hat ja die Probleme mit dem anlaufen. Bin am Ende und weiss nicht mehr weiter.
Hat jemand noch einen Tipp was da los sein könnte ?
LG
Kai
PS: habe auf dem Brushlessadapter keine zusätlichen Widerstände da es die letzte Version ist und auf dem Board auch keine zusätlichen 220nf
Kondensatoren. Das ganze scheint sehr instabiel zu sein weil denn ich nur mit dem Finger drann komme verändert sich die Drehzahl und der Motor stoppt.
 
Zuletzt bearbeitet:
Oben