Ich arbeite daran, ein Startproblem mit einer Atmel AT91SAM9G20-Karte zu beheben. In den ersten 700 ms läuft alles gut. Es scheint, dass der Prozessor etwa 700 ms nach dem Zurücksetzen einfriert. Merkwürdig ist, dass die CPU die Reset-Leitung steuert, nachdem ich die Reset-Taste losgelassen habe.
Hier ist eine Scope-Aufnahme, die zeigt, was los ist. Die gelbe Kurve ist die Rücksetzlinie. Das erste Eintauchen ist die Zeit, in der ich die Reset-Taste gedrückt halte. Der zweite Einbruch wird, glaube ich, von der CPU erzeugt.
Die blaue Kurve sind serielle Daten, die aus der CPU kommen. Die ersten beiden Bursts stammen vom ersten Bootloader. Der dritte Burst ist der U-Boot-Start. Die CPU sendet keine Zeichen mehr, wenn der dritte blaue Burst endet.
Wenn ich die Traces richtig interpretiere, bedeutet dies, dass die Reset-Leitung fast genau für die Zeit niedrig ist, in der der Prozessor U-Boot von NAND-Flash lädt.
Ich habe ein paar Fragen:
- Ist diese Art des CPU-gesteuerten Zurücksetzens normal?
- Irgendwelche Vorschläge, wie man das debuggt?
Noch ein paar Details: Ich sollte hinzufügen, dass ich mir die Stromschienen angesehen habe und sie sauber aussehen. Das folgende Verhalten ist reproduzierbar. Ich kann die Länge des anfänglichen Reset-Eintauchens (in Gelb) um einige Sekunden variieren, und der Rest des Verhaltens geschieht auf die gleiche Weise. Wenn ich das JTAG-Kabel anschließe, ändert sich das Verhalten - manchmal startet es, manchmal nicht, aber nach einigen Sekunden übernimmt JTAG und der Prozessor wird angehalten.
Unter JTAG kann ich erfolgreich booten. So sieht ein erfolgreicher JTAG-gesteuerter Start aus:
Beachten Sie, dass die Zeitskala unterschiedlich ist und ich nicht die Reset-Taste drücke - sie wird softwaregesteuert. Der gleiche Reset-Dip tritt auf. In beiden Fällen beträgt die Länge ca. 500 ms.
Update (immer noch verblüfft)
Auf Anregung von Mr. Taffeys Vorschlag unten habe ich den Watchdog-Timer und den Reset-Controller genauer untersucht. Der Watchdog-Timer wird tatsächlich vom ersten Bootloader deaktiviert. Ich bin mir ziemlich sicher, dass Code ausgeführt wird, da er auftritt, bevor Text über die serielle Debug-Schnittstelle gesendet wird, und ich den Text erfolgreich lesen kann.
Bei der Lektüre über die Details des Reset - Controller, erfuhr ich , dass der Prozessor soll zur Greifersteuerung des Reset - Pin und ziehen Sie sie niedrig für einen kurzen Zeitraum. Dies soll sicherstellen, dass andere Hardware auf der Karte, die dieselbe Leitung hört, einen ausreichend langen Reset erhält. Beim Durchsuchen des U-Bootes stellte ich fest, dass die Dauer des Zurücksetzens mithilfe des ERSTL-Felds auf 0x0D festgelegt wurde:
at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
(AT91_RSTC_ERSTL & (0x0D << 8)) |
AT91_RSTC_URSTEN);
Das Datenblatt erklärt, dass die Dauer auf 2 ^ (ERSTL + 1) langsame Taktperioden eingestellt ist.
Die Rücksetzdauer beträgt ungefähr 500 ms, der langsame Taktkristall beträgt 32768 Hz, und Google teilt mir mit, dass log (0,500 * 32768) / log (2) = 14 und 0x0D + 1 = 14 ist. Dies alles ist also sinnvoll.
Ich denke, das eigentliche Problem könnte ein Absturz des U-Bootes sein. Die Tatsache, dass dies unmittelbar nach diesem Zurücksetzen geschieht, ist wahrscheinlich irrelevant. Was verwirrend ist, ist, warum U-Boot nur abstürzt, wenn JTAG nicht verbunden ist.
Zweites Update
Ich weiß immer noch nicht, was schief geht oder warum JTAG es anders macht, aber ich denke, ich habe eine Problemumgehung gefunden. Es sieht so aus, als würde der U-Boot-Absturz auf irgendeine Weise durch den NAND-Blitz auf der Platine verursacht. Zufällig verwendet die nächste Revision der Karte, die erst kürzlich eingetroffen ist, eine microSD-Karte anstelle von NAND-Flash für die nichtflüchtige Massenspeicherung (nun, es gibt NAND-Flash in der microSD-Karte, aber Sie sehen den Punkt).
Meine "Lösung" besteht darin, die nächste Version des Boards zu verwenden. U-Boot stürzt ebenfalls ab, aber aus bekannten Gründen - es ist so konfiguriert, dass es nach einem NAND-Flash sucht, den es nicht finden kann. Daher stirbt es einen feurigen Tod.
Also, Problem "gelöst". (Erwarten Sie in Kürze eine weitere Frage wie "Wie lasse ich AT91Bootstrap U-Boot von einem seriellen Flash laden?" Oder "Wie kann U-Boot mit einer microSD-Karte funktionieren?" Oder "Warum mache ich das?" )
Ich denke, das grüne Häkchen geht an Joby, um zu bemerken, dass die Rücksetzleitung vom Mikro gesteuert werden kann, obwohl sie sich auf lange Sicht als irrelevant herausgestellt hat. Vielen Dank für die Hilfe an euch alle. Ich schätze es.
Drittes Update (ca. eine Woche später)
Ich habe in letzter Zeit hauptsächlich an anderen Dingen gearbeitet, aber ich habe herausgefunden, wo das Problem letztendlich lag. Mein letztes Rätsel habe ich oben zusammengefasst als:
Was verwirrend ist, ist, warum U-Boot nur abstürzt, wenn JTAG nicht verbunden ist.
Tatsächlich stellte sich heraus, dass ich den U-Boot-Fehler beim Senden von Zeichen über die serielle Debug-Schnittstelle für einen U-Boot-Absturz hielt. Ich verstehe die Details immer noch nicht, aber ich habe festgestellt, dass es nicht JTAG ist, das U-Boot zum Funktionieren bringt - es ist eine gemeinsame Basis zwischen meiner Schaltung und dem USB-Host meines PCs, den JTAG bereitgestellt hat, weil es durchläuft den USB-Anschluss. Tatsächlich funktionierte der U-Boot die ganze Zeit einwandfrei, aber wenn JTAG getrennt wurde, funktionierte der von mir mit einem Steckbrett versehene RS-232-zu-USB-Level-Shifter nicht mehr, die serielle Schnittstelle fiel aus und ich ging davon aus, dass dies der Fall war tot. In Wirklichkeit stellte ich fest, dass ich beispielsweise immer noch Ping-Befehle eingeben und die erzeugten ICMP-Pakete sehen konnte, obwohl meine Zeichen nicht auf dem Terminal wiedergegeben wurden.
Ich verstehe nicht genau, was falsch gelaufen ist, aber es ist mir egal - ich kann leicht einen anderen Weg finden, um die serielle Schnittstelle zu lesen, und kurzfristig kann ich einfach die Verbindung zur USB-Masse mit einem Kabel herstellen .
Vielen Dank für die Hilfe.