Hallo,
kurz vorab, ich bin blutigen Anfänger in Sachen XC167 und µVision(neuer
Arbeitgeber) und eingentlich gar kein Entwickler.
Wir haben hier einige Module aus eigener Fertigung, ähnlich denen von
Phycore, die nicht richtig funktionieren und ich soll klären warum.
Wir haben eine eigene Testsoftware, die aufgespielt wird und diverse
interne und externe Komponenten testet. Nur auf einem Modul wird diese
Software nicht sauber gestartet.
Wenn ich im Debug-Modus den Assemblercode durchsteppe, geht gleich beim
2 Befehl was schief und ich kann leider nicht nachvollziehen warum.
Der Assbblercode sieht so aus
00000000 FA00B000 JMPS 0x0000B0
.
.
000000B0 A57AA5B5 DISWDT ???
Nach Ausführen des DISWDT springt er komischerweise zur Adresse 0000028
und ein paar Zeile später läuft er ins Nirvana. Warum das?
Bei einem anderen, fehlerfreien Modul stehen keine 3 Fragezeichen
dahinter und es geht ganz normal in der nächsten Zeile weiter.
00000000 FA00B000 JMPS 0x0000B0
000000B0 A57AA5B5 DISWDT
000000B4 E60C0700 MOV CPUCON1,#0x000750
.....usw.......
Was kann denn beim Watchdogtimer ausschalten so schief gehen oder geht
da schon vorher was schief?
Mir konnte bisher keiner sagen was diese 3 Fragezeichen da zu bedeuten
haben? Gibt es noch irgendwo Einstellungen im Dissembler Fenster um
detailliertere Infos zu bekommen?
Ich hoffe ihr könnt mir ein wenig auf die Sprünge helfen.
Gruß Jan
Ich kenn mich mit diesem Controller nicht aus, aber ein paar Gedanken habe ich: Adresse 0x28 sieht nach Vektortabelle aus. Welcher Interrupt steht üblicherweise an dieser Adresse? WDT? Ist dafür eine Interruptroutine hinterlegt? Wenn nicht, dann läuft der Prozessor ins Nirvana :-) Offensichtlich lässt sich der Watchdogtimer nicht ausschalten oder er ist hardwaremässig aktiviert, so dass du mit dem Debugger scheiterst (und eventuell auch der Softwarebefehl DISWDT nicht zum Zuge kommt). Versuche deinen Debugger so einzustellen, dass du erst an Adresse 0xB4 anhälst, dann ist der WDT eventuell aus.
Hallo, da mit dem Interruptvector war ein guter Tip. Dort war auch irgendeine Routine vorhanden in der es dann aber ins Nirvana ging. Ich kanns jetzt leider nichtmehr nachvollziehen, denn nunn funktioniert garnichts mehr. Ich kann das externe Flash (29F160) löschen und flashen, aber wenn ich dann den Debugger starte, steht an jeder Adresse immer der gleiche Befehl drin. 00000000 FFFF BSET R15.15 00000002 FFFF BSET R15.15 00000004 FFFF BSET R15.15 00000006 FFFF BSET R15.15 Kann der Controller das Flash nicht mehr auslesen oder warum steht da immer FFFF ? Gruß Jan
Unprogrammiertes Flash enthält 0xFF als Wert. Soll heißen: Das Flash scheint leer zu sein. Kannst du die Anbindung und dir Programmierung des Flashs testen? Ich würde als erstes versuchen den Flash wieder auszulesen, danach mir die Busanbindung genauer angucken.
Hi, das Flashen mache ich mit µVision. Ein anderes Tool das auch das externe Flash beschreiben kann haben wir hier nicht. Was das KEIL µVision-Tool alles gegenprüft (verify oder sowas) kann ich nicht sagen, auf jeden Fall gibts keine Option zum Auslesen, nur "Erase" und "Download" Wenn jemand ein kostenloses Tool kennt, das auch das externe Flash bearbeiten kann, immer her damit. Gruß Jan
Jan schrieb: > Hi, > > das Flashen mache ich mit µVision. > Ein anderes Tool das auch das externe Flash beschreiben kann haben wir > hier nicht. Was das KEIL µVision-Tool alles gegenprüft (verify oder > sowas) kann ich nicht sagen, auf jeden Fall gibts keine Option zum > Auslesen, nur "Erase" und "Download" > > Wenn jemand ein kostenloses Tool kennt, das auch das externe Flash > bearbeiten kann, immer her damit. > > > Gruß Jan Verstehe ich das richtig, der Controller startet vom externen Flash? Das könnte dann natürlich auch ein Hardwareproblem sein, z.B. ein "Bitklemmer" wenn er aus dem Flash eine Adresse liest bzw. eine Adresse anlegt. Was steht denn im Quellcode an der Adresse 0x28? Ein flüchtiges Durchlesen des Datenblattes hat mir gesagt, dass die Vektortabellen weiter "oben" liegen. Wie heißt denn der Controllertyp genau?
Ja, der Controller holt sich die Software aus dem externen Flash. Die Adress- und Datenleitung scheinen aber i.O. zu sein, denn das Flashen läuft über den Controller. JTAG (Wiggler) -> Controller -> Flash SAF-XC167CI-32F Gruß Jan
Ich hab nochmal was anderes versucht. Per Jumper kann ich umstellen ob vom internen oder externen Flash gebootet werden soll. Dann hab ich ne alte Version der Testsoftware raufgespielt, welche intern arbeitet und siehe da die alte Testsoftware läuft an (wird per LED signalisiert). Ich kann zwar nichts debuggen weil ich das µVision Projekt nicht habe, aber der Controller läuft wenigstens. Ich glaub ich werd mal das Flash tauschen. Gruß Jan
Teste erst die Buskonfiguration! Vllt. fehlt da nur ein Pulldownwiderstand.
Soo, nun hab ich endlich den "verify" Haken im Menu vom JTAG Adapter gefunden und nun wird auch ein Check durchgeführt. Vorher hat er wohl nur auf gut Glück was reingeschrieben. Ergebnis -> Fehler bereits an der ersten Adresse Soll FAh, IST FFh Das erklärt natürlich warum er nicht über extern startet. Kurios ist nur das bis gestern immer noch ein paar Sachen reinschreiben konnte, denn der Assemblercode war ja beim Debuggen zusehen und dann gestern Abend und heute garnicht mehr geht. Ideen? Gruß Jan
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.