Hi Ich weis echt nimmer. Ich habe jetzt reichlich Erfahrung mit AVRs, und wollte für ein etwas anspruchsvolleres Projekt auf ARM umsteigen. Also habe ich mir ein eval-Baord mit At91SAM7S64 von Olimex, und den passenden WIGGLER-Jtag-Adapter zugelegt. Mein erster Versuch war, die Sache mit der YATARGO-IDE zum Laufen zu bringen. Hat auch ganz gut funktioniert. Ich konnte Programme schreiben, die in den ARM brennen und auch ausführen (so weit, so gut). Mit wurde aber dann die Geschichte mit den ewig nicht funktionierenden Linkserscripts und Startup-Codes (sorry, aber ich bin stolz behaupten zu können, dass ich AVR-ASM-Code lesen (und manchmal auch schreiben) kann) bald zu bunt. Daher hab ich auf Anraten eines Freundes Keil µVision 3.53 heruntergeladen und getestet. Wow, keine Linkerscripts. Keil gefällt mir echt gut. Da kann ich mich erstmal reinarbeiten. Das Problem ist jetzt aber, dass ich (in Kombination mit H-JTAG) den ARM nichtmehr flashen kann. ARRRGGGGHH Da ich mich aber von ein bisschen Silizium nicht frustrieren lassen will, hab ich ein paar Fragen: 1) Ist YATARGO so ******* wie ich denke, oder mach ich da was falsch? (Ich glaube ja zweiteres... In dubio pro reo. :P) 2) Gibt es auch "all-round"-Linkerscripts (mit Ramfunction-Support, IRQ/FIQ usw) (und evtl. auch Startup-Codes) für WinARM? (Wie bei den AVRS...) 3) Gibt es eine Lösung Keil-Code auf den ARM zu bringen? (evtl mit openOCD?) Wie macht ihr das? 4) Ich bekomme in Keil beim Flashen: *** RDI: System-Reset is not Supported! *** RDI: System-Reset is not Supported! Load size error. Unknown Error. Erase Failed! Und als Popup: Cannot Load Flash Programming Algorithm ! Ich glaube das hat irgendwas mit den RAM-Adressen und -Größe zu tun. Ist der Wissensstand immernoch wie in Beitrag "H-JTAG LPC2148 Embedded Artists Board" oder gibts da was neues? Bin im Moment etwas verzweifelt... Vielen Dank für eure Hilfe! Tobi
Tobi wrote: > Ich weis echt nimmer. Was? > Ich habe jetzt reichlich Erfahrung mit AVRs, und wollte für ein etwas > anspruchsvolleres Projekt auf ARM umsteigen. > Also habe ich mir ein eval-Baord mit At91SAM7S64 von Olimex, und den > passenden WIGGLER-Jtag-Adapter zugelegt. > Mein erster Versuch war, die Sache mit der YATARGO-IDE zum Laufen zu > bringen. Hat auch ganz gut funktioniert. Ich konnte Programme schreiben, > die in den ARM brennen und auch ausführen (so weit, so gut). > Mit wurde aber dann die Geschichte mit den ewig nicht funktionierenden > Linkserscripts und Startup-Codes (sorry, aber ich bin stolz behaupten zu > können, dass ich AVR-ASM-Code lesen (und manchmal auch schreiben) kann) > bald zu bunt. Genaue Problembeschreibung der "Geschichte"? > Daher hab ich auf Anraten eines Freundes Keil µVision 3.53 > heruntergeladen und getestet. Nun dann erübrigt sich ja Hilfe in Sache "Yagarto-IDE" (Yagarto ist eine vorkompilierte Sammlung aus GNU arm-elf Toolchain, Eclipse, Eclipse-Plugins und OpenOCD nicht wirklich ein eigenständiges Produkt, genauso wenig wie meine WinARM-Sammlung). > Wow, keine Linkerscripts. Nutzt man die GCC-Toolchain als Backend für uVision gibt es weiterhin Linkerskripte für den GNU-Linker. Falls man die RealView-Tools nutzt, sind Fragen dazu in diesem Forum (gcc) unpassend. Also weiter "off-topic": Bei RealView heissen die Dateien zur Steuerung des Linkers scatter(-load)-files und dienen dem gleichen Zweck. Sobald das Speicherlayout nicht mehr durch klicken in der IDE wie gewünscht einzustellen ist, muss man sich auch mit "scatter-files" beschäftigen. (Nur im Manual darüber gestöbert, eigene scatter-files funktionieren bei der Eval-Version nicht, daher nicht selbst ausprobiert.) > Keil gefällt mir echt gut. "Keil"? Gemeint ist wohl RV-MDK. Neue Baustelle, gleiche Fehler: ungenaue Beschreibungen. Man gibt bei Fragen (dann im Forum von www.keil.com) auch besser die RV-MDK (Packet-)Version (vor Kurzem war das 3.11, k.A. ob schon eine aktuelle Version da) und nicht die Version von uVision, zumindest scheint das üblich. Wenn es "echt gut" gefällt, dann ist ja gut. Wenn Eval-Lizenz und Codegrößenbeschränkung nicht zum eigenen Projekt passen, bleibt nur die "kleine" Hürde der Anschaffung einer vollen Lizenz. > Da kann ich mich erstmal reinarbeiten. > Das Problem ist jetzt aber, dass ich (in Kombination mit H-JTAG) den ARM > nichtmehr flashen kann. *ARRRGGGGHH* H-JTAG als RDI-Wigger Schnittstelle hat nachweislich mit älteren Versionen von RV-MDK oder CKARM) funktioniert. Meine Erkenntnisse zu altem und neuen Stand stehen schon im genannten Thread. > Da ich mich aber von ein bisschen Silizium nicht frustrieren lassen > will, hab ich ein paar Fragen: Hat sich bisher so gelesen, als ob Frustation schon da war, obwohl, nein, das steht ja "...Hat auch ganz gut funktioniert...", ach was, doch, da steht ja "ewig nicht funktionierenden". Ach egal, der Beitrag scheint ja eh mehr eine Frustwegschreiben zu sein. (Antworte eigentlich nach Möglichkeit nicht auf solche Beiträge, aber ganz unkommentiert wollte ich es nicht stehen lassen. Die Bedienung der freien Tools mag anfangs etwas spröde sein, aber mehr auch nicht). > 1) Ist YATARGO so ******* wie ich denke, oder mach ich da was falsch? Wohl Letzteres. Zusammenhänge nicht verstanden (Yagarto ist eine Sammlung, kein einzelnes Produkt), Probleme wahrscheinlich schlecht beschrieben, an falschen Stellen gefragt, die Funktion der Einzelkomponenten nicht verstanden. Lynchs Tutorial nicht gelesen oder nicht verstanden... > (Ich glaube ja zweiteres... In dubio pro reo. :P) (Wer ist angeklagt?) Jetzt doch wieder "on-topic"? Keil/ARM-Produkt ist doch jetzt Mittel der Wahl. Es bleibt verwirrend - für mich. > 2) Gibt es auch "all-round"-Linkerscripts (mit Ramfunction-Support, > IRQ/FIQ usw) (und evtl. auch Startup-Codes) für WinARM? (Wie bei den > AVRS...) Es gibt ein default Linkerscript für arm-elf (wird mit arm-elf-ld --verbose eingezeigt), das ist auch irgendwie all-round. Aber man muss einige Paramter an den Linker geben, um es verwenden zu können (nie selbst gemacht), so dass ein eigenes Linkerscript meiner Meinung nach einfacher und übersichtlicher ist. Ist wohl nicht nur meine Meinung, habe bisher noch keinen LPC2k, AT91SAM, STR7, ADuC etc. Code für GNU-Toolchain gesehen, der das default-script nutzt. Funktion von Linker-Script und Startup-Code nochmal nachvollziehen (Lynchs Tutorial und Artikelserie bei embedded.com zum Einstieg). Was soll der Linker (ld) mit Assembler Source-Code (für (g)as) zum Startup in seiner Steuerdatei anfangen? Es sind zwei Dateien für unterschiedliche Funktionen. Auch bei avr-gcc et. al. so nur besser vorgekaut. Was funktioniert bei den WinARM Beispielen nicht wie erwartet? > 3) Gibt es eine Lösung Keil-Code auf den ARM zu bringen? (evtl mit > openOCD?) Wie macht ihr das? Die vom uVision-Flasher/Debugger für ARM unterstützten JTAG-Interfaces sind in der Dokumentation erläutert. Meines Wissens ist kein gdb-Interface genannt und damit entfällt debugging über OpenOCD. Einen "Vermittler" zwischen uVision und OpenOCD in Form einer "RDI nach dgb-Server"-dll ist mir nicht bekannt, kann aber gut sein, dass es sowas gibt, die RDI-Schnittstelle ist meines Wissens offengelegt. > 4) Ich bekomme in Keil beim Flashen: > > *** RDI: System-Reset is not Supported! > *** RDI: System-Reset is not Supported! > Load size error. > Unknown Error. > Erase Failed! "Keil" nutzt wohl in neueren Versionen einen (oder mehr) RDI Befehl(e)/Funktion(en), die H-JTAG nicht unterstützt. Entweder wird das in H-JTAG nachgerüstet oder Keil nutzt die "alte" Vorgehensweise. Keil-Support oder H-JTAG Entwickler anschreiben und hoffen. Ansonsten: alte Version des Keil-Packets nutzen (vgl. ARM AppNote). > Und als Popup: > Cannot Load Flash Programming Algorithm ! Folgefehler. Verbindung per JTAG kann nicht herstellt werden also kann auch die Codesequenz zum Flashen nicht ins RAM des Controllers übertragen werden. > Ich glaube das hat irgendwas mit den RAM-Adressen und -Größe zu tun. Ich nicht. System-Reset is not supported deutet nicht darauf hin. Aber auch nur spekulation, man kann ja nicht in den Code von Keil oder twentyone schauen. Falls man nur flashen will (nicht debuggen), kann man die erzeugte hex-Datei auch mit H-JTAG und OpenOCD übertragen. > Ist der Wissensstand immernoch wie in > Beitrag "H-JTAG LPC2148 Embedded Artists Board" > oder gibts da was neues? In Sachen uVision Debugger und H-JTAG von meiner Seite nichts. > Bin im Moment etwas verzweifelt... Aber nicht frustriert ;-). Wenn man schon auf das "Keil-Pferd" setzt, dann wäre die Anschaffung von entsprechendem "Sattel" in Form eines untersützten Debug-Interfaces naheliegend z.B. SAM-ICE (enthält meines Wissens Seggers RDI-Lizenz, ist aber nur für AT91 dafür relativ günstig), J-Link+RDI Lizenz, ULINK(1) oder ULINK2. Ansonsten gibt es ja noch weitere "Pferde": z.B. IAR EWARM. Solange die Kickstart-Version (um es auszumelken: das "Fohlen") ausreicht, in Sachen Lizenz und Codegrößenbeschränkung sogar "entspannter" als RVMDK. H-JTAG/Wiggler funktioniert damit lt. Angaben von Olimex. Falls man aber ein "Pferd" in Form einer Vollversion zum Ziehen der "Projektlast" braucht (ok, ausgemolken) düften die Kosten für z.B. ein J-Link (wie auch für ein ULINK) im Vergleich zu den Kosten für die Softwarelizenz keine große Rolle mehr spielen. Martin Thomas
Ein anderes kostengünstiges (aber nicht -loses) Pferd ist Rowley Crossworks for ARM. Das funktioniert exzellent mit einfachen Wiggler-Clones für den Parallelport, kann in der neuesten Version aber auch mit dem kostengünstigen FT2232-basierenden OpenOCD-USB-JTAG-Interface arbeiten. Ansonsten wird derzeit jeder Bestellung ein Rowley-eigener USB-JTAG-Adapter beigepackt. www.rowley.co.uk Sofern nicht zu kommerziellen Zwecken genutzt, ist die nichtkommerzielle Lizenz für 150 USD eine gute Investition (es gibt keine technischen Unterschiede zur kommerziell nutzbaren Version, nur die Lizenzbedingungen unterscheiden sich).
Hi okok, vielleicht war ich doch etwas arg verzweifelt - sorry (so verzweifelt wie man halt ist, wenn man 3 Stunden am Stück versucht und versucht und es geht einfach garnichts) (aber nicht frustriert :P). Also die Sache ist die: Ich habe (noch) kein Studium in Informationstechnik, und höre daher den Betriff "Linkerscript" (& Co) in Zusammenhang mit ARM zum ersten Mal. Es ist so, dass die Beispiele mit dem Yatargo-Paket zwar funktionierten, aber sobald ich meinen eigenen Code schreiben wollte streikte die Ausführung auf dem ARM, weil es Probleme mit dem Linkerscript (.ld ;) ) und / oder dem Startupcode (.s :) gab. Das hab ich dann durch kreatives Austauschen der genannten Files (mit anderen aus Beispielen) gelöst bekommen. Als ich dann einen Interrput programmieren wollte, ging dann irgendwie garnichts mehr, auch meine kreativen Tauschversuche hatte leider keine Wirkung mehr. Sprich habe ich eher ein Problem in dieser Richtung. Ich wollte / hätte gerne eine "Umgebung" die "vorne Code rein, hinten Binary raus" unterstützt. "Keil" ( ~ µVision 3.5 (ARM)) war da ein Versuch in diese Richtung. Es sieht also so aus, als bräuchte ich einen Crashkurs in Sachen "Linkerscripte for ARM". Oder liege ich da wieder falsch? Wenn ich nämlich ehrlich bin, würde ich nämlich lieber den WinARM (also arm-elf) verwenden als "die Keil-Sache". Irgendwie kann es doch nicht so kompliziert sein, ein bisschen Code in den Arm zu bringen (Danke für den Tipp mit "Lynchs Tutorial", aber Datenblätter kann ich lesen ;) ). Irgendwie scheint beim ARM-Programmieren (mit arm-elf) viel vom Linkerscript abzuhängen. Gibt es in dieser Hinsicht ein Tutorial? (Google spuckt zwar viele Linkerscripts selber aus, aber das hilft ja dann auch nicht, wenn man andauernd irgendwelche scripts kopiert.) > Nutzt man die GCC-Toolchain als Backend für uVision gibt es weiterhin > Linkerskripte für den GNU-Linker. Falls man die RealView-Tools nutzt, > sind Fragen dazu in diesem Forum (gcc) unpassend. Sprich ich kann die Linkerskripte von µVision mit dem GCC auch verwenden? Oder verstehe ich das gerade etwas falsch? > H-JTAG als RDI-Wigger Schnittstelle hat nachweislich mit älteren > Versionen von RV-MDK oder CKARM) funktioniert. Meine Erkenntnisse zu > altem und neuen Stand stehen schon im genannten Thread. Okay. Ergo keine gute Nachricht in der Richtung. > Ich nicht. System-Reset is not supported deutet nicht darauf hin. Aber > auch nur spekulation, man kann ja nicht in den Code von Keil oder > twentyone schauen. Aha! Okay. Okay, Danke auf jeden Fall. Ich denke mein Problem liegt bei den Linkerscripts. VLG Tobi
Wenn du deine Applikation aus dem Ram ausführst, könnte der Fehler auch wieder vor dem Rechner sitzen. Die AT91 mappen das Flash standardmäßig an 0x0 (und 0x100000). Wenn man Interrupts im Ram haben will, muss man das remap-bit setzen, dann kommt das ram neben 0x200000 (oder so) auch an 0x0. Damit lassen sich dann auch Interrupts aus dem Ram ausführen. Eine entsprechender startup code vorausgesetzt. Bei Atmel gibt es einen Beispiel startup code mit Erklärungen dazu. Ansonsten unbedingt den von Martin Thomas nachvollziehen. Man muss ihn nicht unbedingt selbst schreiben können, aber man sollte wissen, was da passiert.
Hi Wie und warum die Interrupts nicht funktioniert haben, weis ich nicht, ich bin ja kein ARM :). Ich vermute eben, dass es an o.g. Problem lag. Aber wie gesagt. Ich weis, dass da drin steht, wo das Programm dann im Speicher liegt. Viel mehr nicht... Aber wenn das so wichtig ist, muss ich das genauer wissen. Wo kann ich das lernen? VLG Tobi
Datenblatt, Datenblatt, Datenblatt, ARM ARM (per google findet man es), AP-notes, jedes beliebige Buch über allgemeine Mikroprozessorarchitektur, jedes Buch über die ARM Architektur, Internetseiten zur gnu toolchain. VERSTEHEN, WAS MAN LIEST UND WARUM ES DIE ANDEREN SO MACHEN. Und wenn man es zehn mal lesen muss! [pre]man (arm-elf-)ld[\pre] [pre]man (arm-elf-)gcc[\pre] [pre]man (arm-elf-)as[\pre] Früher oder später wirst du dich auch bei den Kauf-IDEs mit den Internas beschäftigen (müssen). Einige verwenden nämlich auch die gcc. Nimm dir Zeit, das ganze erlernt man nicht an einem Tag. Meinereiner verwendet übrigens garkeine IDE, nur einen Editor (VIM), die arm-elf-toolchain (selbst kompiliert) und mit den Zutaten aus WinARM verfeinert, gdb/ddd/Insight in Kombination mit dem vorzüglichen openOCD.
Hi, da ich auch neu bin auf der Arm-Ebene kann ich deine Probleme gut nachvollziehen, aber leider nicht so viel helfen. Hier hat sich Martin Thomas schon mal ausführlich zu diversen Sachen ausgelassen: Beitrag "GCC, Keil und ARM, WINXP" Linkerskripts, Startupcode, Speicher. Interrupts einschalten muss man z.B., wenn ich das richtig verstanden hab, auch in der startup, bzw. später im Code, weiß nicht ob du dasgemacht hast. Beschreibung des Linkers gibts bei http://www.gnuarm.com/ unter Support, da wirst du auch noch andere wichtige Dinge finden. Man kann Keil auch zusammen mit der GNUToolchain verwenden und dort z.b. ein eigenes Linkerskript einfügen. Beispiele dazu sind im Keil Packet mit drin. Ich kenn mich leider auch nicht weiter damit aus, da wir in der Firma nur mit Keil arbeiten und ichleider keine Zeit hab mich zu vertiefen. Winarm kann man dir glaub ich auch ans Herz legen und hier: http://en.mikrocontroller.net/ gibts noch das passende Forum dazu, soweit dazu, ich hoffe es hat wenigstens n bissel was gebracht. Lass dich von "dem bissel Silizium" nicht unterkriegen ;-)
Hi, Danke! Der Thread ist genau die Art Information die ich brauche. Gibt es evtl. ein Tutorial / Manual, das es noch etwas ausführlicher erklärt, was in den Linkerscripts / Startupcodes vor sich geht? Also halt einen Überblick, keine Detailinformationen darüber, warum man zum Einlesen des Linkerscripts jetzt gerade nicht stdio verwendet hat. Diese Files scheinen irgendwie die Geißel der ARM-Programmierung zu sein, hab ich so den Eindrück. Auch auf die Gefahr hin, mich jetzt noch völlig zu disqualifizieren: > übernimmt und man zum dummen Schaf wird, dass nur zwei Adressen eingeben > muss, Welche Adressen? Viele Grüße, Tobi
Hi Tobi, das war bezogen auf die zwei Adressen R/O Base und R/W Base, bei den Linkereinstellungen von Keil. Ich musste übrigens selber noch mal kurz drüber gucken, um den Sinn zu verstehen ;-). Wenn du schon mal mit Mikrocontrollern gearbeitet hast, dann weißt du sicher, dass es dort diverse Config Bits gibt, die das Verhalten des Controllers kontrollieren. Diese Startup ist ähnlich, nur das hier vielmehr Einstellungen vorgenommen sind. Man könnte diese Einstellungen wohl auch direkt im Programm machen, aber jedesmal neu schreiben macht ja auch wenig Sinn. Außerdem hat es sicher auch eine Grund, dass das ganze in Assembler geschrieben ist. Einfache Links habe ich dafür auch nicht, hab nich keine Übersicht gefunden. ARM ist auch für eine Googlesuche denkbar schlecht, da kommt von Roboterarm bis armes Deutschland alles raus und auch startup als Ergänzung ist ebenso erfolgreich, aber wenn du was findest dann immer her damit. Ich hab grad leider keine Zeit, mich damit tiefer auseinander zu setzen, ich muss was schaffen ;-9. Früher oder später werd aber auch ich wohl nich drum herum kommen. Finds im Übrigen schön, dass es hier noch einen mit gleichem Wissensstand gibt.
Eine recht ordentliche Einführung - nicht ganz ein "Manual" aber schon eine Art Tutorial - findet sich auf den in diesem Thread verlinkten Seiten: http://en.mikrocontroller.net/topic/113459 Martin Thomas
Hi @Icke: Ja, klar, die "Systemsteuerungs"-Register :P Google hab ich schon allzu oft bemüht, da kommt einfach nix gescheites dabei raus. Aber ich glaube das liegt auch daran, dass die ARM-Gemeinde wesentlich kleiner ist als die der PIC- oder AVR-User. Ich finde das auch sehr beruhigend einen "Leidensgenossen" zu haben! :) @Martin: Danke, das sieht echt vielversprechend aus. Aber wie gesagt, Google gint da echt nicht viel her in der beziehung. Im Moment bin ich am Nachforschen ob die Interrupts überhaupt aufgerufen werden (was ich damit sagen will weis ich auch (noch) nicht genau). Das Problem ist, dass die Family dieses Wochenende UNBEDINGT einmal um den Hochgrat wollte... :( Mir ist aufgefallen, dass in den Beispielen die ISRs alle ein _irq, _fiq oder __ramfunc ö.ä. vor dem Funktionsnamen stehen haben. Bei mir ergibt das aber immer böse Fehler. Liegt das daran, dass ich den AT91SAM7S64-ROM.ld verwende? Ist das für die Interrupt-Bearbeitung unbedingt essenziell? Bin da etwas ratlos... VLG - THX Tobi
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.