Hallo Experten ! Wir haben ein Problem beim Manuellen-Reset des XC 167CI-32F40F BB : Lösen wir einen Reset manuell aus, kommt es gelegentlich vor, daß der Prozessor nicht wieder anläuft. RSTIN ist <LOW> für mehr als 100 ms und geht auch richtung wieder auf <HIGH>. Falls der Chip nicht anläuft, ist auch der RSTOUT auf <LOW>, was bedeutet, daß er sich weiterhin im RESET befindet, obwohl RSTIN nicht mehr aktiv ist. Auch erneuetes Reseten bringt nichts mehr; es muß die Spannung ausgeschaltet werden. Wir wissen keinen Rat mehr !
Man könnte die Lage besser beurteilen, wenn man ein Schaltbild vom Prozessor und seiner Peripherie hätte (Resetbeschaltung , Oszillator, Starten aus dem internen oder externen Flash....)! Ist es wirklich sicher, daß er nicht anläuft oder kann es sein, daß er sich irgendwo umherteibt? JTAG-Debugger oder Logic Analyzer verfügbar?
Der Oszillator läuft (8MHz,XTAL1/XTAL2) aber am CLKOUT ist im Fehlerfall kein Signal mehr. Vor dem Reset sind dort die 40 MHz der PLL zu sehen. Zusatzinfo: Die Anwendung besteht eigentlich aus 2 Teilen: Einen Loader im internen Flash und die eigentliche Aplikation im externen Flash. Es wird beim Reset immer der Loader gestartet, der prüft im ext. Flash ob die Aplikation vorhanden ist und startet diese. Starten wir die Aplikation nicht, verbleiben also im Loader, tritt der Fehler nie auf. Übrigens : Der Fehler tritt nur beim Hardwarereset(Warmstart) auf, eine Reset verursacht durch den Watchdog, Trap0 oder Kaltstart funktioniert immer.
Noch was! Im Fehlerfall funktioniert auch der angeschlossene JTAG-Debugger nicht mehr! Schaltbild folgt etwas später !
Wie ist denn der Stand der Entwicklung? Hat das vorher schonmal funktioniert und jetzt nicht mehr? Hört sich irgendwie nach Iniproblemen an.
Angehängte Dateien:
-
XC167_ResetProblem.JPG
130 KB
Hier das Schaltbild. Die frühere Version bestand aus dem C165-Prozessor. Die funktionierte prima. Die neue Version mit dem XC167 hat sich noch die anders verhalten. Wurde aber auf den ULINK-Debugger von Keil geschoben, wir dachten, daß der Debugger den Abflug macht. Das Problem ist aber unabhängig vom Debugger.
In Teilen des RAMs stehen noch Daten (Erkennungsstring Loader <--> Applikation?).
Nein, das RAM ist dabei unwichtig, die Kennung, daß eine Aplikation vorhanden ist, steht im Flash. Noch mal zur Erinnerung: Der Prozessor sthet tatsächlich noch im Reset. (RSTOUT = LOW) Mir ist es ein Rätsel, woher der Prozessor bei einem Reset weiß, daß vorher die Aplikation im ext. Flash gestartet war.
> Der Prozessor sthet tatsächlich noch im Reset. (RSTOUT = LOW)
Es erfolgte noch kein EINIT Befehl, der Loader macht das für Dich. Dein
Flash Startup Code wohl nicht.
>Übrigens : Der Fehler tritt nur beim Hardwarereset(Warmstart) auf, eine >Reset verursacht durch den Watchdog, Trap0 oder Kaltstart funktioniert >immer. Wie wird denn der Hardwarereset ausgelöst? Dabei befindet sich der XC167 im externen Flash, wenn ich das richtig verstanden habe. Wo steht die Interrupttabelle zu diesem Zeitpunkt? Es ist darauf zu achten, daß der Vector Segment Pointer (VECSEG) richtig steht! Den gab es beim C165 ja noch nicht. Würde mich interessieren, was nun die Ursache war....
Hallo, Wo kommen deine 2,5V her? Das finde ich in deinem Schaltbild nicht. Da hängt ein Kondensator zwischen 2,5V und GND, damit verletzt du beim Drück auf einen Resettaster die Bedingung das VDDI mindestens 1V größer als VDDP sein muss. Schaffe die Möglichkeit das sich dieser Kondensator beim HW-Reset entläd. Sollte der RSTOUT beim EINIT umschalten oder schon beim Internen Resetzyklus, je nach dem wie es die Konfiguration will.
Oh da ist ein Fehler in meinem Post: Es muss heißen "das VDDP mindestens 1V größer als VDDI sein muss"
Hallo Leidensgenossen, ja, auch ich kenne dieses Reset-Problem und habe auch schon viel Zeit mit der Ursachensuche verbracht. Das Problem ist sehr hartnäckig: So habe ich gedacht, daß es mit dem internen PLL-Oszillator zusammenhängt und habe den externe Beschaltung des Quarz verfeinert. Dann habe ich das Einschalten der Core-Spannung zur Peripherie-Spannung verzögert. Dann habe ich die StartUp-Konfiguration (div. Widerstände) niederohmiger gemacht. - Alles ohne nennenswerten Erfolg. Irgendwann geht einem auch die Phantasie aus. Schließlich habe ich eine Support-Anfrage an Infineon gerichtet und warte bis heute auf eine Antwort. Was mich weitergebracht hat, war der Versuch die Zustände verschiedener Leitungen beim Einschalten zu messen. Als ich mit einer Meßspitze im JTAG-Stecker herumfingerte, war das Problem plötzlich weg! Also, kurzum, der _TMRST ist im "Insider's Guide" nicht beschaltet. Ich meinte klüger zu sein und habe ein Pull-up verbaut. - Das hat auch die meiste Zeit gut funktioniert, aber eben nicht bei allen Platinen. Dann habe ich den Pull-up entfernt, aber unbeschaltet ist der Ärger immernoch da. Dann habe ich, entgegen jeder Logik, den _TMRST mit einem Pull-Down versehen und ... ja, das war's. ... bis heute. Jetzt tritt das Problem plötzlich wieder auf. Weniger stark, aber in einer Weise die nicht auslieferbar ist. Das sind meine Erfahrungen, wer weiß mehr?
Ich kann maestro nur Recht geben! Auf einigen Infineon Boards hat der _TMRST Pulldown 10k. Pullup am NMI ist natürlich auch ganz wichtig! siehe Kapitel 1.3 in http://www.keil.com/dd/docs/datashts/infineon/xc164cm-cs_delta.pdf
Hallo! Der Thread ist zwar schon älter, aber wir beobachten dasselbe Verhalten momentan mit einem XC2287 Controller. Nach einem Reset startet der µC nicht mehr korrekt, das geflashte Programm wird nicht geladen. Es wurden schon große Anstrengungen unternommen um das Problem einzugrenzen und zu beheben, jedoch erfolgreich. Deswegen: Gibts es irgendwelche Erkenntnisse aus dieser Diskussion? Hat jemand die Reset-Probleme bei den Xc164/XC167 erfolgreich gelöst und könnte mir sagen auf welche Art und Weise?
Ich würde noch folgende Lösungsmöglichkeiten in die Runde werfen: -> Ist die PLL-Konfiguration richtig? Hier wird im Datenblatt auch zwischen Quarz und Oszillator unterschiedlich konfiguriert. Auf jeden Fall die gesamte PLL-Konfigurationskette durchprüfen, ob alles stimmt (alle MUL/DIVs/Ranges und was noch so alles zu konfigurieren ist). -> Benutzt Ihr alle Quarze zur Takterzeugung? Die Anschwingreserve könnte nicht ausreichend sein. Mag sein, dass der Quarz nicht schnell genug anschwingt. Quarze vermessen lassen kann man beim Quarzhersteller, wenn man hier eine gute "Beziehung" hat. Abhilfe: Mit einem Oszillator probieren. Ich betreibe einen XC167CI mit einem 16MHz-Oszillator, ohne diesen Fehler jemals gehabt zu haben. -> Wie schon beschrieben, den NMI mit 10k gegen 5V ziehen. -> Den Pin für die Auswahl Start internes/externes Flash mittels PullUp(10k)-/PullDown(0R?)-Widerstand festlegen. Pin 20.5 mit 10k gegen 5V, wenn Du aus dem internen Flash starten möchtest. -> Ist der MAX707 in der genutzen Variante geeignet? Spannungspegel der Überwachung? Reset-Länge? Ich nutze eine STM1811-Variante. Im Allgemeinen ist der XC167 ein sehr "anwenderfreundlicher" µC. Es können aber zahlreiche Fehler sein, die zu dem beschriebenen Fehler führen. Wir müssen aber erst mal die Basics klären.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.