Hallo zusammen, ich nutze Yagarto (OpenOCD, arm-elf-gcc, arm-elf-gdb, Eclipse) mit einem Amontec JTAGKey, das ganze derzeit auf einem Olimex LPC-P2129 EvalBoard (LPC2129). Installiert habe ich die neuesten Packages von Yagarto, die Amontec-Software habe ich nicht installiert (ist ja das gleiche, nur eben älter als was in Yagarto zu finden ist). Funktioniert soweit auch relativ gut, nur sehe ich öfters mal einen Absturz beim Debuggen. Das ganze passiert wenn das zu debuggende Programm über längere Zeit läuft, und zwar sowohl wenn ich es "frei" laufen lasse, als auch wenn ich im Single-Step-Modus arbeite (dann immer, wenn man über einen größeren Block steppen will, z.B. eine while-Schleife). In Eclipse erscheint die Meldung "Execution is suspended because of an error" mit Detailmeldung "Remote Communication Error: Bad File Descriptor". Alle zur OpenOCD-Sitzung gehörenden Meldungen sind so: E:\Eclipse Workspaces\LPC2129_Test>openocd-ftd2xx -f .\prj\lpc2129_jtagkey.cfg Info: openocd.c:84 main(): Open On-Chip Debugger (2006-01-26 13:30 CET) Warning: arm7_9_common.c:683 arm7_9_assert_reset(): srst resets test logic, too Warning: arm7_9_common.c:842 arm7_9_halt(): target was already halted Info: server.c:67 add_connection(): accepted 'gdb' connection from 0 Warning: arm7_9_common.c:683 arm7_9_assert_reset(): srst resets test logic, too Error: ft2232.c:201 ft2232_read(): FT_Read returned: 4 Error: ft2232.c:365 ft2232_send_and_recv(): couldn't read from FT2232 Also irgendwie scheint OpenOCD auszusteigen, was wiederum zu einem Fehler in Eclipse führt - der File Handle geht dann natürlich verloren. Den JTAGKEy muss ich auch aus- und neu einstecken, um ihn wieder zum Leben zu erwecken. Hat irgendjemand eine Ahnung, woran das liegen könnte? Ist es OpenOCD oder sogar ein Problem des Amontec-Treibers (=FTDI-Treiber mit DLL)? Was kann ich tun? Ab und an kommt auch eine Fehlermeldung, dass man an Adresse 0xFFFFFFFF nichts lesen könne, aber da soll es ja auch gar nicht lesen laut meiner Target-Konfiguration. Meine Konfigurations-Datei für OpenOCD entspricht eigentlich dem, was auf der Yagarto-Homepage für den LPC2194 eingestellt ist, nur habe ich das Mapping des Flash angepasst. Für den GDB nutze ich auch das Script aus dem Yagarto-Beispiel (eclipse_ram.gdb). Weitere Fragen: - Für OpenOCD gibt man in der Flash-Config u.a. die Clock Frequency in kHz an (flash bank lpc2000 0x0 0x40000 0 0 lpc2000_v1 0 14746 calc_checksum). Kann das auch eine reele Zahl sein? Im konkreten Fall ist ja ein 14.475.600-Hz-Quarz auf dem Board, das habe ich jetzt mal mit 14746 angenähert. Lieber wäre mir 14745.6 anzugeben, aber es auszuprobieren wollte ich nicht einfach so. Wieso steht dort in den anderen Skripten immer 14765? Haben nicht alle Olimex-Boards einen 14.745.600-Quarz? - Spielt die Reihenfolge der Befehle im OpenOCD-Config-File eine Rolle (ausser natürlich die Reihenfolge der Targets zu definieren). Konkret frage ich mich, wieso in den meisten Config_Files immer "daemon_startup reset" relativ weit unten kommt, obwohl es "logisch" doch zur Daemon-Cfg gehört. Ich habe es also nach oben verschoben (Dritte Zeile). Scheint zu tun... - Wie stabil läuft bei Euch die gleiche Ausstattung (Yagarto + JTAGKey)? Ansonsten bin ich sehr begeistert, was ein paar clevere Leute in Ihrer Freizeit auf die Beine stellen können!
Ich habe ein Olime OCD USB JTAG (...) dongle, aber auf Linux. Es läuft, aber ich kann nicht die externen Flash oder SRAM lesen/schreiber (habe noch nicht warum gefunden :-( ). Hast du shon die Treiber für FT2232 installiert ? Die OpenOCD config ist ein bisschen schlecht, der Name und Typ müssen stimmen !, oder wird es die dongle nicht finden ! (auf linux, du kannst die Kommando lsusb benuzen und die richtige name der dongle finden, auf windoof, such etwas).
Ja klar, der Treiber ist installiert. Ich kann ja auch schon debuggen, nur leider gibt es bei längerer Laufzeit ein Problem. Auch, wenn ich über einen Block mit "Step Over" laufen will, tritt das Problem auf. Simple Einzeilen-Befehle (z. B. a = b + 3;) sind meist kein Problem, allerdings kann ich auch dort nur eine begrenzte Dauer debuggen. Irgendwann verabscheidet sich eben alles. Übrigens debugge ich im RAM. Das hat glaube ich als Info noch gefehlt.
Ich habe nicht lange es benutzt, die ganze Dinge, weil die extern bus fuktioniert nicht, weiss es nicht warum, ich muss noch die Datenblättern nochmal lesen (ich habe ein lpc-l2294 Karte), aber bei mir es gibt ein Paar mehr probleme aber haben nicht (glaube ich) zu tun mit den verbindung zwischen die pc und die dongle. Ich habe ein LCD treiber debugged problemlos (aber hat von externen bus nicht gut gelesen). Ich screibe z.B. mwb 0x83000001 0x94 So es wird ein T6963 initilizieren, und wenn ich lese: mdb 0x83000001 00x83000001 0x94 So etwas klapp nicht, vielleicht bei openOCD. Du kannst auch die geschwindigkeit von dem JTAG langsamer machen, vielleich es hilft ! (ich kann auch es probieren). jtag_speed 2 in openocd.cfg, bei 2 ich kann debuggen aber habe diese probleme mit ext Speicher, höhere Zahlen machen es langsamer. Vielleciht es hift. Ale
Danke für den Tipp! Allerdings habe ich auch dei JTAG-Speed bereits auf 2 gesetzt (soweit ich weiss, ist das wohl der Teiler, durch den die maximale JTAG-Geschwindigkeit geteilt wird: speed = max_speed / (jtag_speed + 1) Leider finde ich in der OpenOCD-Doku dazu keine weiteren Angaben, o.g. Formel habe ich aus den Aussagen im Forum mir zusammengereimt. Ob's stimmt, keine Ahnung! Bei mir wäre das also 6 / 3 = grob 2 MHz. Irgendwo stand auch mal, dass die JTAG-Speed max. 1/6 der Chipgeschwindigkeit sein soll. Bei mir also max. 14.746 MHz / 6 = grob 2.5 MHz. Damit müsste das stimmen...
Jetzt ist es mal wieder so abgestürzt (Meldung von OpenOCD): Warning: arm7_9_common.c:1798 arm7_9_read_memory(): memory read caused data abort (address: 0xffffffff, size: 0x1, count: 0x4) Error: gdb_server.c:101 gdb_get_char(): read: 10054 Wieder beim Stepping über einen Code-Block hinweg. jtag_speed 2 oder jtag_speed 3 macht keinen Unterschied.
quote: Warning: arm7_9_common.c:1798 arm7_9_read_memory(): memory read caused data abort (address: 0xffffffff, size: 0x1, count: 0x4) Error: gdb_server.c:101 gdb_get_char(): read: 10054 Nicht initializiert Pointer ? Wo gibt keine Speicher oder Periphärien, gibt "Data Abort", ganz normal. Versucht mit 10. Ich bin auch ein bisschen gespannt weil meine nicht gut lauft, und ich so viel Geld investiert habe :-((
An sich nutze ich in diesem super-simpel-Testprogramm noch gar keine Pointer. Ggf. haut mir aber irgenwo ein Interrupt rein, obwohl nach einem Reset doch eigentlich gar keine aktiv sein dürften. Allerdings ist bei den Philips-Dingern die Liste der Errata ja nicht gerade kurz :-) Jedenfalls sind die Interrupt-Routinen bisher unbelegt, wobei ich dachte, dass dies kein Problem darstellen sollte, solange ich keine Interrupts aktiviere. Übrigens trat der Fehler ja auch schon mit anderen Meldungen auf (siehe ganz oben), ggf. waren die Meldungen aber bereits eine Folge eines solchen Fehlers!? Jedenfalls schade, dass anscheinend noch wenig andere mit der Kombination Yagarto / Amontec JTAGkey Erfahrung haben. Wäre für Erfahrungserichte schon sehr dankbar.
Lösungen zu meinen Fragen (Dominic Rath, der Autor von OpenOCD hat mir freundlicherweise meine Fragen direkt beantowrtet, seine Antworten sind hier wiedergegeben): ----------------------------------------------------------------------- Frage zu Problem mit Stabilität von OpenOCD, GDB oder Amontec-Treiber: > Nach einiger Zeit bricht die Verbindung zusammen, insebsondere beim > stepping über große Blöcke (z.B. while-Schleifen). > > Dabei entstehen zwei mögliche Fehlersituationen: > > 1. (oft) > Error: ft2232.c:201 ft2232_read(): FT_Read returned: 4 > Error: ft2232.c:365 ft2232_send_and_recv(): couldn't read from FT2232 > > 2. (selten) > Warning: arm7_9_common.c:1798 arm7_9_read_memory(): memory read caused > data abort (address: 0xffffffff, size: 0x1, count: 0x4) > Error: gdb_server.c:101 gdb_get_char(): read: 10054 > Antwort zu Unterpunkt 1. (oft) '4' entspricht einem FT_IO_ERROR - das deutet auf ein USB Problem hin. Die meisten User konnten ähnliche Probleme durch die Verwendung eines self-powered Hubs in Griff bekommen. Den genauen Grund konnte ich bisher nicht in Erfahrung bringen, da auf all meinen Rechnernen noch nie ähnliche Probleme aufgetreten sind, aber scheinbar sind manche USB Controller empfindlich was den vom USB entnommenen Strom angeht. Meine Anmerkung: Habe das auch mal an einen Self-Powered-USB-Hub angeschlossen, und zumindest im ersten Versuch trat das Problem nicht mehr auf. Allerdings ist ein Versuch noch wenig aussagekräftig, trotzdem aber emutigend, dass dies das Problem lösen kann. Antwort zu Unterpunkt 2. (selten): 10054 entspricht WSAECONNRESET - die Gegenstelle (der GDB) hat die Verbindung abgebrochen - eigentlich sollte das nicht passieren. Es wäre möglich, dass dieser seltene Fehler auf ein Problem im GDB zurückzuführen ist. ---------------------------------------------------------------------- Frage zum Problem mit Stepping über lange while-Schleifen: > c = a + b; // Stepping OK > l = 3000; // Stepping OK > while (l--) { // Hier bricht alles zusammen > ; > } Antwort: Das ist ein Problem des GDBs - der GDB verwendet für den Step jeweils einzelne Assembler-Level Single-Steps, anstatt den Block mit einem Breakpoint zu überspringen. 3000 Steps dauern auf einem ARM7 (keine HW Unterstützung für single-step) via JTAG eine kleine Ewigkeit. Das Problem betrifft allerdings vor allem eher ungewöhnlichen Konstrukte wie eine solche Schleife ohne "Body" - auch über komplexe Source Statements kann der GDB normalerweise problemlos hinweg-steppen. Als Workaround bietet sich ein Breakpoint am Ende der Schleife an. Anmerkung dazu: Nachdem ich meine USB-Verbindung auf einen Self-Powered-Hub umstellte, war auch dieses Problem behoben. ---------------------------------------------------------------------- Frage zur Taktfrequenz bei Flash-Config im Config-Script: > 2. Für OpenOCD gibt man in der Flash-Config u.a. die Clock Frequency in > kHz an (flash bank lpc2000 0x0 0x40000 0 0 lpc2000_v1 0 14746 > calc_checksum). Kann das auch eine reelle Zahl sein? Im konkreten Fall > ist ja ein 14.475.600-Hz-Quarz auf dem Board, das habe ich jetzt mal mit > 14746 angenähert. Lieber wäre mir 14745.6 anzugeben, aber es > auszuprobieren wollte ich nicht einfach so. Wieso steht dort in den > anderen Skripten immer 14765? Haben nicht alle Olimex-Boards einen > 14.745.600-Quarz? > Antwort: Der Wert wird von den IAP Routinen des On-Chip Bootloaders für die Flash Timings benötigt und ist wohl relativ unkritisch. Häufig funktioniert selbst ein Wert der um ein Vielfaches vom tatsächlichen Takt abweicht - z.B. 14746 obwohl die PLL mit 60MHz aktiviert ist. Die IAP Routinen erwarten den Wert in ganzen kHz, real-Werte sind damit also nicht möglich. Es ist gut möglich, dass die 14765kHz einfach ein Tippfehler sind, der seither immer wieder kopiert wurde - diese kleine Abweichung hat allerdings überhaupt keinen Effekt auf die korrekte Funktion des Flash Vorgangs. ------------------------------------------------------------------------ Frage zur Reihenfolge von Befehlen im Config-Script: > - Spielt die Reihenfolge der Befehle im OpenOCD-Config-File eine Rolle > (ausser natürlich die Reihenfolge der Targets zu definieren). Konkret > frage ich mich, wieso in den meisten Config_Files immer "daemon_startup > reset" relativ weit unten kommt, obwohl es "logisch" doch zur Daemon-Cfg > gehört. Ich habe es also nach oben verschoben (Dritte Zeile). Scheint zu > tun... > Antwort: Die Reihenfolge spielt nur bei der Definition JTAG Kette (jtag_device), der Targets und der Flashes eine Rolle, also immer dann, wenn mehrere Objekte eines Typs existieren können, die dann über einen Index nummeriert werden, und wenn ein Objekt ein anderes referenziert, z.B. ein target das jtag_device, und eine flash bank das target. ------------------------------------------------------------------------ Frage zur üblichen Stabilität / Erfahrungswerte zur Stablität: > - Wie stabil läuft normalerweise die gleiche Ausstattung (Yagarto + > JTAGKey)? Gibt es dazu Erfahrungen? > Antwort: Normalerweise funktioniert die Kombination ausgesprochen stabil. Ich selbst setze Yagarto zwar selten ein, da ich 99.999% unter Linux arbeite, aber generell bekommen die User Anfangsschwierigkeiten (meist die .cfg) in Griff, und können dann stabil arbeiten. Eclipse ist in meinen Augen ein kleiner Unsicherheitsfaktor, da es den User vom GDB abschirmt - wenn etwas aufgrund von Einschränkungen, die für JTAG Debugging gelten (nur 2 HW Bkpts, kein 'run' sondern nur continue, step etc.) schief geht kommen Eclipse und GDB aus dem Takt. Ich selbst verwende nur den Kommandozeilen GDB, andere User haben aber auch mit Insight und Eclipse gute Erfahrungen gemacht. ------------------------------------------------------------------------ An dieser Stelle nochmal vielen Dank an Dominic Rath, der alle meine Fragen schnell und kompetent beantwortet hat. Danke!
Danke, ganz interessant ! Ich wollte mit meine für-Alle dev laptop, mit ein avr910 kompatibel (mysmartUSB by myAVR) ein ATMega88 brennen, aber hat nicht geklappt. Ich kann machmals mit minicom etwas von den Dongle bekommen. Auf eine zweite PC diese dongle geht. Ich habe die Treibern für WebISE (Xilinx) installiert, und plötlich die Dongle (mysmartUSB) geht nicht mehr. Vielleicht Alle meine Probleme kommen von diese Jungo windoof (WebISE) Treiber. Ich werde nochmal alles installieren (Schade) und nochmal probieren. Hat jemand ein Erfahrung ? (vor ich diese SuSE 10.0, daß nicht viel Speicher als 10.1 und 10.2 braucht weg mache ?). Danke
Hallo! Habe den Thread hier mit Interesse gelesen. Kann mir jemand etwas zur Anpassung des JTagKey an einen ARM-Controller sagen? Wir benutzen hier netX-Controller von Hilscher. Der Kern ist ein ARM926EJS. Ich würde gerne OpenOCD damit verwenden. Kann das funktionieren? Gruß und VIelen DAnk, Andreas
Der ARM926EJS Kern wird von OpenOCD unterstützt. Sollte kein Problem sein. > Kann mir jemand etwas zur Anpassung des JTagKey an einen ARM-Controller > sagen? Was willst du am JTagKey anpassen? Viele Grüße Jörn
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.