Atmega1280 Webserver stürzt ab

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.

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:

1

// Validate the data returned from the ENC28J60.  Random data corruption, 

2

// such as if a single SPI bit error occurs while communicating or a 

3

// momentary power glitch could cause this to occur in rare circumstances.

4

if(header.NextPacketPointer > RXSTOP || ((BYTE_VAL*)  (&header.NextPacketPointer))->bits.b0 ||

5

     header.StatusVector.bits.Zero ||

6

     header.StatusVector.bits.CRCError ||

7

     header.StatusVector.bits.ByteCount > 1518u ||

8

     !header.StatusVector.bits.ReceiveOk)

9

  {

10

    Reset();

11

  }

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

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

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

Hier noch die .h datei.

Ich arbeite übrigens mit Half-Duplex.

Gruß

Frank