Atmega1280 Webserver stürzt ab

[Tom (Gast)]

Hallo,

ich habe einen Atmega1280 Webserver und betreibe diesen mit dem Stack 
von Ulrich Radig in einer für meine Zwecke leicht erweiterten Version.

Funktioniert auch alles soweit blendend, der Webserver hängt im lokalen 
Lan und ist blitzschnell ansprechbar.

Versorgt wird die Schaltung (die sich in meinem PC befindet) über die 5v 
standby Leitung eines ATX Netzteils (der zugehörige PC läuft die ganze 
Zeit, es kommt also nicht irgendwie durch das ein und ausschalten des 
PCs). Auf der Platine sitzt direkt am Controller ein 100nf und ein 10uF 
keramikkondensator, direkt am Eingang der Spannung ein 22uF Elko.

Nach völlig zufälligen 2 - 8 Tagen nun ist er aber einfach nichtmehr 
ansprechbar (keine Reaktion auf Ping) und führt selbst einfachste 
Aktionen (Pollen eines Eingangs und einschalten einer LED) nichtmehr 
aus.

Nach einem Neustart geht das ganze dann von vorne los, läuft wieder ein 
paar Tage und ist dann einfach weg.


Die Software hab ich soweit schon "stressgetestet", also mit ping -f 
geflooded, so schnell wie möglich überall rumgedrückt im Webserver etc. 
Zwischenzeitlich bis zum Absturz wird dann tagelang nicht wirklich was 
am Controller gemacht


Wie würdet ihr bei sowas vorgehen? Nachdem es immer tagelang dauert bis 
zum nächsten Absturz zieht sich das ganze ewig...


Ich hab jetzt bereits das board noch zweimal zusammengelötet, um 
irgendwelche Lötprobleme auszuschließen, der Fehler tritt bei allen drei 
auf.

Was mir jetzt noch einfällt:

- BOD detection aktivieren und so scharf wie möglich einstellen?

- 300uF Elko am Eingang reinhängen (normal sollte aber das ATX Netzteil 
doch schon riesige Töpfe haben?)

- Statt 16mhz mal 4mhz oder 1mhz als quarz einlöten?

- einen JTAG Adapter kaufen, könnte ich damit sehen was der controller 
grade macht und denkt wenn er sich tot stellt?



Nachdem jeder Versuch immer ne Woche "warten auf Absturz" heißt, wäre 
ich für Hilfe sehr dankbar!


Euer Tom

[Peter (Gast)]

als Workaround könnte man ja den Watchdog verwenden.
(ich weiss den Fehler finden währe schöner)

Hast du mal eine freier Timer zum Blinken einer LED verwendet? Selbst 
wenn sich das Programm verhängt sollte der Timer weiter laufen.

[Peter D. (peda)]

Tom wrote:
> Nach völlig zufälligen 2 - 8 Tagen nun ist er aber einfach nichtmehr
> ansprechbar (keine Reaktion auf Ping) und führt selbst einfachste
> Aktionen (Pollen eines Eingangs und einschalten einer LED) nichtmehr
> aus.


Du mußt versuchen rauszukriegen, wo er hängt.

Gehen Interrupts noch (Blink-LED)?
Geht eine der UARTs noch?
Du mußt Funktionen einbauen, um ihm auf den Zahn zu fühlen.

Geht garnichts, dann nach einem Reset nen RAM-Dump über die UART 
ausgeben. Allerdings geht durch das Reset der Stackpointer verloren, die 
Analyse wird etwas schwierig.

Besser, wenn noch ein Interrupt geht, dann dort RAM-Dump und wichtige 
IO-Register auslesen. Am besten in Assembler, um keine Register oder 
SRAM zu zerstören.


Allgemein klingt das nach Race-Condition, Atomicity-Problem oder 
Stacküberlauf.


Peter

[Frank aus Köln (Gast)]

Hallo Tom,

ich denke das Du bei Dir einen ENC28J60 benutzt, geht leider aus Deinem 
post nicht hervor.
Ich hatte auch immer wieder das Problem mit diversen abstürzen meiner 
Software, aber leider traten die so selten auf das man nicht wirklich 
etwas mitloggen konnte. Irgenwann vor ein paar Monaten löste sich mein 
Switch in wohlgefallen auf und ich musste auf so einen alten 24Port Hub 
umsteigen.
Läuft mit normalen PCs wunderbar, aber der ENC Webserver schmierte immer 
wieder nach ein paar Minuten ab. Da ich in meinem Programm noch einen 
Debugger mitlaufen hatte, konnte ich allerdings feststellen das der 
Fehler irgendwo vom ENC herkommen musste, der rest der Software lief 
nämlich wunderbar weiter. Der ENC Treiber setzt auf dem Code von Pascal 
Stang aus dem Jahr 2005 auf. Also habe ich mir die Erratas von Microchip 
nochmal reingezogen und festgestellt das mein ENC fast immer beim Senden 
hängen blieb. Also habe ich mir mal den Transmit Staus vector mal 
genauer angeschaut und gesehen das immer wieder das Late Collision Bit 
gesetzt war, wie auch TXRIF und TXABRT. Also habe ich mir mal den 
Originalen Microchip TCPIP Stack mal genauer angeschaut und die 
Senderoutine Zeile für Zeile auseinandergepflückt und so umgebaut das es 
bei mir passt. Und siehe da jetzt sendets. Aber zwischenzeitlich hing er 
sich auch beim Receive immer wieder auf. Die Erratas für die Receive 
routinen waren soweit implementiert und trotzdem hing er wieder. Also 
habe ich mir auch die Receiveroutine auseinadergerupft und dan sties ich 
auf diese Codezeile:

// Validate the data returned from the ENC28J60.  Random data corruption, 
// such as if a single SPI bit error occurs while communicating or a 
// momentary power glitch could cause this to occur in rare circumstances.
if(header.NextPacketPointer > RXSTOP || ((BYTE_VAL*)  (&header.NextPacketPointer))->bits.b0 ||
     header.StatusVector.bits.Zero ||
     header.StatusVector.bits.CRCError ||
     header.StatusVector.bits.ByteCount > 1518u ||
     !header.StatusVector.bits.ReceiveOk)
  {
    Reset();
  }

Diese stück Code ist der absolute Hammer, bedeutet abgekürzt, geht 
irgendwas beim receive schief, dann resette den ENC.
Also eingebaut und jetzt läufts, selbst an dem murksigen Hub.
Ich habe mir hier schon so einige ENC webserver sourcen angeschaut, aber 
das habe ich bis jetzt noch bei keinem eingebaut gesehen.

Vielleicht hilft das ja dem ein oder anderen weiter.

Gruß aus Köln

Frank

[Dirk B. (sharandac)]

Autsch ... ich such bei mir auch schon eine weile nach einen 
sporadischen Fehler. Ich kann Gigabyteweise einen MP3-Stream empfangen 
mit den ENC28j60, aber irgendwann geht halt nix mehr per Netzwerk. Des 
Rest lief dann halt noch was so an Programmen da war. Ich werde das dann 
mal einbauen, vielleicht hilft es ja bei mir. THX nochmal.

CAY Dirk

[Frank aus Köln (Gast)]

Hallo Tom und Dirk,

ich wollte mal nachhören ob ihr den Microchip workaround mal ausprobiert
habt und ob es eine verbesserung gebracht hat.

Gruß aus Köln

Frank

[Andreas V. (tico)]

Hallo Frank,
ich finde Deine Erkenntnisse zum ENC28J60 sehr interessant. Kannst Du 
Deinen verbesserten Treiber hier veröffentlichen?
Betreibst Du den ENC im Full- oder Half-Duplex Modus?

Gruss
Andreas

[Frank aus Köln (Gast)]

Hallo Andreas,

im Anhang meine derzeitige Arbeitsversion, so sieht sie im Moment auch 
noch aus. :)
Grundsätzlich ist das immer noch die ursprüngliche Version von Pascal 
Stang aber die Funktionen enc28j60PacketSend und enc28j60PacketReceive 
wurden um den Mircochip Workaround erweitert. In der enc28j60PacketSend 
wurde das Transmit Status Word ausgewertet und entsprechend darauf 
reagiert und in der
enc28j60PacketReceive wird der ENC im absturzfall "resettet" so wie 
Microchip das in ihrem Stack auch machen. Seitdem läuft der Webserver 
bei mir auch über Monate stabil. Ich würde mich über ein kurzes Feedback 
freuen, ob es bei anderen auch geholfen hat oder ob man noch weiter nach 
irgendwelchen ENC macken suchen muss.

Gruß aus Köln

Frank

[Frank aus Köln (Gast)]

Hier noch die .h datei.

Ich arbeite übrigens mit Half-Duplex.

Gruß

Frank

[Andreas V. (tico)]

Frank aus Köln wrote:
> Ich arbeite übrigens mit Half-Duplex.

Aha, ich verwende Vollduplex, weil man beim Lesen der Erratas von 
Microchip den Eindruck gewinnt, dass die Kollisionen bei Halbduplex dem 
Chip eine ganze Reihe von Problemen bereiten. Einen Langzeittest habe 
ich damit allerdings bis jetzt noch nicht gemacht, das werde ich mal 
nachholen.

Ansonsten ist mir bei Deinem Code (Danke dafür!) nur die Zeile

while(!(enc28j60Read(ESTAT) & ESTAT_CLKRDY));

 in der Funktion enc28j60Init() aufgefallen. Laut Errata ist 
ESTAT_CLKRDY unzuverlässig, ich habe die komplette Zeile deshalb durch

for (uint8_t i=0;i<30;i++) _delay_ms(35);

 ersetzt. Das dauert zwar länger, funktioniert nach meiner Beobachtung 
aber sehr gut.

Gruss
Andreas