Hallo, im Moment beschäftige ich mich damit, das ich versuche meine geschriebenen Programme (Eclipse und AT91SAM7X256) in den Flash zu schreiben und nicht wie bisher in den RAM. Das stellt sich irgendwie schwieriger herraus, als einfach nur das Tutorial bei yagarto durchzuarbeiten. Habe bei meiner Suche eine Seite gefunden: http://gandalf.arubi.uni-kl.de/avr_projects/arm_projects/openocd_intro/index.html Das Beispiel habe ich mir auch herruntergeladen und erstmal ausgiebig angeschaut. Dann habe ich versucht aus meinem Programm und der Vorlage ein laufendes Projekt zu kriegen. Fehlermeldung war jedoch: make all C:\Program: C:\Program: No such file or directory make: *** [begin] Error 127 Ich habe erstmal das makefile von der HP genommen und versucht anzupassen. Leider ist das nicht sehr einfach für jemanden, der sich nicht so gut auskennt. Reicht das nicht, wenn ich einfach meine bisherige makefile abändere, sodass er mir einfach eine main.bin erzeugt? (Will nicht über batch-files gehen) Außerdem im Debug-Dialog "Commands" und die Datei at91sam7x256-armusbocd.cfg anpassen. Würde das gehen? Allgemeine Fragen: Wenn das Programm im Flash ist, kann man Debuggen? Wie programmiert ihr, gleich im Flash oder erstmal das Programm in den RAM? Vielen Danke und Grüße, Marius
Hallo Marius, Solange das RAM gross genug ist, ist es sehr viel einfacher dorthin zu laden und zu debuggen. Laden ins RAM bedeutet einfach beschreiben, das kann mit einem Befehl pro Adresse gemacht werden. Ein Flash zu beschreiben ist doch etwas mehr Aufwand und das wird entweder von der IDE unterstuetzt oder nicht. Meine Empfehlung fuer den SAM7 einen guten USB-JTAG Emulator zu benuetzen. Debuggen im Flash ist sehr muehsam weil der ARM nur 2 Hardware Breakpoints hat. Es gibt nur ein mir bekanntes Tool, das auch Flash Breakpoints setzen kann. Musst jetzt leider etwas googlen mit den Begriffen, sonst mach ich gleich wieder Werbung. Robert
Was erspare ich mir durch den USB-JTAG Emulator, bzw. was macht dieser? Ich benutze im Moment ARM-USB-TINY von Olimex. Ist das nicht ein USB-JTAG Emulator?
Ja, das ist ein USB-JTAG Emulator. Das Problem ist aber normalerweise nicht die Hardware sondern die Software dazu. Jetzt musst du also nur noch einen Flash Loader finden, der mit dem USB Tiny zuverlaessig funktioniert. Wahrscheinlich gibt es Ansaetze dafuer, sind mir aber leider nicht bekannt. Ich hab immer mit den kommerziellen Paketen von IAR und Keil gearbeitet und die haben download Moeglichkeiten fuer andere USB-> JTAGs. Fuer Debugging im Flash sind mir aber nur die Tools von High-End Emulatoren (typisch >> 5k Euro) und Flash Breakpoints unserer Firma bekannt. Wenn du mit Yagarto arbeitest, dann waere es doch eine Idee auch mit der Hardware zu arbeiten, fuer die es dort "how-to"s gibt. z.B. recht ausfuehrlich: http://www.yagarto.de/howto/jlink/index.html (Vorsicht das ist Werbung von jemand anders fuer die Produkte unserer Firma) Ein kleiner Geschwindigkeitsvergleich JTAG bei Yagarto: http://yagarto.de/projects/jtagspeed/index.html Robert
Hallo, Eine Frage zu J-Link. Ich Arbeite zurzeit mit JTAGkey und es funktioniert mit Yagarto und OpenOcd auch recht gut – Schreiben, Debuggen, im RAM und im Flash. Nur was mich etwas nervt ist die Geschwindigkeit beim singel step. Und das es vorkommen kann, dass sich Eclipse und GDB verabschieden ab und zu – Wobei es schneller und stabiler geworden ist. (Kann das jemand sonst noch bestätigen). Im Vergleich zu Crossworks aber immer noch langsamer. Merkt man einen unterschied mit J-Link und Eclipse bezüglich Speed beim singel step? Loht es sich um 100 Euro oder doch gleich Crossworks kaufen? danke
Huhu, ich habe seit einigen Tagen ein J-Link für ~130€ (98,- + MwSt. + Versand) und verwende den mit Eclipse + GDB-Server. Das Teil ist deutlich schneller und stabiler als mein Ft2232 Adapter mit dem OpenOCD. Viel habe ich aber mit beiden Adapter noch nicht gemacht. Was allerdings nicht funktioniert ist das Flashen des Controllers (LPC2368). Er flasht zwar (~40kB/s), das Programm läuft aber in 9 von 10 Fällen nicht. Da werden wohl falsche Daten geschrieben. Ich nehme mal an das der Flash-Download über den GDB-Server noch experimentell ist. Dank des Bootloaders bin ich beim LPC aber nicht auf JTAG angewiesen.
So, schamlose Eigenwerbung, aber als Open-Source Projekt ist man da wohl ein wenig freier ;) Normalerweise funktioniert der OpenOCD ausreichend stabil. Natürlich gibt es immer wieder Probleme, aber die werden in der Regel schnell behoben. Das größte Hindernis für Einsteiger ist wohl die aufwendige Konfiguration, die einige Kenntnis über die Zielhardware und das verwendete JTAG Interface voraussetzt. Ausserdem ist das Arbeiten mit GDB natürlich nicht jedermanns Sache. Die Integration mit Eclipse klappt aber immer besser, Øyvind Harboe hat hier in den letzten Wochen und Monaten viele Verbesserungen eingebracht. Wer eine möglichst einfache Plug&Play Lösung möchte ist bei den kommerziellen Anbietern wohl besser aufgehoben (zumindest noch - Ziel ist es natürlich, den Anwendern hier so weit wie möglich entgegen zu kommen). Das geht allerdings meistens mit einem deutlich höheren Preis einher, da zu den günstigen Preisen für die JTAG Hardware nochmal einiges für die Software fällig wird. Ausgenommen sind hier z.B. Studenten, die günstigere Lizenzen bekommen. Bei Rowley gibt es afaik ganz allgemein für nicht-kommerzielle Anwender vergünstigte Lizenzen. Das Flashen von AT91SAM7x funktioniert seit einiger Zeit stabil - falls es zu Problemen kommt kann ich das OpenOCD Forum empfehlen: http://forum.sparkfun.com/index.php Eine Mailingliste existiert auch, allerdings richtet die sich mehr an OpenOCD-Entwickler. Gruß, Dominic
Der Fehlerbericht > make all > C:\Program: C:\Program: No such file or directory > make: *** [begin] Error 127 deutet erstmal auf ein Problem mit Eclipse- und/oder Pfad-Einstellung hin. Zum Start der Debug/Flash-Software (OpenOCD) oder gar zur Kommunikation per JTAG-Interface kommt es also augenscheinlich erst garnicht. Wurde "flashen" denn überhaupt schon ohne Eclipse, make, etc. ausprobiert/getestet? Also per Aufruf von openocd.exe mit Kommanodzeilenparametern von der Eingabeaufforderung. MS Vista oder englisches Windows 2k/XP im Einsatz? Also Programme im (evtl. virtuellen) Pfad "Program Files". Im Zweifel alle Komponenten in ein eigenes Verzeichnis unterhalb C: installieren (z.B. C:\Yagarto oder C:\WinARM oder whatever). Spart Vorkehrungen für Pfade mit Leerzeichen bei allen MS Systemen und zudem mit virtuellen Pfaden/Sicherheitseinstellungen bei Vista. (Anmerkungen zu ARM Debug Soft- und Hardware hätte ich auch ein paar - ein andermal).
@Marius Merten: Debuggen kannst auch im Flash... Wie Robert T. schon angeführt hat, hast du beim ARM nur zwei Hardware Breakpoints. JLINK unterstützt glaube ich auch Software Breakpoints. Dafür muss man aber eine Lizenz erwerben. Ich verwende größtenteils IAR Embedded Workbench und ich debugge entweder mittels Single-Step, Run to Cursor oder einfach mittels Konsolen-Outputs über eine verfügbare RS232 Schnittstelle. Ist zwar nicht so komfortabel wie mit Breakpoints, aber eine bessere Lösung habe ich für mein Problem nicht. Wenn das RAM eben nicht mehr als Programmspeicher ausreicht, dann muss man im Flash debuggen. Wenn du jetzt aber nur dein Programm ins Flash schreiben willst, ohne noch debuggen zu wollen, würd ich mir einen Bootloader dafür schreiben, und ich meine jetzt nicht den umständlichen SAM-BA von ATMEL. Habe einen einfachen Bootloader entworfen mit dem ich mittels eines kleinen Windows Tools die von IAR generierte HEX Datei meiner Applikation flashen kann.
Danke euch allen! Werde mich jetzt erstmal probieren. Natürlich erstmal so, mit meinen bisherigen geräten ... olimex ... und wenn ich meine "erfahrungen" damit erworben habe, werde ich im notfall zu etwas anderes greifen müssen1 Viele Grüße, Marius
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.