Menü
Aktuelles
Von:
Filter

RESET cause: watchdog

Hmm, in dem Fall braucht noch einen Trigger im sunray für erneute konfig. Man könnte beim reset ein boolflag ublox_configured von true auf false setzten... Um dann eine Bedingung einmalig auszuführen die die config macht und den flag wieder true setzt.
 
ich möchte hier mal ganz vorsichtig Erfolg vermelden. Nach unzähligen Analysen, Modifikationen im Quellcode und bei den Debug-Ausgaben, bin ich zu der Überzeugung gekommen, dass das Problem, welches den Watchdog-Reset erzeugt, der Watchdog selbst ist.

Der Watchdog ist im Prinzip ein Timer, den man auf 10 Sekunden einstellt. Laufen diese 10 Sekunden ab, dann resetet der Watchdog den Adafruit. Damit das nicht passiert, wird in jedem Loop des Adafruit der Watchdog wieder auf 10 Sekunden gestellt. Bei mir dauert ein durchschnittlicher Loop 3 Millisekunden und im Bestfall unter einer Millisekunde. Meine Vermutung ist, dass es bei diesem häufigen Zurücksetzen des Watchdog-Timers zu Komplikationen kommt.
Als Lösung setze ich den Watchdog-Timer nur noch einmal pro Sekunde zurück. Seit dieser Änderung habe ich inzwischen 2 Batterieladungen bis zu Grund leergefahren und keinerlei Probleme mit dem Watchdog mehr. Ich hoffe, dass das auch so bleibt.

Ich halt euch auf dem Laufenden.
 
nö, der Mittelwert liegt bei mir relativ konstant bei 3ms. Der Maximalwert liegt bei mir meist bei 10….15ms. Sonderereignisse wie Pfadfinder natürlich ausgenommen. Der braucht durchaus mal 3 Sekunden.
 
Aber die motor.cpp alleine mit den pid Reglern braucht regelmäßig über 10ms ....
Die controlcycle time der Statistik aus der App? Was steht da bei dir? 0.003?? Ich gehe davon aus, das adafruit läuft im besten Fall mit 50 hz durch den Code
 
ich nutze die App nicht und kann dazu auch nichts sagen. Ich habe lediglich die Zeit pro Loop gestoppt und statistisch ausgewertet. Ich kann aber gerne nochmal drauf schauen, ob ich da einen Fehler drin habe, glaube es aber nicht. Wo kommen deine 50Hz her? Der Adafruit taktet deutlich höher.
 
Also, deswegen ja, ich habe es nicht getestet. Und würde mich auch überzeugen lassen das der 120Mhz Chip den Code tatsächlich so schnell abarbeiten kann.
Ich habe aber indizien, das dem nicht so ist:
- Die expectet PIDcycletimes werden regelmäßig überschritten, wenn unter 12ms eingestellt
- Motorcontrol wird glaube nur max. alle 50ms aufgerufen, wenn motorcontrol dann aufgerufen wird, braucht es geschätzt 5 bis 15 ms um durchzulaufen, sonst würde es nicht zu besagtem consolen output Warning.. PID Times... soundso überschritten..." kommen
- wenn Sunray in 1 - 3 ms durchlaufen würde, und Daten vom flinken Ublox abholt, dann hätten wir eine GAAANZ andere Bahnqualität. Er würde auf die kleinste Bahnabweichung reagieren können, ohne das überhaupt etwas sichtbar wäre... Ähnlich einem Industrieroboter, deren Steuerungen mit 1- 4ms den GESAMTEN code durchlaufen

Allerdings, kann es sein, dass wenn alle oder viele Funktionen warten bzw. nicht getriggert werden, Sunray also quasi ohne "Last" mit wenig Code durchläuft, dann würde das wohl gehen?!
 
Zuletzt bearbeitet:
Silberstreifen schrieb:
ich möchte hier mal ganz vorsichtig Erfolg vermelden. Nach unzähligen Analysen, Modifikationen im Quellcode und bei den Debug-Ausgaben, bin ich zu der Überzeugung gekommen, dass das Problem, welches den Watchdog-Reset erzeugt, der Watchdog selbst ist.

Der Watchdog ist im Prinzip ein Timer, den man auf 10 Sekunden einstellt. Laufen diese 10 Sekunden ab, dann resetet der Watchdog den Adafruit. Damit das nicht passiert, wird in jedem Loop des Adafruit der Watchdog wieder auf 10 Sekunden gestellt. Bei mir dauert ein durchschnittlicher Loop 3 Millisekunden und im Bestfall unter einer Millisekunde. Meine Vermutung ist, dass es bei diesem häufigen Zurücksetzen des Watchdog-Timers zu Komplikationen kommt.
Als Lösung setze ich den Watchdog-Timer nur noch einmal pro Sekunde zurück. Seit dieser Änderung habe ich inzwischen 2 Batterieladungen bis zu Grund leergefahren und keinerlei Probleme mit dem Watchdog mehr. Ich hoffe, dass das auch so bleibt.

Ich halt euch auf dem Laufenden.
Zum Vergrößern anklicken....
Hello,
could you share your code modification. I will try on my side.
At this time, some days I have no reset, some days I could have 3/4 resets. It is very variable
 
Manu27 schrieb:
Hello,
could you share your code modification. I will try on my side.
At this time, some days I have no reset, some days I could have 3/4 resets. It is very variable
Zum Vergrößern anklicken....
Watchod reset can have multiple cause ,so you need to add some part in the code to help detect the trouble.
Into robot.cpp
Code: 
void run(){
  //bber
  unsigned long StartReadAt = 0;
  unsigned long EndReadAt = 0;
  unsigned long ReadDuration = 0;

Check the IMU I2C delay response using this part of code:
Code: 
// IMU
  if (millis() > nextImuTime)
  {
    nextImuTime = millis() + 50;
    // imu.resetFifo();
    if (imuIsCalibrating)
    {
      activeOp->onImuCalibration();
    }
    else
    {
      StartReadAt = millis();
      readIMU();
      EndReadAt = millis();
      ReadDuration = EndReadAt - StartReadAt;
      if (ReadDuration > 30)
      {
        CONSOLE.println("Error reading IMU too long duration need < 30 : ");
        CONSOLE.println(ReadDuration);
      }
    }
  }

Check the main control loop by this way :
Code: 
gps.run();
    
  calcStats();

  if (millis() >= nextControlTime)
  {
    if (millis()-nextControlTime > 20)
    {
      CONSOLE.print("Exceed Control time duration better if < 20 ms : ");
      CONSOLE.println(millis()-nextControlTime);
    }

    nextControlTime = millis() + 20;
    controlLoops++;

And record all the console message on SD Card or raspberry to understand the issue.

But it's strange that AGCM4 can freeze for more than 10 Secondes!
Teensy have 2 delay for watchdog , it first start a callback after 2 Second of non watchdogreset call : it can help to send some state of mower
And only reboot after other delay (10 seconds in my case).
Maybe the Adafruit watchdog can do the same ??
 
With all this in mind, don't forget that there is a serious stack problem with AGCM4. see github error message "code wastes stack memory on AGCM4".
This causes an unpredictable, unstable behaviour and SW hangs, at least for me. If I replace the AGCM4 with an Ardiuno DUE, I notice a stable stack pointer and the Ardumower runs (almost) without those problems!
 
Silberstreifen schrieb:
hey Manu27,
you can find my changes on Github in the watchdog-tree. It is based on version 303.
Zum Vergrößern anklicken....
did you test my code? With that smal changes my mower runs like a charme, without any watchdog-resets.
Tinker schrieb:
With all this in mind, don't forget that there is a serious stack problem with AGCM4. see github error message "code wastes stack memory on AGCM4".
This causes an unpredictable, unstable behaviour and SW hangs, at least for me.
Zum Vergrößern anklicken....
I think, you are right with that, but for me the workaround does the job for the moment hopefully till the bug is fixed.
 
Danke @Silberstreifen für Deinen Code, scheint bei mir auch zu funktionieren.
Hatte schon einen Hardwarefehler in Verdacht, da mein Mäher plötzlich ständig stehen geblieben ist, teilweise hat er nicht mal mehr auf den Button reagiert.
Laut Logfile war es dann doch wohl "nur" der Watchdog. Bei mir war es übrigens auch im Zusammenhang mit erhöhter Stromaufnahme des Mähmotors, da das Gras schon recht hoch war. Ich hoffe Dein Code oder eine Lösung findet bald mal ins offizielle Repository...seit Oktober kommt ja kein Release mehr, sehr schade, ich hoffte im neuen Jahr würde etwas mehr geschehen
 
Tinker schrieb:
With all this in mind, don't forget that there is a serious stack problem with AGCM4. see github error message "code wastes stack memory on AGCM4".
This causes an unpredictable, unstable behaviour and SW hangs, at least for me. If I replace the AGCM4 with an Ardiuno DUE, I notice a stable stack pointer and the Ardumower runs (almost) without those problems!
Zum Vergrößern anklicken....
Comment out this line into comm.cpp
Code: 
 CONSOLE.print (statControlCycleTime);      
    //CONSOLE.print (" op=");  
    //CONSOLE.print (activeOp->getOpChain());  
    //CONSOLE.print (stateOp);
    #ifdef __linux__


@Silberstreifen :
Yes with AGCM4 its the same. In sunray, it is used to store some debug-Information. The Watchdog-Reset is hardcoded to 16sec. The debug-information will be stored after 10sec.
Zum Vergrößern anklicken....
Not the same at all: Only a resetWatchdog occur after 10 sec and it did not help at all if GCM4 freeze the reset is never call and watchdog is trig after 16sec without any info.,
 
Seems to work on my AGCM4 as well!
Incredible, you solved the problem! There's a trophy for that!!! Many thanks for your efforts! How did you come up with this and do you have any explanation for the behaviour of the stack?

Add: Today, after that change I was able to mow my whole lawn with the AGCM4 for the first time!
 
Zuletzt bearbeitet:
Tinker schrieb:
Seems to work on my AGCM4 as well!
Incredible, you solved the problem! There's a trophy for that!!! Many thanks for your efforts! How did you come up with this and do you have any explanation for the behaviour of the stack?
Zum Vergrößern anklicken....
Unfortunately this practice do not solve the bug describe by @AlexanderG in the activeOp->getOpChain() .
But i don't use this control and i need to say that i don't know the utility of this info maybe someone can explain ?
Here my actual part of the output summary on console return only each 2 minutes on the pi side and certainly totally remove when all my dev are finish.

Code: 
// output summary on console
void outputConsole(){
   //return;
  if (millis() > nextInfoTime){       
    bool started = (nextInfoTime == 0);
    nextInfoTime = millis() + 120000;                   
    unsigned long totalsecs = millis()/1000;
    unsigned long totalmins = totalsecs/60;
    unsigned long hour = totalmins/60;
    unsigned long min = totalmins % 60;
    unsigned long sec = totalsecs % 60;
    CONSOLE.print (hour);       
    CONSOLE.print (":");   
    CONSOLE.print (min);       
    CONSOLE.print (":");   
    CONSOLE.print (sec);     
    CONSOLE.print (" ctlDur=");       
    //if (!imuIsCalibrating){
    if (!started){
      if (controlLoops > 0){
        statControlCycleTime = 1.0 / (((float)controlLoops)/120.0);
      } else statControlCycleTime = 120;
      statMaxControlCycleTime = max(statMaxControlCycleTime, statControlCycleTime);   
    }
    controlLoops=0;   
    CONSOLE.print (statControlCycleTime);       
    //CONSOLE.print (" op=");   
    //CONSOLE.print (activeOp->getOpChain());   
    //CONSOLE.print (stateOp);
    #ifdef __linux__
      CONSOLE.print (" mem=");
      struct rusage r_usage;
      getrusage(RUSAGE_SELF,&r_usage);
      CONSOLE.print(r_usage.ru_maxrss);
    #else
      CONSOLE.print (" freem=");
      CONSOLE.print (freeMemory()); 
      uint32_t *spReg = (uint32_t*)__get_MSP();   // stack pointer
      CONSOLE.print (" sp=");
      CONSOLE.print (*spReg, HEX);
    #endif
    // CONSOLE.print(" bat=");
    // CONSOLE.print(battery.batteryVoltage);
    // CONSOLE.print(",");
    // CONSOLE.print(battery.batteryVoltageSlope, 3);   
    // CONSOLE.print("(");   
    // CONSOLE.print(motor.motorsSenseLP);   
    // CONSOLE.print(") chg=");
    // CONSOLE.print(battery.chargingVoltage);   
    // CONSOLE.print("(");
    // CONSOLE.print(battery.chargingCurrent);   
    // CONSOLE.print(") diff=");
    // CONSOLE.print(battery.chargingVoltBatteryVoltDiff, 3);
    // CONSOLE.print(" tg=");
    // CONSOLE.print(maps.targetPoint.x());
    // CONSOLE.print(",");
    // CONSOLE.print(maps.targetPoint.y());
    // CONSOLE.print(" x=");
    // CONSOLE.print(stateX);
    // CONSOLE.print(" y=");
    // CONSOLE.print(stateY);
    // CONSOLE.print(" delta=");
    // CONSOLE.print(stateDelta);   
    // CONSOLE.print(" tow=");
    // CONSOLE.print(gps.iTOW);
    // CONSOLE.print(" lon=");
    // CONSOLE.print(gps.lon,8);
    // CONSOLE.print(" lat=");
    // CONSOLE.print(gps.lat,8);   
    // CONSOLE.print(" h=");
    // CONSOLE.print(gps.height,1);   
    // CONSOLE.print(" n=");
    // CONSOLE.print(gps.relPosN);
    // CONSOLE.print(" e=");
    // CONSOLE.print(gps.relPosE);
    // CONSOLE.print(" d=");
    // CONSOLE.print(gps.relPosD);
    // CONSOLE.print(" sol=");   
    // CONSOLE.print(gps.solution);
    // CONSOLE.print(" age=");   
    // CONSOLE.print((millis()-gps.dgpsAge)/1000.0);
    CONSOLE.println();
    //logCPUHealth();   
  }
 
ich habe mir aufgrund des Defekts meines guten alten Arduino DUE einen AGCM4 gegönnt. der zickt aber herum wie hölle... ich hatte sunray 1.0.305 drauf. und es kam jedes mal ein reset durch den watchdog. aber nicht einfach so... erst wenn der mäher ein paar meter gefahren ist und der mähmotor an war. dabei spielte es keine rolle, ob ich float, fix oder invalid hatte, auch bei manueller steuerung passierte das. ich habe sunray 1.0.230 drauf gespielt, das selbe... ich habe mit dem oszilloskop alle spannungen (Akku, 9V, 5V, 3,3V) beobachtet - keine Auffälligkeiten. Ich habe einen 7s4p akku, der sollte stabil genug sein. ich habe die codeänderungen hier probiert - das problem blieb. Ich habe die Batterie aus der RTC getauscht - keine Besserung. nun habe ich, entgegen meiner interpretation, die 2,2k Pull up Widerstände dran gelötet (Normal sollte das doch beim PCB 1.4 mit den Lötbrücken gemacht werden, oder?)
Jetzt scheint es zu funktionieren... allerdings vertraue ich diesem M4 nun nicht mehr von der Wand zur Tapete. Ein neuer DUE wird geliefert. Aber ich dachte, ich tu mir mit dem M4 einen gefallen. muss ich mit dem Ding noch irgendwas beachten, wenn ich den in betrieb nehme????? (neuer bootloader ist drauf, lötbrücken gesetzt, JP13 ist offen, 2,2k Pullup-Widerstände sind dran)

edit: nach ca 30 min wieder reset durch watchdog
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben