Watchdog habe ich nicht aktiviert. Ist original Bootloader für einen UNO, nichts manipuliert. Die Motortreiber habe ich entfernt. Läuft alles auf Akku. Habe im Programm gerade noch einen Zähler eingebaut. Nun sehe ich am Zähler, dass der AVR immer nach dem dritten Schleifendurchlauf weg ist. Ein Schleifendurchlauf geht immer so in etwa, über I2C: ein Byte aus einem Array von dem AVR lesen, um einen Status zu erfahren, dann noch ein Byte daraus lesen, dann ein Byte ins Array auf dem AVR schreiben (das, was zu Anfang gelesen wurde). Diese Prozedur funktioniert ein Mal. Dann noch Mal und dann noch ein Mal, dann startet der AVR neu. Wenn ich jetzt die Prozedur neu anschubse, funktioniert das ein Mal und noch ein Mal, dann ist der AVR wieder weg.
Das wird noch etwas dauern, bis ich das Problem gefunden habe.
MfG
- - - Aktualisiert - - -
Den verfügbaren freien Variablen-Speicher habe ich auf 895 Bytes erhöht (keine Meldung - Warnung - von der Arduin-IDE). Vorher war der etwa bei 400 Bytes, da hat der AVR sich genau so verhalten.
IR-Diode entfernt und Reset-Pin nochmals auf HIGH-Pegel gelegt - keine Änderung.
- - - Aktualisiert - - -
Habe jetzt einen neuen AVR genommen, Problem ist dasselbe. Also weiter suchen...
- - - Aktualisiert - - -
Fuses habe ich noch mal kontrolliert, da ist nichts eingeschaltet, was einen Reset hervorrufen könnte. BOD war auf 2.7V eingestellt (üblich). Ein 2936 versorgt nur diesen einen AVR. Max. Strom sind hier 50mA über den Regler. Kann mir aber nicht vorstellen, dass die 50mA überschritten werden. Ich hatte mal eine LED zum Testen an genau diesen AVR angeschlossen, wo schon mal 15mA extra für die LED verbraten wurden, das lief (die LED blinkte) über Stunden in einer Testsschleife. Auch jetzt läuft der AVR problemlos in einer Programmschleife, solange keine Kommunikation hinzukommt (hier i2c). Als ich das Programm aufgebaut habe, habe ich das nodeMCU 1.0 und den AVR im fliegenden Aufbau mit Steckern verbunden (AVR auf einem UNO-Board) damit ich serielle Ausgaben zum Testen benutzen konnte, ob die Kommunikation einwandfrei ist. Da ist das dann auch sehr lange Zeit gelaufen, ohne dass es zu Fehlern kam. Wenn ich jetzt den freien RAM-Speicher erhöhe, auf über 1400 Byte, schafft der AVR ein paar Zyklen mehr (wenn es vorher 2 oder 3 waren, sind es jetzt bis zu 9). Macht den Eindruck, als ob da Daten ein Stapel überläuft oder was anderes, durch sich ansammelnde Daten. Aber auch das kann eigentlich nicht möglich sein. Ich mache da nichts extravagantes im Programm, wie extra Speicher reservieren. Alles wird durch den Compiler erledigt. Arrays lege ich nicht zur Laufzeit an, sondern deklariere die im Quellcode (das Erstellen macht dann der Compiler) und die müssen auch nicht entfernt werden, die bleiben immer erhalten. Manchmal habe ich lokale Variablen in Funktionen, die natürlich dann Speicher benötigen und anschließend wird der Platz wieder freigegeben. Aber auch das erledigt der Compiler. Ich habe keine Ahnung , was da los ist. Leider finde ich keine List-Files, wo ich sehen könnte, was da compiliert wird. So kann ich das Ergebnis des Compilers nicht kontrollieren. Was ich jetzt wieder tun kann, dass ich das nodeMCU und den AVR wieder mal fliegend verknüddele und mit Serial.print dann die Vorgänge überprüfe, um genauer herauszufinden, an welcher Stelle der AVR dann rebootet.
Lesezeichen