Forum: Mikrocontroller und Digitale Elektronik Problem mit OpenOCD - Yagarto


von Volker T. (funker211)


Lesenswert?

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!

von Ale (Gast)


Lesenswert?

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).

von Volker T. (funker211)


Lesenswert?

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.

von Ale (Gast)


Lesenswert?

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

von Volker T. (funker211)


Lesenswert?

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...

von Volker T. (funker211)


Lesenswert?

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.

von Ale (Gast)


Lesenswert?

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 :-((



von Volker T. (funker211)


Lesenswert?

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.

von Volker T. (funker211)


Lesenswert?

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!

von Ale (Gast)


Lesenswert?

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

von Rickert (Gast)


Lesenswert?

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

von Jörn K. (joern)


Lesenswert?

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
Noch kein Account? Hier anmelden.