Menü
Aktuelles
Von:
Filter

Root cause for WDT

There was an issue with the Stackpointer, that is written in the dump state every 10 sec or so. Stackpointer was rising, so the Microcontroller run Out of memory. That was fixed. What you would be interested in IS what Happens before the reboot, Not after.
 
Yes its the Stackpointer, so in your Case its OK when its Not contantly rising. There is another issue. You should mention your Version of sunray and Hardware Details.
 
Great, thanks for confirming! Now, the binary I'm running was built without saving the elf, so I rebuilt the same (I believe) code a few days later, just to get the elf. But that elf doesn't give any usefull info on the address 2000190C, so I think I need to rebuild and reflash just to be sure.

I'm running a Grand Central M4 on a PCB v1.3 with Sunray 1.0.324.
 
Or actually, I am running a version built from a git clone from master and I see now when fetching latest commits that the latest commit only updates the firmware version number to 1.0.325, so that must be the real version I'm on...
 
My guess: You should try another Release Version, and not master of the github to make Sure its Not ON your Hardware Side. Just flash an older FW, elf doesnt Matter.
 
And by circomestance, If it is my fork. Yes, Theres a watchdog issue and it got reverted because of that ... Now the master is stable 😅 but Not up to Date with sunray
 
No, I will try your fork later, but right now I'm on the official master. I will do one more try with this build, then I will do as you say and go back to a Release version! Thank you! :)
 
Now wait a minute! When I load the elf in gdb and do a "list *0x2000190C" I get nothing! And that address is in the SP in the log file created just now, with that exact elf! What am I doing wrong now?
 
Ok, I reverted the main branch to 1.0.324 and added the ENABLE_STACK_SAVING flag. I get a stack dump in the log-file after reset:

reading flash stack dump from last watchdog reset... sp=2003FEC8
0x0,0x0,0x0,0x41014000,0x7FF,0x1BC43,0x1CDAA,0x41000200,0xFFFFFFFF,0x3D59DA6A,0x7F728BB4,0x7F000000,0x80000000,0x9671,0x9670,0xA1000000,0x0,0x1E8C1,0x20000BA8,0x4,0x100,0x0,0x20000BA8,0x3C,0x1,0x1,0x54442D18,0x20003FD0,0x1,0x1BC43,0x2003FF76,0x1,
this looks like a real stack dump
NOTE: we will need your .ino.elf binary file for further inspections
erasing flash stack dump...

Now, I try to find those adresses in the .ino.elf file using gdb, but I get nothing. Am I completely missing something in the instructions or is the stack pointers completer rubbish? I attached the .ino.elf here if anyone is curious/knows how to read it correctly.
 
I am not the right Person to Analyse Stack Infos, beside... Your Stackpointer Adresse didnt Rise, so its ok, when IT was fixed you See in github. Hardware issues Like loose Connections can also lead to resets.
 
Hydropower schrieb:
I'm trying to find the root cause to my frequent watchdogs. I have installed an SD card and get the log files, but where do I find the stack dump mentioned here? https://wiki.ardumower.de/index.php?title=Ardumower_Sunray#SD_card_logging

In the top of the log-file I see that the reset cause is a watchdog, but then it goes on with software versions and startup tests. Do I have to activate anything in config?
Zum Vergrößern anklicken....
Very often watchdog reset is generate by sdcard issue.
So initial check is a test for long mowing duration without sdcard to be sure .
 
Someone recently mentioned getting WD resets from a non properly set up ublox board, Ive also had WD issues related to I2C
 
Thank you all for your valuable input!

I have been focusing on the software side, with wrong versions or configurations, but from the sound of it the most probable cause would be some sort of communication issue with periferals not responding in time!

I think we can rule out the SD card, it was not even part of my compilation in the beginning but I was still seeing these wdt's (actually these wdt's was the reason to activate it).

I2C is one interesting thing to look at. But most interesting maybe could be the esp32! I experience connection dropouts from the app, having to reconnect. If that is caused by the agcm4-to-esp link being shaky or esp-firmware being badly configured, then maybe that could be the reason for the wdt's as well?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben