da ich nicht den thread von "hijacken" möchte, fasse ich meine Erfahrungen mit meinen iTELEX reboots in diesem thread zusammen.
Meine Anlage ist aus dem Jahr 2016 und besteht aus den Komponenten iTELEX Karte/iTELEX Busplatine/TW39-seriell Karte.
Meine HArdware:
- iTELEX, hw 1.4,
- tw39+spezial 2.x mit AB-Funktion
- fertige Busplatine
Das System läuft 24 Stunden und die reboots passieren nur im Kommunikationsbetrieb, wenn also Text empfangen wird, besonders, wenn dieser länger ist.
Eigenartigerweise laufen in meiner Konstellation nur einige Firmware-Versionen stabil ,genauer gesagt 2 Stück.
Bei den anderen Versionen führt das System ein Kartenreset durch.
Testweise habe ich im meiner häuslichen Infrastruktur Komponenten abgeschaltet, um Störeinflüsse zu vermeiden.
http://www.telexforum.de/viewtopic.php?f=6&t=208
a) DECT Telefone / Stationen abgeschaltet
b) weitere LAN Komponeten von der Fritz!Box abgezogen
c) WLAN abgeschaltet
Leider gab es keine Verbesserungen. Mit den folgenen Versionen habe ich die folgenen Erfahrungengemacht.
build 621 resets bei längeren Fernschreiben, z.B. Listenabruf
build 636 stabil
build 654 resets bei längeren Fernschreiben, z.B. Listenabruf
build 659 resets bei längeren Fernschreiben, z.B. Listenabruf
build 663 resets bei längeren Fernschreiben, z.B. Listenabruf
build 666 resets bei längeren Fernschreiben, z.B. Listenabruf
Gerne würde ich aber von Weiterentwicklungen profitieren, welche natürlich in neuere Versionen einfließen, doch bisher gibt es dort bei mir Stabilitätsprobleme.
Ich habe nun einmal eine Webcam aufgebaut und die LEDs in meiner Anlage abgefilmt, um einen Hinweis auf die Resetursache zu bekommen.
Zeitgleich lief ein Terminalprogramm mit, welches Systemmeldungen mitloggt.
Nach einem reset zeigt das DEBUG Log in iTELEX Webinterface, bzw. in der seriellen DEBUG-Console lediglich nur das "Resetflag 08" an,
welches auf ein Softwarereset schließen läßt. Ich dachte erst an einen Pufferüberlauf des Empfangspuffers, aber so genau kenne ich mich mit der Software nicht aus. Ich kann auch nicht sagen, ob die resets nach einer gewissen Zeit oder erst nach einer gewissen Datenmenge ausgeführt werden.
Die Funktion der ResetFlags hat Fred in dem thread hier beschrieben.
http://www.telexforum.de/viewtopic.php? ... 5&start=30
16 = Bit 4: Reset durch JTAG-Schnittstelle (kann nicht vorkommen)
8 = Bit 3: Reset durch Watchdog (da es keinen Reset-Assembler-Befehl gibt wird ein absichtlicher Reset dadurch gelöst, dass man den Watchdog ablaufen lässt)
4 = Bit 2: Brown-Out Reset: Versorgungsspannung war zu gering
2 = Bit 1: External Reset: Kommt nicht vor, da der externe Reset-Eingang nur von der Programmier-Schnittstelle "bearbeitet" wird.
1 = Bit 0: Power-On Reset: Versorgungsspannung wurde erstmals angelegt.
Das System wurde durch einen Watchdog-Mechanismus automatisch neu gestartet.
Ich habe mit der Firmware build 666 diese Tests nocheinmal wiederholt.
Zufälligerweise habe ich hier im angehängten Logfile (0-0) einen seltenen Fall eines resets nach ganz kurzer Zeit eingefangen.
In dem Beispiel wird die Telexauskunft angerufen. Meistens passiert das Verhalten bei längeren Verbindungen.
Das 2. Logfile zeigt Abbrüche, während Wetternachrichten abgerufen wurden.
Angehängt habe ich das Logfile und den Link zum Video.
Video mit LED Beobachtung (Absturz bei ca. 1:30 )
Logfile nach dem Reboot
10:59:33,24: iTelex(23820): Ascii-Verarbeitung: ' 212129 - Henning T37 Flur - (33) i-Telex' 0D 0A (+0)
10:59:33,24: iTelex(23820): gewandelt in: ' 212129 - Henning T37 Flur - (33) i-Telex' 0D 0A
10:59:41,25: iTelex(58867): Ascii-Verarbeitung: ' 246463 - Henning Test-TxP - i-Telex' 0D 0A (+0)
10:59:41,26: iTelex(58867): gewandelt in: ' 246463 - Henning Test-TxP - i-Telex' 0D 0A
10:59:48,51: iTelex(25065): Ascii-Verarbeitung: ' 488868 - Henning Testanlage 2 - i-Telex' 0D 0A (+0)
10:59:48,51: iTelex(25065): gewandelt in: ' 488868 - Henning Testanlage 2 - i-Telex' 0D 0A
10:59:56,07: iTelex(58100): Ascii-Verarbeitung: ' 517601 - Henning URL - i-Telex' 0D 0A (+0)
10:59:56,07: iTelex(58100): gewandelt in: ' 517601 - Henning URL - i-Telex' 0D 0A
iTelex...
UART Initialisiert
STDOUT Initialisiert
CLOCK Initialisiert
LED_core Initialisiert
Config Initialisiert
EXTINT Initialisiert
MMC/SD Error
SHELL Initialisiert
THREAD Initialisiert
ENC28j60 (Rev.: 6) initialisiert ( HW-Add: 02:03:6f:55:1c:c8 ) Fullduplex: Link ready
-+-> ARP initialisiert
|-> UDP (Tornado-engine) initialisiert
|-> TCP (Hurrican-engine) initialisiert
|-> Versuche DHCP-Config zu holen. DHCP-Config Fehlgeschlagen
| IP : 192.168.4.131
| Netmask: 255.255.255.0
| Gateway: 192.168.4.1
| DNS : 192.168.4.1
|-> NTP-Server Zeit aktualisieren: Zeit: 11:01:53.36
HTTP-Server Port 80.
Telnet-Server Port 23.
itelex_init:
...SendePuffer, EmpfPuffer ok
...Config ok
...Timer-Callback-Funktion ok
...Cgi ok
iTelex Port 134.
...Email ok
...TlnBuch ok
iTelex TlnServer Port 11811.
...Teilnehmer-Server ok
11:01:53,38: Neustart 666 Reset-Flags 08
11:01:53,57: iTelex: * Teilnehmer-Verzeichnis wird unveraendert uebernommen.
Ich möchte herausfinden, ob sich bei der Watchdogprogrammierung nach der Version build 636 für die folgenden Versionen
etwas geändert hat, was sich in meiner HW/Software Konstellation auswirken könnte. Wenn ich wüßte was, könnte ich vielleicht nach einer Einarbeitung probieren, eine aktuelle Version mit der alten Watchdogprogrammierung zu compilen ... unter der Annahme , daß es da überhaupt eine Änderung gab.
Vielleicht erbarmt sich aber auch eine kundige Person, eine Testversion herzustellen.
Habt Ihr noch Ideen für mich ?
MfG
Frank