Webserver nach Telnetverb. in Resetschleife

[abc123]

Hallo,

ich habe ein Problem mit der Software oder dem Webserver von Ulrich Radig.

Ich nutze (oder versuche es zumindest) den Webserver als RS232 -> Telnet Wandler.
Leider habe ich das Problem dass nach nicht mal 5min (Zeit variiert) der Webserver nicht mehr per Telnet ansprechbar ist.
Die Verbindung bricht plötzlich beim empfangen ab oder lässt sich gar nicht mehr herstellen.
Der ATmega 644P (mit 16MHz getaktet) geht in eine Resetschleife über und startet ständig hintereinander neu. (aber nicht vollständig)

Die Ausgabe der RS232 Schnittstelle sieht dabei wie folgt aus:

Code: Alles auswählen

System Ready
Compiliert am Apr 1 2009 um 12:15:15
Compiliert mit GCC Version 4.3.0

Durch ein Reset des Controllers funktioniert die Telnetverbindung dann wieder für max. 5 min, bis dann der gleiche Effekt auftritt.

Folgender Datenframe wird im ca. 3sec Zyklus an die RS232 Schnittstelle des Webservers gesendet:

Code: Alles auswählen

"#CSV", "xxxxxxxxxxxxxxxxxxxxx","xxxxxxxxxxxxxxxxxx","xxxxxxxxxxxxxxx"

Ich habe auch schon versucht die Daten nur bei Tastendruck zu senden, jedoch tritt auch hier das selbige Problem auf.
Die Puffergröße wurde Testweise angehoben, dies brachte jedoch keine Veränderung.

PS: Der Effekt tritt sowohl mit Hyperterminal als auch mit telnet und netcat unter ubuntu auf.

Gruß
abc123

EDIT: Es wurde zum testen ein älterer und der aktuelle Strack verwendet, jedoch ohne Änderung.

[abc123]

So, ich habe festgestellt, dass der Webserver nur in die Resetschleife fällt, wenn ihm auch Daten per RS232 zugesendet werden.
Ich habe gerade per Skript mehrere Stunde lang Daten vom PC per telnet an den Webserver versendet.
Diese wurden auch korrekt wieder gegeben und es gab keine Abbrüche oder Fehler.
Sobald ich jedoch wieder per RS232 Daten sende hängt sich der Webserver nach max. 5-10min auf.
Muss ich beim senden von Daten irgendwas beachten? (z.B. ein „End of Transmission“ nach jeder Zeile senden?)


Grüße
abc123

[jornbyte]

Bei der RS232 fehlt die Datenflusskontrolle, was ja im Normalfalle nicht schlimm ist. Prüf mal ob das RS232-Puffer für den Reset verantwortlich ist.

[abc123]

Wie genau kann ich dass feststellen?
Bzw. ist der Reset ein Anzeichen für einen Überlauf?
Die Ausgabe oben wir ungefähr im 2-3s Zyklus gesendet.
Mein der Puffergröße selber habe ich auch schon "rumgespielt" und diesen vergrößert (bis max. 1000), jedoch ohne Besserung.

[Fred Froehlich]

Hallo,
ich hatte ein ähnliches Problem.
Bin mir aber nicht sicher, ob die Ursache damals mit meinem PC-Programm
zusammenhing - hatte mir mein eigenes Programm umgeschrieben,
sodass die Kommunikation, die vorher direkt über RS232, lief nun über TCP->RS232 ging.
Nach ein paar Minuten (bei schneller Kommunikation früher) kam keine Antwort mehr
vom Webserver.

Der Puffer sollte eigentlich nicht überlaufen - es ist ja eine Bedingung drin, die
bei Puffer=voll die Daten einfach ignoriert.

Code: Alles auswählen

if(rx_buffer_pointer_in == (rx_buffer_pointer_out - 1))
		{
			//Datenverlust
			return;
		}

Bin der Sache aber nicht weiter nachgegangen, da ich folgendes geändert hatte:
Mein RS232-Gerät schickt nur Daten aufgrund eines Befehls, den ich vorher sende.
Dann weiss ich auch, wieviel Daten ankommen müssen.
Wenn ich nun solch einen Befehl über TCP an das RS232 Gerät sende, sammelt der Webserver
ALLE erwarteten RS232 Daten ein und schickt sie dann in EINEM TCP-Paket zurück.
Das funktioniert bisher ohne Probleme.
Vorher hat er gleich nach den ersten empfangenen Zeichen ein TCP Paket geschickt und dann den inzwischen gesammelten Rest.

Retransmission habe ich ausgeschaltet. Irgendwie war da immer was durcheinander gekommen. Wireshark hat die Daten total wirr aufgelistet.

Wie gesagt, habe nicht weiter gesucht.
Vielleicht ist es aber eine Lösung, die auch bei Dir geht, wenn du die eigentliche Ursache nicht findest.

Gruss

[abc123]

Hallo,

@ Fred Froehlich
Danke für deinen Beitrag und die Erklärungen!!!
Hast du das Programm zufällig noch da, bzw. die Änderungen?

Ich würde es jedoch lieber per Telnet machen wollen.
Ich habe auch schon ein Skript geschrieben (telnet und netcat unter Linux), welches jeweils immer einen "Befehl" an den Controller welcher per RS232 am Webserver hängt sendet.
Und nur dann hat auch der Controller geantwortet bzw. jeweils nur einen Datensatz gesendet.

Jedoch bestand nach kurzer Zeit wieder dasselbe Problem, der Webserver hängt.
Sende ich Befehle worauf der Controller nicht antwortet passiert nichts und der Webserver bleibt auch nach Stunden noch problemlos ansprechbar.
Leider ist somit die Telnettunnelung des Webservers noch nicht stabil anwendbar.

Ic hoffe das jemand die fehlerhafe Routine finden kann, ich bin hierdran gescheitert.

[abc123]

Ich habe mal in das Main- Programm eine Resetroutine eingebaut.

In der Whileschleife wird ein Flag auf 1 gesetzt.

Code: Alles auswählen

tmp = 1;

Wenn jetzt der Controller wieder in seiner Resetschleife hängt, löse ich per Watchdog selber einen Reset aus.

Code: Alles auswählen

if(tmp == 1)
{
     cli();
     wdt_enable (WDTO_15MS);         
     while (1);                         
}

usart_write("\n\rSystem Ready\n\r");
usart_write("Compiliert am "__DATE__" um "__TIME__"\r\n");
usart_write("Compiliert mit GCC Version "__VERSION__"\r\n");

Jedoch ohne Erfolg.
Erst nach einem Reset per Taster ist der Controller wieder „anpingbar“ und per telnet zu erreichen.
Kann es sein, dass der ENC ab einem bestimmten Punkt nicht mehr ansprechbar ist und das Problem gar nicht in der Telnetroutine liegt?

Gruß und noch ein schönen Freitag.....

[abc123]

Hallo,

ich habe noch mal einige ältere Versionsstände der Radigsoftware ausprobiert, immer mit demselben Ergebnis.
Was mir auch auffiel, einige male ließ sich der Webserver nicht mal mehr per Taster aus der Resetschleife holen.
Es musste teilweise die Stromversorgung gekappt werden, sodass dieser wieder normal startete.
Außerdem trat der Fehler unter diversen Linuxdistributionen ehr auf als unter Windows.
(Ich habe unter Windows per Hyperterminal eine recht lange Textdatei an den Webserver gesendet und unter Linux per telnet oder netcat diese entgegengenommen)


Gruß
noch einen schönen Sonntag

[Ulrich]

Hallo,

leider konnte ich den Fehler bisher nicht nach voll ziehen!

Gruß
Uli

[abc123]

Hallo Ulrich,

ich kann dir ja mal eine kleine Anleitung schreiben, wie du den Fehler reproduzieren kannst:

Der AVR Webserver hat die IP Adresse 192.168.1.99 (WOL, NTP. DHCP deaktiviert).

Dann habe ich 2 PCs laufen.

PC1 mit Windows XP SP3 ist per RS232 mit dem AVR Webserver verbunden.

Auf PC2 läuft eine Linuxdistribution (z.B. eine Ubuntu „Live-Version“).
PC2 hat als Netzwerkeinstellung die IP- Adresse 192.168.1.2.

Wenn alles „zusammengesteckt“ ist und läuft, mache ich folgendes:

Auf dem PC2 baue ich eine Telnetverbindung zu dem AVR Webserver auf.
Dazu können folgende Konsolenbefehle genutzt werden:
„telnet 192.168.1.99“ oder
„netcat –t 192.168.1.99 23“

Danach öffne ich auf PC1 HyperTerminal und wähle im Menü „Übertragung -> Txtdatei senden…“ aus.
Als Textdatei habe ich eine angelegt, welche ein paar 1000 mal hintereinander das Wort Test sendet.
Danach beginnt HyperTerminal mit dem senden.

Nach max. 1 Minute hängt sich nun der Webserver auf, bis dahin wird auf der Gegenstelle, also dem Linuxterminal alles korrekt empfangen.

Das „Aufhängen“ äußert sich dann so, dass der Controller in einer Resetschleife hängt und immer wieder seinen Initialisierungstext ausgibt.

Also diesen Teil hier:
usart_write("\n\rSystem Ready\n\r");
usart_write("Compiliert am "__DATE__" um "__TIME__"\r\n");
usart_write("Compiliert mit GCC Version "__VERSION__"\r\n");

Manchmal ist ein Reset per Taster möglich, manchmal muss die Stromversorgung gekappt werden sodass der Webserver wieder normal startet.


In dem normalen Anwendungsfall wo mir der Fehler auffiel, wird halt alle 2-3s der oben angegebene Datenramen von einem anderen ATmega per UART gesendet.

Ich hoffe das hilft dir weiter um den Fehler reproduzieren zu können.

Gruß
abc123 (der bald verzweifelt )

[Ulrich]

Also ich habe nun min 5min über Telnet (WinXP SP3) Daten an den Webserver gesendet ohne Absturz. Wurde irgendet was an der Software geändert? Evt. gibt es Probleme mit dem ENC die Software sollte nach einen normalen Reset laufen. Welche Version vom ENC wird benutzt und welche Software Version? Ich gehe mal davon aus das der ENC Probleme macht, der AVR läuft ja nach einem Reset.

[abc123]

Und unter Linux wurde auch eine Telnetverbindung zum Webserver aufgebaut??
Wenn ich die Daten unter Windows per telnet empfange pasiert häuft gar nichts, bzw. es läuft normal.
---------

Die Software habe ich so gelassen (also das fertige Hexfiles genommen) aber auch meine angepasste Version macht Probleme.
Ich habe es sowohl mit 2 versch. Webservern getestet (einmal mit einem 644 und einmal mit einem 644p) also auch mit einem anderen Computersystem.
Die ENC Version kann ich morgen mal abfragen, ich habe gerde keine Möglichkeit diese rauszubekommen.

Ich habe auch das Gefühl das der Controller versucht normal zu starten, aber der ENC nicht mehr initialisiert werden kann.

PS. Ich kann bei Gelegenheit mal per JTAG nachsehen an welcher Stelle das Programm "hängen" bleibt. Die Pins dafür scheinen ja ungenutzt zu sein.

[Thomas]

Hier:
- Nur ein Rechner (Vista32)
- com1 sendet an RS232 des ETH
- putty als Telnetclient empfängt von Port 23 des ETH


Mit der Konsole des Rechners sende ich: (Windows!)

Code: Alles auswählen

echo 1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ >com1

Von Port 23 kommt reproduzierbar nur ein Teil an:

1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMN\n

Speichere ich den String in eine Datei (ohne Umbruch am Ende) und übertrage diese per "type text.txt >com1" erhalte ich:

1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNZ

Am Ende kommt noch das Z!!! ???

Dabei sendet das ETH jeweils 3 mal (ohne weitere Auffälligkeit) lediglich die Aufteilung der Daten ist seltsam. Siehe capture.txt.


P.S. Sende ich eine 1000xTest-Datei, bleibt das ETH nicht hängen, aber es kommt nur die hälfte an, ca.

[abc123]

Wie gesagt, unter Putty und überhaupt unter Windows hatte ich selten Probleme.
Hauptsächlich unter Linux....

PS. ENC28J60-Version: 6

[Thomas]

Also wurden bei dir die Daten (unter Windows) korrekt übertragen? (Bei mir wird ja die Hälfte nicht gesendet!)

Unter Linux werde ich das noch testen, wenn ich ergründet habe, wo die Zeichen verloren gehen.