Telexforum.de

Interessante Beobachtung am Rande: Ist die Eth-Karte "blockiert", zeigt also das rote Lämpchen, so wird die Karte *NICHT* mehr durch fragmentierte ICMP-Echo-Requests abgeschossen. Das verstehe ich nicht ganz, denn die Eth-Behandlung (inklusive Verwurf zu langer oder fragmentierter Frames) ist ja im Interrupt und sollte daher nicht von der Threadblockade betroffen sein. Die Blockade habe ich durch Blockieren des I2C-Busses provoziert.

Frage an Fred am Rande: Läuft bei Dir die Eth-Karte mit angeschlossener serieller Debugschnittstelle? Komischerweise blockiert die Karte bei mir reproduzierbar, wenn ich seriell etwas angeschlossen habe um dort mitzulesen und dann einne HTTPS-Request sende. Ich sehe dann die HTTP-Abfragen im Debug, aber sie laufen dann aufs rote Lämpchen und auf Timeout im Browser. Das passiert lustigerweise nicht wenn die Schnittstelle unbeschaltet ist, ggf. Blockade über Hardwarehandshakesignale?

ProgBernie hat geschrieben: ↑Di 14. Jul 2020, 11:51 Interessante Beobachtung am Rande: Ist die Eth-Karte "blockiert", zeigt also das rote Lämpchen, so wird die Karte *NICHT* mehr durch fragmentierte ICMP-Echo-Requests abgeschossen. Das verstehe ich nicht ganz, denn die Eth-Behandlung (inklusive Verwurf zu langer oder fragmentierter Frames) ist ja im Interrupt und sollte daher nicht von der Threadblockade betroffen sein. Die Blockade habe ich durch Blockieren des I2C-Busses provoziert.

So komplett habe ich die bestehende Struktur des Basisprojekts "OpenMCP" noch nicht durchschaut, ich vermute aber, dass in der Interrupt-Behandlung nur "zeitkritische" Aktionen laufen (Vermutung: Daten abholen und in einen Puffer schreiben).
Alles andere läuft in "kooperativen" Threads. Von diesen Threads ist die i-Telex-Kernfunktion nur einer, der HTTP-Server z.B. ein anderer.
Das zeitkritische Generieren des 50 Baud-Taktes ist in einer Interrupt-Funktion realisiert. Diese prüft, ob auch der "normale" i-Telex-Thread mindestens alle 2 Sekunden aufgerufen wird, wenn nicht, wird die rote Lampe angemacht.
Wenn also die rote Lampe an ist, werden vermutlich alle nicht-interrupt-gesteuerten Funktionen aufgerufen, wahrscheinlich auch nicht die, die den "Absturz" verursacht.

Frage an Fred am Rande: Läuft bei Dir die Eth-Karte mit angeschlossener serieller Debugschnittstelle? Komischerweise blockiert die Karte bei mir reproduzierbar, wenn ich seriell etwas angeschlossen habe um dort mitzulesen und dann einne HTTPS-Request sende. Ich sehe dann die HTTP-Abfragen im Debug, aber sie laufen dann aufs rote Lämpchen und auf Timeout im Browser. Das passiert lustigerweise nicht wenn die Schnittstelle unbeschaltet ist, ggf. Blockade über Hardwarehandshakesignale?

Das ist sehr merkwürdig. Das RTS und CTS sind zwar an den Atmel geführt, werden aber nicht ausgewertet.
Ich sinniere gerade, ob irgendwelche an die Serielle Schnittstelle gesendeten Daten irgendwas anrichten können.
Aber das ist nicht der Fall, wenn der Empfangspuffer voll ist, dann werden Daten von dem UART verworfen.
Ich habe schon häufig über Stunden die serielle Debug-Ausgabe aufgezeichnet, nie hatte ich dort ein anderes Verhalten als sonst.
HTTPS-Request an Port 80 oder wie?

Hallo Fred,

vielleicht sollten wir die Diskussionen in die Entwickler-Ecke verschieben?

FredSonnenrein hat geschrieben: ↑Di 14. Jul 2020, 13:07 So komplett habe ich die bestehende Struktur des Basisprojekts "OpenMCP" noch nicht durchschaut, ich vermute aber, dass in der Interrupt-Behandlung nur "zeitkritische" Aktionen laufen (Vermutung: Daten abholen und in einen Puffer schreiben).

Das ist leider nicht ganz so, zumindest die gesamten ICMP-Sachen laufen alle komplett innerhalb des Interrupts, sogar das Senden der Antwort. Ich hätte auch erwartet daß die empfangenen Frames in eine Queue gepackt werden und dann später verabreitet. Aber die Methode ethernet() in system/net/ethernet.c is direkt die ISR und ruft arp() bzw. ip() auf. In ip() wird dann nach icmp(), udp() und tcp() verzweigt.
icmp() behandelt den EchoRequest direkt und ruft sogleich wieder sendEthernetFrame auf.
udp() und tcp() kopieren die Daten in die entsprechende socket-Struktur.

FredSonnenrein hat geschrieben: ↑Di 14. Jul 2020, 13:07 Alles andere läuft in "kooperativen" Threads. Von diesen Threads ist die i-Telex-Kernfunktion nur einer, der HTTP-Server z.B. ein anderer.
Das zeitkritische Generieren des 50 Baud-Taktes ist in einer Interrupt-Funktion realisiert. Diese prüft, ob auch der "normale" i-Telex-Thread mindestens alle 2 Sekunden aufgerufen wird, wenn nicht, wird die rote Lampe angemacht.
Wenn also die rote Lampe an ist, werden vermutlich alle nicht-interrupt-gesteuerten Funktionen aufgerufen, wahrscheinlich auch nicht die, die den "Absturz" verursacht.

Ja, nur komischerweise müsste der Absturz eigentlich ja im ISR passieren, wenn es um ICMP geht. Und dort hatte ich ja eingebaut, fragmentierte Frames zu verwerfen. da hatte ich fest mit einem Erfolg gerechnet.

FredSonnenrein hat geschrieben: ↑Di 14. Jul 2020, 13:07 Das ist sehr merkwürdig. Das RTS und CTS sind zwar an den Atmel geführt, werden aber nicht ausgewertet.
Ich sinniere gerade, ob irgendwelche an die Serielle Schnittstelle gesendeten Daten irgendwas anrichten können.
Aber das ist nicht der Fall, wenn der Empfangspuffer voll ist, dann werden Daten von dem UART verworfen.
Ich habe schon häufig über Stunden die serielle Debug-Ausgabe aufgezeichnet, nie hatte ich dort ein anderes Verhalten als sonst.
HTTPS-Request an Port 80 oder wie?

Normaler Aufruf der 80er-Webseite. Ich kann es mir auch nicht so recht erklären. Ich dachte es liegt an meinen eingebauten Debugs, aber auch ein flashen der "offiziellen" 867 änderte da nichts.

Noch eine Frage. Du sagtest das Blinken der grünen wäre ein erfolgloser RAM-Test. Ich habe das im code und experimentell nicht bestätigen können. Ein fehlschlagender RAM-Test lässt rot-gelb an und grün dauerhaft aus, habe ich mit einer Manipulation am 573 provoziert. Auch xram.c sagt da: LED aus, WDT aus und Endlosschleife.

BTW: Ich habe jetzt den Code komplett ohne die als DEPRECATED markierten prog_char am laufen.

Debugausgabe bei angeschlossenem Sellerie-Kabel:

Code: Alles auswählen

iTelex...
UART Initialisiert
STDOUT Initialisiert
CLOCK Initialisiert
LED_core Initialisiert
Config Initialisiert
EXTINT Initialisiert
MMC/SD Error
SHELL Initialisiert
THREAD Initialisiert
itelex_init1:
...SendePuffer, EmpfPuffer ok
...Config ok
...Timer-Callback-Funktion ok
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 geholt
 |   IP     : 192.168.178.90
 |   Netmask: 255.255.255.0
 |   Gateway: 192.168.178.1
 |   DNS    : 192.168.178.1
 |-> NTP-Server Zeit aktualisieren:Oeffne neues Socket.
UDP-Socket aufgemacht zur 130.133.1.10.
UDP-Packet gesendet.
Warte auf Antwort.Antwort erhalten.
UDP-Socket geschlossen.
 Zeit: 18:56:57.84
HTTP-Server Port 80.
Telnet-Server Port 23.
itelex_init2:
...Cgi ok
iTelex Port 134.
...Email ok
...TlnBuch ok
http-server: index.html ( 470 Byte uebertragen (FLASH)
http-server: headline.html ( 217 Byte uebertragen (FLASH)
http-server: mainmenu.html ( 448 Byte uebertragen (FLASH)
http-server: info.html ( 910 Byte uebertragen (FLASH)
http-server: lochstreifen-hg.png ( 777 Byte uebertragen (FLASH)
http-server: style.css ( 448 Byte uebertragen (FLASH)
http-server: favicon.ico ( 0 Byte uebertragen (SD)
http-server: itelex-menu-de.html ( 542 Byte uebertragen (FLASH)

Aufgerufen wurde zunächst die Startseite, dann i-Telex (Deutsch), dann Debug-Infos. Beim Abruf der Debug-Infos geht dann die rote LED an und bleibt es bis zum Watchdog, der die Karte erneut startet. Die Webseite zeigt die Debug-infos bis:

Code: Alles auswählen

TCP_socket[0]: ConnectionState=16, SendState=0, SourcePort=47156, DestinationPort=80, SourceIP=2EB2A8C0, Timeoutcounter=30
TCP_socket[1]: closed
TCP_socket[2]: closed
TCP_socket[3]: closed
TCP_socket[4]: closed
TCP_socket[5]: closed
NetzPort = 134
NetzEigeneIP = 00
LangTimerVal(&ZeitServerAbfrageTimer) = 4

Nehme ich das Kabel ab, so kommen alle Zeilen der Debug-Infos im Browser. Aber nun kommts: Nehme ich den MAX232ACPE aus der Platine, bleibt die Ausgabe auch hängen! Ich nehme an das Aufleuchten von rot bei Abruf der Webseiten ist normal, das passiert nämlich immer.

Und noch was interessantes: Die 825 protokolliert seriell und hängt sich dabei auch nicht weg. Viel weniger "ROT" bei Zugriffen über HTTP und alles wird seriell ohne Hänger geloggt.

Die Zeilen

Code: Alles auswählen

iTelex TlnServer Port 11811.
...Teilnehmer-Server ok
00:00:00,20: Neustart 825 Reset-Flags 05
23:33:08,09: iTelex: Teilnehmer-Verzeichnis aus EEPROM geladen.

fehlen mir in den neueren Versionen stets.

Dann werde ich mal den Unterschied zwischen der 825 und der aktuellen Version genau überprüfen.
Fakt ist: Die Teilnehmer-Server-Funktion ist entfernt (da nicht mehr benötigt), dass auch das Auslesen des EEPROM dabei auf der Strecke geblieben ist, ist nicht beabsichtigt gewesen.

So, ich habe vermutlich die Probleme gefunden, ein bufferoverflow in einer Blockread-Methode über SPI. Mit den Änderungen bekomme ich erstmal meine Karte nicht mehr ohne weiteres abgeschossen, mal sehen was die Truppe von außen erreichen kann. Auch die Serielle funktioniert wieder besser.

Ich hänge hier mal die patches an:

Code: Alles auswählen

diff --git a/hardware/spi/spi_1.c b/hardware/spi/spi_1.c
index 71104f8..ec6419b 100644
--- a/hardware/spi/spi_1.c
+++ b/hardware/spi/spi_1.c
@@ -130,7 +130,7 @@ void SPI1_FastRead2Mem( char * buffer, int Datalenght )
 	int Counter = 0;
 	char data;
 
-	while( Counter <= Datalenght )
+	while( Counter < Datalenght )
 	{
 		// warten auf fertig
 		while ( !( UCSR0A & (1<<UDRE0)) );
@@ -153,7 +153,7 @@ void SPI1_FastRead2Mem( char * buffer, int Datalenght )
 	int Counter = 0;
 	char data;
 
-	while( Counter <= Datalenght )
+	while( Counter < Datalenght )
 	{
 		// warten auf fertig
 		while ( !( UCSR1A & (1<<UDRE1)) );

Zusätzlich halte ich die folgenden Änderungen für sehr sinnvoll, da sie prinzipiell die Stabilität verbessern sollten:

1. Verwerfen aller fragmentierter Frames, sie werden ohnehin nicht korrekt assembliert:

Code: Alles auswählen

diff --git a/system/net/ip.c b/system/net/ip.c
index 79cc4c5..0a94d94 100644
--- a/system/net/ip.c
+++ b/system/net/ip.c
@@ -78,8 +78,8 @@ void ip( int packet_lenght ,  char *buffer )
 											// checke mal ob dat ÃƒÂ¼berhaupt fÃƒÂ¼r uns ist
 		// if ( IP_packet->IP_DestinationIP != myIP || IP_packet->IP_DestinationIP != 0xffffffff ) return;
 
-//		if ( ( IP_packet->IP_Flags_Fragmentoffset & htons( FRAGMENTOFFSET_bm ) ) == 0 )
-//		{
+		if ( ( IP_packet->IP_Flags_Fragmentoffset & htons( FRAGMENTOFFSET_bm ) ) == 0 )
+		{
 			switch ( IP_packet->IP_Protocol )
 			{
 				case 0x01:			if ( IP_packet->IP_DestinationIP != myIP ) return;
@@ -96,7 +96,7 @@ void ip( int packet_lenght ,  char *buffer )
 #endif
 				default:			break;
 			}
-//		}
+		}
 	}
 
 /* -----------------------------------------------------------------------------------------------------------*/

2. Korrektur von ICMP-EchoReplies, diese haben eine um 4 Byte zu große Länge (Checksum)

Code: Alles auswählen

diff --git a/system/net/icmp.c b/system/net/icmp.c
index e56a4b6..2b95930 100644
--- a/system/net/icmp.c
+++ b/system/net/icmp.c
@@ -75,7 +75,7 @@ void icmp( int packet_lenght, char *buffer)
 										ETH_packet->ETH_sourceMac[i] = mymac[i];
 									}
 									// und ab die post
-									sendEthernetframe( packet_lenght, buffer); // packet_lenght - 4 weil der Controller die checksumme selber berechnet
+									sendEthernetframe( packet_lenght - 4, buffer); // packet_lenght - 4 weil der Controller die checksumme selber berechnet
 									break;
 		case ICMP_EchoReplay:		if ( ICMP_packet->ICMP_Identifierer == 0xac1d && ICMP_Replaystate == ICMP_WaitForReplay )
 										ICMP_Replaystate = ICMP_ReplayOkay;

Moin,

tolle Detektivarbeit, finde es jeden Tag spannend die Neuigkeiten zu lesen.

Eine ausrollbare Abhilfe rückt in greifbare Nähe.

(Ich sehe auch, du hast schon geforkt, habe gleich meinen Stern gesetzt.)

Grüße

Björn

Um dem ganzen einen gewissen Abschluß zu geben:
Seit der Korrektur (siehe auch im Entwickler-Thread) arbeitet die Eth-Karte bei mir wieder absolut zuverlässig und stabil. Aktueller Stand:

Code: Alles auswählen

SystemStartZeit = 16.07.2020 16:15:45, ResetFlag = 05

Telexforum.de

Ethernet-Karte Hänger

Re: Ethernet-Karte Hänger

Re: Ethernet-Karte Hänger

Re: Ethernet-Karte Hänger

Re: Ethernet-Karte Hänger

Re: Ethernet-Karte Hänger

Re: Ethernet-Karte Hänger

Re: Ethernet-Karte Hänger

Re: Ethernet-Karte Hänger

Re: Ethernet-Karte Hänger