Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C Quellcode formatieren: <code>Quellcode</code> BASIC Quellcode formatieren: <basic>Quellcode</basic> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! -> I > > > > > > > > > > > > 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 > > >
