Timingfehler sichten

[D a v i d K. (oekel)]

Hi,

ich habe leider immer noch ein sporadisches Problem in meinem Code auf 
dem 93% gefülltem Atmega16 bei 8Mhz, dass sich erst nach minutenlangem 
Lauf zeigt.

ich versuche hier einige Vermutungen mit Codeschnipsel zu hinterfragen, 
in der Hoffnung dass euch etwas auffällt, dass mir endlich weiter hilft.

Basisproblem: das Programm bleibt hängen! (Und hat am Ausgang einen 
Zustand der niemals dort verweilen darf.)
Also "emergencyStop();" [setzt die richtigen Pinne auf 0] wird nicht 
mehr ausgeführt, wenn "isSecure()==false" [auch nur ein EingangsPin]

Teilprobleme:
1. Ich verwende die "countdown.h" von hier 
http://www.gjlay.de/software/c-code/countdown.html (Dachte eigentlich 
die Sourcen hier aus dem Forum zu haben, kann den Beitrag jedoch leider 
nicht finden)

Ist es möglich, dass ich damit bereits ein deadlock produziere,
indem man diese counter zu viel verwendet
bzw. dessen Pausen zu klein definiert?


Folgnder ISR, ist von mir nicht abgeändert worden:

ISR(TIMER2_COMP_vect)
        {
                static uint16_t irqs_10ms;

                wdt_reset();

                ////////////////////////////////////////////////////////////
                // 10 ms-Takt für Jobs: countdown-Zähler, Tasten-Entprellung, DCF, ...
                irqs_10ms = 1 + irqs_10ms;

                // Sind 10 ms voll?
                // IRQS wird im Makefile definiert, es gibt die Anzahl der
                // IRQs pro Sekunde an.
                // Um 10ms zu erhalten, teilen wir also durch 100
                if (irqs_10ms >= IRQS / 100)
                irqs_10ms = 0;

                // Führe nicht alle Jobs gleichzeitig aus, damit eine ISR nicht
                // zu lange dauert. Stattdessen staffeln wir die Aufrufe: es gibt
                // nur einen je 10ms, aber immer einen anderen (oder garkeinen).

                if (0 == irqs_10ms)   job_countdown();
                // if (1 == irqs_10ms)   mach_was_alle_10ms();
                // if (2 == irqs_10ms)   mach_nochwas_alle_10ms();
        }

2. Ich verwende den WATCHDOG:
Tue ich dies wirklich richtig? "ISR(TIMER2_COMP_vect)" macht ja auch 
bereits einen reset:

#include <avr/wdt.h>
#include ...

int main() {
        wdt_reset();//needet before reset on this MCU?
        wdt_disable();//sometimes need reset first...
        loadEEValues();
        inits();
        emergencyStop();//to be sure!
        initBuffers();

        view_boot();//hier steht etwas falsches im Display

        while (!sensorWormUp()){;}

        bool anyKeyInput = false;
        wdt_enable(WDTO_250MS);
        while (1) {
                temperatureCheck();
                if (isSecure()) {
                        anyKeyInput = scanButtons();
                        processing();//0,2Sek mit countdown.h
                        interpretButtons();//0,2Sek  mit countdown.h
                } else {
                        emergencyStop();
                }
                view(anyKeyInput);//0,2Sek - 1,5Sek  mit countdown.h
                wdt_reset();
        }
}

3. Lesen und schreiben in den eeMem.
Hier der nahezu volle Code, da ja evtl. der kleinste Fehler reichen 
kann:

#define DEFAULT_WT 500
#define DEFAULT_MT 900
#define DEFAULT_AA 0
#define DEFAULT_DIM 6
#define DEFAULT_HOLD 2
#define DEFAULT_TTC 0
uint16_t EEMEM eeTemperatureWork = DEFAULT_WT;
uint16_t EEMEM eeTemperatureMelting = DEFAULT_MT;
uint8_t EEMEM eeAlarmActive = DEFAULT_AA;
uint8_t EEMEM eeDisplayDimming = DEFAULT_DIM;
uint8_t EEMEM eeHoldingMelt = DEFAULT_HOLD;
uint8_t EEMEM eeTankCorrection = DEFAULT_TTC;


/* saved in EEPROM */
uint16_t volatile temperatureWork;
uint16_t volatile temperatureMelting;
bool volatile alarmActive;
uint8_t volatile displayDimming;
uint8_t volatile holdingMeltingPeak;
uint8_t volatile tankCorrection;
/* END of saved in EEPROM */

#define temperatureWork_Min 400UL
#define temperatureWork_Max 600UL

#define temperatureMelting_Min 800UL
#define temperatureMelting_Max 990UL

#define temperature_Step 10

#define displayDimming_MAX 15
#define holdingMeltingPeak_MAX 10

#define tanKCorrection_MIN 0
#define tanKCorrection_MAX 10

void get_WT() {
        uint16_t e = eeprom_read_word(&eeTemperatureWork);
        //Not sure why eeprom could be destroyed or *.eep is not flashed
        if (e >= temperatureWork_Min && e <= temperatureWork_Max) {
                temperatureWork = e;
        } else {
                temperatureWork = DEFAULT_WT;
                save_WT();
        }
}

void get_MT() {
        uint16_t e = eeprom_read_word(&eeTemperatureMelting);
        //Not sure why eeprom could be destroyed or *.eep is not flashed
        if (e >= temperatureMelting_Min && e <= temperatureMelting_Max) {
                temperatureMelting = e;
        } else {
                temperatureMelting = DEFAULT_MT;
                save_MT();
        }
}

void get_AA() {
        alarmActive = eeprom_read_byte(&eeAlarmActive) > 0;
}

void get_DIM() {
        uint8_t e = eeprom_read_byte(&eeDisplayDimming);
        //Not sure why eeprom could be destroyed or *.eep is not flashed
        if (e <= displayDimming_MAX) {
                displayDimming = e;
        } else {
                displayDimming = DEFAULT_DIM;
                save_DIM();
        }
}

void get_Hold() {
        uint8_t e = eeprom_read_byte(&eeHoldingMelt);
        //Not sure why eeprom could be destroyed or *.eep is not flashed
        if (e <= holdingMeltingPeak_MAX) {
                holdingMeltingPeak = e;
        } else {
                holdingMeltingPeak = DEFAULT_HOLD;
                save_Hold();
        }
}

void get_TTC() {
        uint8_t e = eeprom_read_byte(&eeTankCorrection);
        //Not sure why eeprom could be destroyed or *.eep is not flashed
        if (e >= tanKCorrection_MIN && e <= tanKCorrection_MAX) {
                tankCorrection = e;
        } else {
                tankCorrection = DEFAULT_TTC;
                save_TTC();
        }
}

void loadEEValues() {
    get_WT();
    get_MT();
    get_AA();
    get_DIM();
    get_Hold();
    get_TTC();
}

void save_WT() {
#ifndef GCC
        eeprom_update_word(&eeTemperatureWork, temperatureWork);
#endif
}

void save_MT() {
#ifndef GCC
        eeprom_update_word(&eeTemperatureMelting, temperatureMelting);
#endif
}

void save_DIM() {
#ifndef GCC
        eeprom_update_byte(&eeDisplayDimming, displayDimming);
#endif
}

void save_Hold() {
#ifndef GCC
        eeprom_update_byte(&eeHoldingMelt, holdingMeltingPeak);
#endif
}

void save_TTC() {
#ifndef GCC
        eeprom_update_byte(&eeTankCorrection, tankCorrection);
#endif
}

void autosave() {
        if (count.ms10_16.volatilePrg == 0) {
                /*
                 * all use  eeprom_update_
                 * So we dont care about non changing values
                 */
                save_WT();
                save_MT();
                save_TTC();
                save_Hold();
                save_DIM();
                dot7seg_ON = false;
        }
}

Und zu guter letzt, was ich eigentlich beobachte und mich dazu treibt, 
dass ich denke irgendwas von obigen Teilproblemen ist schuld an meinem 
Disaster:

"process()" läuft einige Tage ohne Auffälligkeiten durch. Dann Hängt das 
Programm Plötzlich und ich nur noch durch Trennen vom Strom zu 
"re(se)tten".
(Dahher habe ich den watchdog doch mit eingebaut.)

Nach einem Reset ist jedoch ein wert aus/im Eprom falsch.
Dies erkenne ich bereits während des "bootens" bei der Displayanzeige: 
"view_boot();" (Dort werden normalerweilse zwei Werte angezeigt. Temp 
A=50 und Temp B=90)

Nun zeigt er jedoch Fehlerhaft 2x "50" an :(
Ohne Watchdog blieb er in diesem Zustand ewig und nur ein neues flashen 
brachte den Wert Ablauf zurück.
Mit Watchdog und meinen neuen gettern, verweilt er dort 250ms, resettet 
sich und hat dann die korrekten Werte aus meiner Notfallroutine.

Was mich am Meisten irritiert ist, dass er HIER dann vor der 
Hauptschleife bereits aussteigt und sich resettet jedoch im Langzeittest 
irgendwo in der Hauptschleife stecken MUSS (sonst würde man es ja sofort 
sehen)

Hat irgendwer einen Hinweis, was dort oben in den Schnipseln unsachgemäß 
ist oder ob ich noch weitere Details posten soll, damit wir dem Rätsel 
auf die Spur kommen?

Vielen Dank für eure Unterstützung. Ich hoffe diesmal präzise genug zu 
sein.

Grüße David

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Normalerweise ist es keine gute Idee, den WD in einer Timer ISR 
zurückzusetzen, denn die ISR kann leicht noch ausgeführt werden, auch 
wenn das Hauptprogramm schon im Nirvana ist.
Der sinnvollste Platz für den WD Reset ist also die Hauptschleife.

[Oliver S. (oliverso)]

Sich unbeabsichtigt ändernde Werte im Eeprom könne durch eine nicht 
gesetzte Brown-out Fuse kommen. Da diese Unterspannung der Versorgung 
abfängt, steckt damit ein Hardwareproblem dahinter.

Oliver

[D a v i d K. (oekel)]

Oliver S. schrieb:
> Brown-out Fuse / Unterspannung
> ... Hardwareproblem dahinter.
>
Ich verwende ein fertiges WideRande Open-Frame Netzteil mit 1A.

Gehe ich etwas falsch in der Annahme,  dass dieses mehr als genug für:
Atmega16
3x OK
1x Summer
1x RTC
1x HT16K33
4x 7-Segmentabzeige
2x LED
..Hundefutter

Sind?

Genaue Bauteilbezeichnubg kann ich nachliefern,  wenn Zweifel sich 
erhärten.

[D a v i d K. (oekel)]

Oliver S. schrieb:
> Sich unbeabsichtigt ändernde Werte im Eeprom könne durch eine nicht
> gesetzte Brown-out Fuse kommen.

Ich habe mir gerade:
https://www.mikrocontroller.net/articles/Brownout
durchgelesen und tatsächlich festgestellt, dass ich diesen 
Sicherheitsmechanismus nicht verwende. (Siehe Screenshot 1)

Ich verwende zudem folgendes Netzteil:
https://www.ebay.de/itm/1A-1000mA-Power-Supply-AC-DC-5V-Buck-Converter-Step-Down-Modul-Small-Size/172258848263

Kann es sein, dass die Schaltstufen (Siehe Anhang GELB 230V) beim 
Anlaufen (Motor, Lüfter, Heizung) so viel Strom ziehen, dass der Trafo 
kurzzeitig versagt und keine 5V liefern kann?

Wirklich jeglicher Hinweis zum Testen bzw. retten der Schaltung hilft 
mir gerade weiter!

[глупний форентроль (Gast)]

Beginn damit den Watchdog nicht zu benutzen. Damit kann man Fehler 
kaschieren, die man besser finden sollte.