| Re: Zeitsprünge Kategorie: IDE (von Joerg - 2.04.2012 8:41) | ||
| Als Antwort auf Re: Zeitsprünge von PeterS - 31.03.2012 9:21 | ||
| ||
|
> > > > > > > > > > > Hallo Peter, > > > > > > > > > > > > > > > > > > > > > > mir sind, seitdem ich die neue Beta (2.20.0.16) benutze, Zeitsprünge mit > > > der internen Uhr aufgefallen. > > > > > > > > > > > > > > > > > > > > > > Ich habe ein Programm, welches Messdaten erfasst und diese zusammen mit der > > > > > > > > > > > Uhrzeit auf der Seriellen Schnittstelle ausgibt. Hin und wieder kommt es vor, > > > > > > > > > > > das die Uhrzeit von z.B. 18:38:49 auf 00:00:00 wechselt, ohne das ich die Uhr mit > > > > > > > > > > > Clock_SetTime() gestellt habe. > > > > > > > > > > > > > > > > > > > > > > Das interessant dabei ist, das auch das Datum dabei auf den nächsten Tag springt. > > > > > > > > > > > > > > > > > > > > > > Gibt es hierfür ein Erklärung (z.B interner Ã?berlauf)? > > > > > > > > > > > > > > > > > > > > > > Hier sind zwei protokollierte Zeitsprünge: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) > > > > > > > > > > > 18:38:48 18:03:12 392 8 6.250000 0 0 0 0 > > > > > > > > > > > 18:38:49 18:03:12 392 8 6.250000 0 0 0 0 > > > > > > > > > > > 00:00:00 19:03:12 384 6 6.187500 0 0 0 0 > > > > > > > > > > > 00:00:01 19:03:12 384 6 6.187500 0 0 0 0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) > > > > > > > > > > > 22:25:08 18:03:12 6 2 5.562500 0 0 1 0 > > > > > > > > > > > 22:25:09 18:03:12 6 2 5.562500 0 0 1 0 > > > > > > > > > > > 00:00:00 19:03:12 6 2 5.562500 0 0 1 0 > > > > > > > > > > > 00:00:01 19:03:12 6 2 5.562500 0 0 1 0 > > > > > > > > > > > > > > > > > > > > > > GrüÃ?e Joerg > > > > > > > > > > > > > > > > > > > > Hallo Joerg, > > > > > > > > > > > > > > > > > > > > werde ich heute mal testen. > > > > > > > > > > > > > > > > > > > > Gruss Peter > > > > > > > > > > > > > > > > > > Hallo Peter, > > > > > > > > > > > > > > > > > > ich habe nun neue Erkenntnisse bezüglich der Zeitsprünge. > > > > > > > > > > > > > > > > > > Zuerst habe ich versucht, die Zeitsprünge zu detektieren und zu protokollieren. > > > > > > > > > Dabei habe ich festgestellt, dass die Häufigkeit und Art der Fehler mit der GröÃ?e des Codes zunimmt. > > > > > > > > > Zum Schluss bekam ich dann auch mal mit Clock_GetVal(CLOCK_SEC) Sekundewerte von 72 oder 110! > > > > > > > > > > > > > > > > > > Völlig frustriert bin ich dann auf die Version 2.13.015 zurück. Hierbei musste ich dann aber feststellen, > > > > > > > > > dass mit dieser Version noch alles viel schlimmer war. Selbst die globalen Variablen, > > > > > > > > > die ich zum protokollieren benutze, haben sich verändert. > > > > > > > > > > > > > > > > > > Ich habe dann über das Problem von Jo mit zu groÃ?em Code nachgedacht und folgendes durchgeführt: > > > > > > > > > > > > > > > > > > Unter Project Optionen habe ich â??Debug Code erzeugenâ?? und â??Array Index Grenzen überprüfenâ?? > > > > > > > > > abgewählt. Alles andere ist angewählt. # > > > > > > > > > Der generierte Bytecode ging dann von ca. 26100 auf 23800 zurück. > > > > > > > > > > > > > > > > > > Mit dieser Einstellung konnte ich mit der Version 2.13.015 und 2.20.016 keine Zeitsprünge mehr feststellen! > > > > > > > > > Das ganze läuft jetzt mit der 2.20.016 seit 14Stunden ohne Fehler. > > > > > > > > > > > > > > > > > > Ich vermute deshalb, dass es immer noch Fehler gibt bei zu groÃ?em Code. > > > > > > > > > > > > > > > > > > > > > > > > > > > Mit der Version 2.20.016 sind mir noch einige Dinge Aufgefallen: > > > > > > > > > > > > > > > > > > 1) Beim Laden erscheint manchmal im Ladebalken â??Wiederholeâ??. > > > > > > > > > 2) Der Irq_GetCount(INT_TIM2COMP) hat früher beim ersten Aufruf immer einen zufälligen Wert. > > > > > > > > > Dieser ist jetzt aber 1. > > > > > > > > > 3) Die Fenster im Editor lassen sich nur noch in voller GröÃ?e darstellen. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > GrüÃ?e Joerg > > > > > > > > > > > > > > > > Hallo Joerg, > > > > > > > > > > > > > > > > danke für die Infos. Ich hatte selber mal getestet, konnte aber kein Problem feststellen. Wenn > > > > > > > > das mit zu groÃ?em Code zu tun hat, wäre es gut, wenn Du mir vielleicht wieder ein Beispielprojekt > > > > > > > > schicken könntest. > > > > > > > > > > > > > > > > Bleibt das "Wiederhole" denn stehen, oder blitzt das nur kurz auf? Ich habe vieles am Handling > > > > > > > > des USB Virtual Comport in der Beta geändert. Man kann jetzt viel gefahrloser komplett den > > > > > > > > Strom der C-Control Unit ausschalten, was früher oft zu einem "hängen" des virtuellen Comport > > > > > > > > geführt hat. > > > > > > > > > > > > > > > > Gruss Petera > > > > > > > > > > > > > > Hallo Peter, > > > > > > > > > > > > > > das â??Wiederholeâ?? blitzt immer mal wieder kurz auf (ca.4 mal pro Ladevorgang). > > > > > > > Ich lade nur mit der seriellen Schnittstelle. > > > > > > > > > > > > > > Ich hatte dir bisher nie ein Beispielprojekt geschickt. > > > > > > > > > > > > Sorry, ich hatte kurz nach meiner Nachricht auch gegrübelt, ob Du der > > > > > > Joerg warst, der mir schon ein Beispiel geschickt hat. > > > > > > > > > > > > > Welche Erwartungen hast du denn daran? > > > > > > > Das man es kompilieren und laden kann oder soll es auch laufen? > > > > > > > > > > > > > > Das Programm ist äuÃ?erst komplex wie man an der GröÃ?e erkennen kann. > > > > > > > Ich habe ein Projectboard PRO128 mit sehr viel externen I2C Erweiterungen und Sensoren. > > > > > > > Wenn die nicht vorhanden sind, gibt es sehr viele Fehlerausgaben und es tut nicht mehr das, > > > > > > > was es soll. Ich müsste es dann noch modifizieren. Ob man den Fehler dann noch erkennen kann, > > > > > > > ist fraglich. Auch schalte ich meinen Detektor erst dann an, wenn mindestens ein > > > > > > > korrekter DCF Update stattgefunden hat. Bei mir findet ein DCF Update nur dann statt, > > > > > > > wenn zwei aufeinander folgende Minuten richtig erkannt werden und die Differenz nur eine Minute ist. > > > > > > > > > > > > > > Bei der Programmierung des Detektors habe ich festgestellt, das jede Ã?nderung am Code > > > > > > > die Häufigkeit und Art des Fehlers beeinflusst. Ich hatte auch Versionen, > > > > > > > da trat der Fehler nur 1mal in 24h auf. Man muss auf das Ergebnis also manchmal sehr lange warten. > > > > > > > > > > > > > > Gibt es hier eigentlich jemand, dessen Projekt noch wesentlich gröÃ?er ist als meins? > > > > > > > > > > > > Ja, ich hatte schon ein Beispiel, was genau an die Grenze der 128kb Flash heran reicht. Da > > > > > > hatte ich in der Vergangenheit ein Problem behoben, was aber nichts mit den Zeitroutinen > > > > > > zu tun hat. > > > > > > > > > > > > Ohne Beispiel das den Fehler reproduziert, habe ich es echt schwer den Bug zu finden. > > > > > > > > > > > > Gruss Peter > > > > > > > > > > > > > > > > > > > > > > > > > > > GrüÃ?e Joerg > > > > > > > > > > > > > > > > > Hallo Peter, > > > > > > > > > > ich versuche mal den Fehler ohne spezielle Hardware zu reproduzieren. > > > > > > > > > > GrüÃ?e Joerg > > > > > > > > > > > > Hallo Peter, > > > > > > > > mein Programm im Zielsystem ohne â??Debug Code erzeugenâ?? und ohne â??Array Index Grenzen überprüfenâ?? > > > läuft nun seit 34h fehlerfrei. > > > > > > > > Das gleiche Programm mit â??Debug Code erzeugenâ?? und â??Array Index Grenzen überprüfenâ?? > > > > auf dem Projektboard läuft natürlich nicht ohne Probleme. Die schreib und lese Versuche > > > > auf dem I2C erzeugen so viel Delay, das der Irq_GetCount(INT_TIM2COMP) nicht mehr > > > > unter 6 kommt. Es findet dann auch kein DCF Update mehr statt. Ich habe dann sämtliche I2C > > > > zugriffe entfernt. Nun läuft das Programm zwar, aber es treten keine Fehler mehr auf. > > > > Das Programm wird dir also nicht helfen. > > > > > > > > Für mich scheint das ganze ein Speicherproblem zu sein. > > > > Vermutlich wird der Stundenwert mit einer zu groÃ?en Zahl überschrieben und die Uhr > > > > springt nach 00:00:00. Das erklärt dann auch den Wechsel auf den nächsten Tag. > > > > Könnte das so sein? > > > > > > > > Vielleicht kannst du mir ja mal folgende Fragen beantworten: > > > > 1) Meine globalen Variablen liegen doch in der Reihenfolge im Speicher wie im MAP File angegeben oder? > > > > > > ja > > > > > > > 2) Wo liegt der Speicher meiner 12 Threads? Zusammenhängend davor oder danach? Reihenfolge? > > > > > > Erst kommt der Interpreter, dann die globalen Variablen, danach für jeden Thread ein Block > > > mit arithmetischem und Programmstack. > > > > > > > 3) Wo liegt der Stack des Hauptprogramms? > > > > > > Am Ende des RAM Speichers. > > > > > > > 4) Wo liegt der Speicher für die interne Uhr? Wer könnte diesen Speicher überschreiben? > > > > > > Der liegt im Interpreter RAM, das ganz am Anfang ist. Das kann eigentlich > > > gar nicht überschrieben werden. > > > > > > > > > > 5) Kann man irgendwie an die Adressen der Variablen kommen? > > > > > > Nein. > > > > > > > 6) Verschiebt sich der Speicher der Variablen bei â??Debug Code erzeugenâ?? oder â??Array Index Grenzen überprüfenâ??? > > > > > > Nein. > > > > > > > > > > > Eine art Speicherabbild währe sehr hilfreich um den Fehler zu lokalisieren. > > > > Ich könnte dann mal Dummy Arrays einbringen oder Threads vergröÃ?ern. > > > > > > 12 Threads sind ziemlich viel. Wieviel Speicher hast Du jedem Thread gegeben? > > > Dir ist bewuÃ?t, das Du für alle Threads und das Hauptprogramm ca. 2460 Bytes frei > > > hast? > > > > > > Gruss Peter > > > > > > > > > > > > > > > GrüÃ?e Joerg > > > > > > > > Hallo Peter, > > > > erstmal vielen Dank für die Info. > > > > Das mit dem Speicher habe ich eigentlich überall mit > > Thread_MemFree() überprüft. Natürlich kann man das nicht immer > > bis in die unterste Ebene überprüfen. Ich habe aber einiges > > an Reserve > > > > Meine Thread Konfiguration ist: > > > > #thread MAIN_THREAD, 0, 20 > > #thread R_GROUP_1, 64, 2 > > #thread R_GROUP_2, 64, 2 > > #thread R_GROUP_3, 64, 2 > > #thread R_GROUP_4, 64, 2 > > #thread R_GROUP_5, 64, 2 > > #thread R_GROUP_6, 64, 2 > > #thread R_GROUP_MARKISE, 64, 2 > > #thread R_GROUP_ALL, 80, 2 > > #thread R_SWITCH_CONTROL, 128, 2 > > #thread DOOR_CONTROL, 128, 2 > > #thread ALARM_CONTROL, 128, 2 > > #thread ENVIRONMENT_CONTROL, 128, 2 > > > > Das sind Ausgaben nach dem Starten: > > > > Thread Control 1is started! Mem Free = 58 > > Thread Control 2is started! Mem Free = 58 > > Thread Control 3is started! Mem Free = 58 > > Thread Control 4is started! Mem Free = 58 > > Thread Control 5is started! Mem Free = 58 > > Thread Control 6is started! Mem Free = 58 > > Thread Control 7is started! Mem Free = 58 > > Thread Control All is started! Mem Free = 73 > > Thread Switch Control is started! Mem Free = 119 > > Thread Door Control is started! Mem Free = 121 > > Thread Alarm Control is started! Mem Free = 121 > > Thread Environment C is started! Mem Free = 88 > > Main Mem Free = 1279 > > > > > > Das der Thread einen arithmetischem und Programmstack hat, > > war mir nicht bewuÃ?t. Was gebe ich den bei #thread an? > > Die Summe aus beiden? > > Ja, bei #thread wird die Gesamtzahl angegeben. Mit dem Arithmetik > Stack wird eine Stackmachine realisiert. Dies ist normalerweise > unkritisch, es sei denn man baut sich z.B. was tail-rekursives. > > > > > Der letzte Thread ist neu. Vorher lief das Programm > > ca. 1 Jahr ohne Probleme. Der Thread Environment > > führt auch Float operationen durch. Könnte das mit dem > > arithmetischem Stack ein Problem sein? > > Die Einheit auf dem Arithmetik Stack ist immer 4 Bytes, egal > ob man floats oder bytes berechnet, dies ist aus Effizienzgründen > so. > > > > > Ich programmiere beruflich seit 20 Jahren Signalprocessoren. > > Ich hatte schon etliche Probleme mit Speicherüberschreitungen. > > Wir mach zur Ã?berwachung des Speichers manchmal folgendes: > > Die Speicher werden mit unterschiedlichen Mustern vorbelegt. > > Ein Interrupt kontrolliert cyclisch diese Werte und gibt > > Fehler raus, wenn gewisse Grenzen überschritten werden. > > Vielleicht könnte man das Ende des Threadstacks auch so > > überwachen. > > Es gibt Ã?berwachungsfunktionen, die dies eigentlich melden, wenn man > zuviel Speicher benötigt. Du kannst aus SpaÃ? ja mal eine minimale > rekursive Funktion aufrufen, das sollte direkt erkannt werden. > > > > > > > Erstmal schönes Wochenende > > Dir auch! > > Gruss Peter > > > > > GrüÃ?e Joerg Hallo Peter, das mit den Ã?berwachungsfunktionen des Stack habe ich überprüft und es funktioniert. Wenn ich es mit dem Debugger laufen lasse, gibt es eine Fehlermeldung. Ohne Debugger scheint das Programm zu stoppen. Mein Watchdog schlägt dann vermutlich zu und startet das Programm neu. Einen Neustart nach Watchdog Reset protokolliere ich im EEPROM Den Unterschied zwischen einem fehlerfreien und fehlerhaften Programm konnte ich nun auf die Option â??Debug Code erzeugenâ?? reduzieren. Das mit den Fehlerhaften Sekundenwerten von Clock_GetVal(CLOCK_SEC) konnte ich jetzt noch einmal genauer beobachten. Die Sekunden sind wirklich bis auf 75 hoch gelaufen und dann erst auf Null. Ich hatte einen Fall, da war die ausgegebene Uhrzeit: 17:35:106 Die wirkliche Uhrzeit war aber 17:36:46 Dies spricht natürlich gegen ein Ã?berschreiben. Des Weiteren ist mir bei der fehlerfreien Version folgendes aufgefallen: In dem neue Thread ENVIRONMENT_CONTROL lese ich Umweltdaten aus. Dies sind z.B. Frequenzwerte eines Licht und Windsensors sowie die Temperatur mit einem DS1820 Sensor. Ca. 5 â?? 10mal am Tag traten bisher Fehler auf. Z.B. waren die Frequenzen des Windsensors auÃ?erhalb der Spezifikation oder die CRC Ã?berprüfung beim DS1820 schlug an. Diese Fehler werden bei mir protokolliert. Bisher dache ich, dass dies wirklich Störungen sind. Allerdings lief das Programm ohne â??Debug Code erzeugenâ?? 5 Tage ohne einen einzigen Fehler! GrüÃ?e Joerg | ||
Antwort schreiben Antworten:  Re: Zeitsprünge (von PeterS - 2.04.2012 11:50) | ||
Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - Zum C-Control-I-Forum - Zum C-Control-II-Forum