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
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.
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
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
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
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 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
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
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
1 | while(!(enc28j60Read(ESTAT) & ESTAT_CLKRDY)); |
in der Funktion enc28j60Init() aufgefallen. Laut Errata ist ESTAT_CLKRDY unzuverlässig, ich habe die komplette Zeile deshalb durch
1 | 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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.