Hallo, Ich wollte mal den H-JTAG wegen dem H-Flasher testen. Doch ich habe ein Problem mit diesem Board: Embedded Artists LPC2148 USB QuickStart Board + Prototype Board V1.1 . Wenn ich Detect Target starte wird das Device nicht erkannt und somit kann ich nichts damit machen. Ich habe schon einige Einstellungen probiert. Ich habe auch schon ein LPC2138 QuickStart Board versucht, es geht auch nicht. Der parallel JTag ist von Olimex. Ein Keil MCB23xx Board wird erkannt und es funktioniert. Muss man bei dem Embedde..Artist Board etwas spezielles anpassen ausser JTAG jumper? Besten Dank im Voraus mgiaco
So habe es jetzt geschaft mein Embedded Artist Board mit dem H-JTAg zu verbinden. Aber ich bekomme noch einen Fehler wenn ich von Keil aus versuche zu Flashen. Load "C:\\Keil\\ARM\\GNU\\Boards\\Keil\\MCB2100\\Blinky\\Flash\\Blinky.ELF" *** RDI: System-Reset is not supported ! *** RDI: System-Reset is not supported ! Load size error. Unknown Error Full Chip Erase Failed! Kann mir jemand Helfen? Was ist das Problem? Ich habe alles so gemacht wie im PDF von Martin Thomas. Besten Dank im Voraus mfg mathias
Mein Text ist schon etwas älter. Keil+H-JTAG+Wiggler war seinerzeit nur eine kurze Spielerei hat aber recht gut zum Flashen funktioniert. Im Text sind die Versionen der Keil IDE und von H-JTAG genannt, mit denen ich getestet habe. Kann gut sein, dass aktuelle Versionen von uVision oder H-JTAG nicht mehr "miteinander können". Hatte irgendwann nachdem ich meinen Text erstellt hatte auf arm.com eine Application-Note für uVisoin+H-JTAG (Stundent's guide oder ähnlich) gesehen. Die App-Note hat teilweise ähnlichen Inhalt wie mein Text, bietet aber noch weitere Themen und kommt zudem von den "Göttlichen" höchstselbst. Daher habe ich meinen Text nicht mehr aktualisiert und die Methode mangels Eigenbedarf nicht mehr mit aktuellen Versionen getestet. Vorschlag: die Vorgehensweise aus der ARM Application-Note nachvollziehen, falls das nicht funktioniert: ARM anschreiben und nachfragen, warum das Beschriebene nicht "klappt". Mit etwas Glück landet die Anfrage dann auch bei der "ARM-Abteilung" Keil und dort erbarmt sich jemand zu antworten oder - mit noch mehr Glück - einen eventuellen Fehler auch noch zu beheben. Kurzer Weg: support-forum auf keil.com. Alternativ: "twentyone" anschreiben und fragen, er kann vielleicht von der anderen Seite her helfen.
Nachtrag: link zur Application-Note von ARM zu uVision+H-JTAG: http://www.arm.com/miscPDFs/13610.pdf Den vielleicht etwas unglücklichen Tonfall in den letzten paar Zeilen meines vorherigen Beitrags bitte nicht überbewerten. Meine Erfahrungen mit dem Keil-Support sind alles Andere als aktuell und noch aus den Zeiten, als das ULINK nicht dazu zu bewegen war, unter Windows2000 zu arbeiten. Ich war und bin kein Lizenznehmer von Keil/ARM, konnte also als Nutzer der Testversion auch keinen "Premium-Support" erwarten.
Ja danke, diese PDF hatte ich schon. Mit deinem bin ich aber viel weiter gekommen, eben bis zu diesem Problem. I werde mal weiter schauen. Ich bleibe aber so wie ich denke bei Eclipse / WinARM und Openocd => funktioniert ja gut. Noch was anderes gibt es eine gute Beschreibung für das erstellen von Linker-, Startup- und Make-Files im Bezug auf LPC ARM. Deine Files sind ja wirklich super aber die zu verstehen ist ohne Beschreibung schwierig. Gerade die Linker-Files schauen bei vielen anders aus. Ich meine die von der Portierung von den Phillips Codebeispielen zum Beispiel. Was ist eigentlich der Unterschied zwischen .cmd und .ld sind doch beides Linker-Files oder? Besten dank schon mal mgiaco
"Noch was anderes gibt es eine gute Beschreibung für das erstellen von Linker-, Startup- und Make-Files im Bezug auf LPC ARM." Jim Lynch's Tutorial dürfte den besten Überblick für ARM "bare metal" und gnu-Toolchain geben. "Deine Files sind ja wirklich super aber die zu verstehen ist ohne Beschreibung schwierig." Muss zugeben: meine Dateien (make, linker-script etc. sind stellenweise etwas überladen aber dafür wird hoffentlich auch möglichst viel "vorgekaut". Ein gutes "Rezeptbuch" für die Nutzung der GNU arm-elf Toolchain kenne ich nicht. Habe mich auch seinerzeit auch durch die GNU-manuals und diverse Beispiele gekämpft. "Gerade die Linker-Files schauen bei vielen anders aus. Ich meine die von der Portierung von den Phillips Codebeispielen zum Beispiel." Im Prinzip "schauen" die schon alle gleich aus, ich habe da nicht gehext. Es geht nur darum, bestimmte "Sektionen" Speicheradressen zuzuweisen, viel mehr passiert nicht. Vielleicht zwar in einigen von meinen Beispielen enthaltene Funktionalität, die man woanders nicht so oft sieht: - Vorbereitung Remapping: Speicher reservieren für Execptions-Vector im RAM - Vorbereitung für "fastrun"-Funktionen: Programmcode im RAM - unused-code-removal support: Verarbeitung von function- und data-sections, neu bei gcc 4 und binutils ab 2.16(?) "Was ist eigentlich der Unterschied zwischen .cmd und .ld sind doch beides Linker-Files oder?" Wahrscheinlich ja. Meines Wissens existiert keine wirkliche Konvention für die Dateiendung von Linker-Dateien. Vordefinierte Scripte im lib-Pfad der Toolchain enden meist mit .x*. Diese Skripte habe ich aber für ARM Projekte nie direkt genutzt sondern höchstens Teile davon übernommen. Ich vermeide Endungen mit .x um die vordefinierten von den selbstgebastelten Skripten deutlich abzugrenzen und nutze stattdessen .ld als Endung. Diese Endung habe es mir aber auch nicht selbst ausgedacht, sondern von irgendwoher übernommen (alte Keil-Beispiele?). Endung steht wohl für linker-description. cmd als Endung für Linker-Scripts auch schon mal irgendwo gesehen (Lynch?). Aber das ist eigentlich eine "well known"-Endung unter MS Windows NT++ und ich vermeide diese daher. Hoffe, es hilft etwas weiter. Martin Thomas
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.