Atmega2560 spinnt bei Programmausführung.

[damfino]

Ich doktore jetzt seit 2 Monaten mit Urlaubsunterbrechung daran herum das Programm lauffähig zu bekommen und komme einfach nicht weiter.
Mittlerweile vermute ich ein Hardwareproblem.

Verschiedene Fehler:
1) Programm beginnt normal, dann eigenartiges Verhalten (Motoren laufen an obwohl in diesem Abschnitt die Motoren nicht angesteuert werden), reagiert aber noch auf Tasteneingabe. Freier SRAM wird laufend am Display angezeigt, es sind hier noch wie erwartet ~3300 Bytes frei.
2) Programm beginnt normal, aber nach 4s schlägt der Watchdog zu, die Watchdog Anzeige wie blinkende LED blinkt nicht mehr mit 10Hz sondern nur mehr alle paar Sekunden
3) Ein altes Hex file das schon mal funktionierte hat auf einmal auch diesen Watchdog Fehler.
4) Nach ein paar Mal andere Files flashen und dann wieder obiges geht dieses auf einmal länger als 4s.
5) neues Hex File flashen wieder bei Fehler 1 oder 2

Hab extra eine Minimalst-Programmversion erstellt, alles rausgeworfen was es an Menüs, Fahrprogrammen, GPS und Bluetooth und sonstigen Extras gab, SRAM benötigt nur mehr 500 Byte anstatt mindestens 4200Byte, und es geht immer direkt in den Watchdog rein

Es ist ein Arduino Mega Board, dh Abblockkondensatoren sollten doch passen, Stromversorgung über Akku-Stepdown Regler, oder auch direkt über den Programmer.
Brownout ist auf höchsten Wert von 4.3V eingestellt.


Watchdog Anzeige, wie kann es passieren dass es nur alle paar Sekunden blinkt???

if ((mcusr_mirror & (1 << WDRF)))
{
Anzeige_Sonder(LCD_WATCHDOGK1);
Motoren_stop();Mower_faststop();
while(1)
{
if (mcusr_mirror & (1 << WDRF)) {LED_gr_ein;LED_rot_aus;}
_delay_ms(100);
LED_gr_aus;LED_rot_aus;
_delay_ms(100);
}


}
else wdt_enable(WDTO_4S);
wdt_reset();


Wie der Roboter das Programm hochfährt ist seit 3 Jahren unverändert gleich und hat schon auf verschiedenen Kontrollern funktioniert, also warum auf einmal in dieser Phase der Watchdog?

Kann der ältere Diamex Programmer den Atmega2560 nicht richtig programmieren?
Kann es sein dass der Stepdown Regler eine unsaubere Spannung liefert und damit das unberechenbare Verhalten auslöst? LCD, GPS und Bluetooth hängen auch direkt dran und laufen fehlerfrei.
Atmega defekt?
??
?
?

LG Werner, der den ganzen Haufen bald zum Elektroschrott wirft...

[askazo]

Ich würde als erstes mal die brownout detection ausschalten oder auf einen niedrigeren Wert stellen. Evtl. ist Deine Spannung wirklich zu unsauber, so dass sie gelegentlich auf unter 4,3V fällt uns somit einen Reset auslöst.

Gruß,
askazo

[shedepe]

ISP Programmer bieten auch immer die Möglichkeit an der Speicherinhalt mit einem Hexfile zu vergleichen (also zu verifizieren wie Atmelstudio das nennt). Das würde ich mal ausprobieren um zu überprüfen ob wirklich das im Speicher steht was drin sein soll. Bei häufigem Flashen kann man durchaus an die Grenzen der Haltbarkeit des Speichers kommen.

Weiterhin würde ich noch mal vorsichtshalber alle Fuses überprüfen. Manchmal macht man ja auch da Blödsinn.
Wie viel Strom zieht eigentlich die äußere Peripherie. Da könnte man je nach Arduino Board durchaus an die Grenzen des Spannungsreglers kommen.

[damfino]

Verifizieren der Daten im Flash ist immer ok. Das Board ist neu und wurde keine 100x geflasht, davon 50x die letzten paar Tage. Wollte damit die Designschwächen meiner Lochrasterplatinen aussschließen.
Und es war billiger als 2 neue 1284 für meine alte Platine.

Stromversorgung kommt vom Stepdown Regler, max 2A, 5V direkt aufs Arduino Shield/Board, die Spannungsregler am Board werden umgangen. Gemessen waren es 4.97 am Board. Vor und gleich nach dem Stepdown Regler sind zusätzliche Elkos verbaut, 20cm Kabellänge weiter am Board gibt es nichts außer der original Beschaltung. Werde dort am Shield noch zusätzlich 100nF und Elko einbauen.

Brownout hatte ich wegen EEPROM so hoch gesetzt, werde es mal rausnehmen.

Fuses sind ok, habe beim Quarz >8Mhz mit 64t gewählt oder auch den Full Swing, kein Unterschied.
Clockdiv8 ist aus.
EEsave ist an.
Bootloader ist aus.

[shedepe]

Ok, dann sind wir an dem Punkt angelangt an dem man ohne genauere Informationen nur raten kann.
Dazu gehören Schaltplan und Programmcode des minimal Programms (komplett)

Deine Fehlerbeschreibung (also 1-5) hören sich mehr nach (Wenn es nicht die Brownoutdetection ist)
1. Kaputter Flashspeicher -> sollte aber wegen Verifikation nicht sein -> du könntest aber die Verfikation noch mal zu einen späteren Zeitpunkt nach einigen Minuten Betrieb drüber laufen lassen
2. Falsche Interruptvektoren -> Der Code springt irgendwo hin

Verwendest du eine Sourcecodeverwaltung bzw. Versionierung wie z.B. git ?
Bist du damit schon mal auf einen funktionierenden Stand zurückgesprungen. Ich hatte auch schon mal den Fall bei dem ich dachte das alte Hexfile müsste eigentlich funktionieren.

[damfino]

Hallo shedepe,

war beim zusammenstellen der Codefiles zum reinstellen als ich im Code bei den Interrupts den Kommentar "geht nicht??" entdeckte, dachte sofort an deinen Hinweis
2. Falsche Interruptvektoren -> Der Code springt irgendwo hin und ging das noch mal mit dem Datenblatt durch. Interruptvektoren stimmen, falsche Interrupts fange ich mit Fehlermeldung ab.
Hatte verschwitzt dass ich kurz vorm Urlaub die Interrupt Pins ändern musste (deswegen ging es ursprünglich nicht), und gerade entdeckt dass damit ein Interrupt von Register EICRB ins EICRA gewandert ist!
Jetzt gehen die ersten Motortests richtig, und zumindest diese 3 Tests waren ohne Watchdog Meldung :)

Was mich wundert dass der Compiler nichts gemeldet hat, schließlich gibt es in EICRB kein ISC30 zu setzen, und ich habe den extra so eingestellt das zu jedem Mist eine Warnung kommt.

Und man sieht dass Kommentare im Code super sind wenn das Hirn vergesslich wird ;)
Dabei hatte ich diese Stelle auch schon oft kontrolliert, aber das falsche Register bis jetzt nicht bemerkt.

Dann werde ich morgen den Roboter mit altem Notfallakku in die Wildnis entlassen, mal sehen wie es dort funktioniert.

LG Werner

[askazo]

Was mich wundert dass der Compiler nichts gemeldet hat, schließlich gibt es in EICRB kein ISC30 zu setzen, und ich habe den extra so eingestellt das zu jedem Mist eine Warnung kommt.
EICRB und ISC30 sind nur Makros. Für den Compiler wird ein Bit in einem Register gesetzt. Der Compiler weiß nichts über die Funktionen der einzelnen Bits der Register. Du kannst grundsätzlich jedes Bit in jedem Register setzen, ohne dass der Compiler meckert - auch wenn das Bit dort gar keine Funktion hat.

Gruß, askazo