Guten Tag, inwiefern kann man mit Prozessoren in Keil µVision bzw. der IAR Embedded Workbench arbeiten, die zwar einen ARM-Kern haben (in meinem Fall handelt es sich um einen ARM7TDMI) aber nicht in der Liste als Supported Devices auftauchen? Bisher hab ich nur die IAR for ARM IDE ausprobiert (mit Kickstart Lizenz, ich glaube von Keil gibts aber auch eine kostenlose, codegrößenbeschränkte Variante). Da kann ich einfach ein Projekt anlegen und in den Options als CPU "ARM7TDMI" angeben. Treiber für J-Link installiert die IDE gleich mit. Was brauche ich nun, damit ich ein unbekanntes ARM7TDMI-Device mit JTAG debuggen kann? Ich hab den Aufbau noch nicht hier aber ich versuche das Problem schon mal für die Zukunft zu lösen. Eine weitere Frage: Das Programmieren der CPU bzw. des externen Flash läuft so ab: 0. BOOTEN-Pin auf Low ziehen 1. Bootloader-Programm via UART in den internen SRAM laden 2. Bootloader-Programm beinhaltet Code um den externen Flash zu initialisieren 3. Tatsächliches Programm wird über UART und mit Hilfe des Bootloaders in den externen Flash geschrieben. 4. Diese Variante ist eher dafür gedacht, falls JTAG nicht funktioniert Inwiefern erhalte ich hier von IAR bzw. Keil µVision ein kompiliertes .hex oder .bin-File, dass ich programmieren kann? Oder muss das alles über JTag laufen? Ich hoffe, meine Fragen kamen halbwegs verständlich rüber.
:
Bearbeitet durch User
> hier von IAR ... ein kompiliertes .hex oder .bin-File
IAR: Outputkonverter einschalten.
Kann bin, hex, s19 ...
Das haette man allerdings auch selber finden koennen.
Angehängte Dateien:
Hab gerade gesehen, dass man im Keil anscheinend die Adressbereiche für ROM und RAM eingeben muss, ebenso gibt es unter "Output" einen Punkt "Create HEX file". Bleibt die Frage, wie bzw. ob das mit JTAG funktioniert.
Hat das nicht supportete Device einen Namen? Was spricht gegen JTAG als Debug Interface? Woher soll der Bootloader kommen? Fragen über Fragen... ;-) Bei IAR liegen die ganzen Device spezifischen Konfiguration unter \arm\config und da kann man sich zur Not sein eigenes Device zusammen bauen, sofern die Datenblätter ausreichend gut sind. Einfach ein ähnliches Device als Referenz nehmen, eine Kopie erstellen und anpassen. Was den Bootloader angeht, so findest Du in \arm\config\flashloader fertige Bootloader für die üblichen Verdächtigen (*.out ist das Binary, die anderen Files die Spejcherconfig, usa.) und in \arm\src\flashloader die Projekte als Source Code, die für die fertigen Bootloader die Basis waren. Also hättest Du auch hier eine Referenz. (Die Pfadangaben hab ich jetzt aus dem Gedächtnis hingeschrieben, können also leichte Abweichungen haben...)
Max M. schrieb: > 0. BOOTEN-Pin auf Low ziehen > 1. Bootloader-Programm via UART in den internen SRAM laden > 2. Bootloader-Programm beinhaltet Code um den externen Flash zu > initialisieren Nenne deinen Chip, sonst ist es nur Rätselraten. Ich vermute mal, daß es sich um einen LPC2220 oder so ähnlich handelt. Also um einen Chip ohne internen Flash, der einen solchartigen Bootlader hat, der nur dazu da ist, den eigentlichen Bootlader ins RAM zu laden, welcher seinerseits auf den externen Flash abgestimmt ist. Das klingt nach Programmierung der Lernbetty oder vergleichbarer Chips. Ob du bei so einem Chip überhaupt mit dem JLink zu potte kommst, wenn das Teil nicht in Seggers Portfolio enthalten ist, halte ich für fraglich. Grund: Der ARM7TDMI ist eine Architektur vor den Cortexen und ich glaub nicht dran, daß Segger jetzt da noch Arbeit hineinsteckt. Wenn du also mit dem Chip werkeln willst, wäre das Selber-Programmieren angesagt: sowohl der für deinen Flash geeignete Bootlader als auch das zugehörige Flash-Programm auf dem PC. W.S.
W.S. schrieb: > Also um einen Chip ohne internen Flash, der einen solchartigen > Bootlader hat, der nur dazu da ist, den eigentlichen Bootlader ins RAM > zu laden, welcher seinerseits auf den externen Flash abgestimmt ist. W.S. schrieb: > Ob du bei so einem Chip überhaupt mit dem JLink zu potte kommst, wenn > das Teil nicht in Seggers Portfolio enthalten ist, halte ich für > fraglich. Dat geht per Jlink (oder IAR) Debugscript. Damit per Registerwrite den DRAM Controller anreißen und dann das Programm in den RAM schreiben. Das geht sogar mit deinen heißgeliebten Magic Numbers ;)
Mw E. schrieb: > Damit per Registerwrite den DRAM Controller anreißen Na klar, du Schlauberger. Welcher ARM7TDMI hat denn DRAM oder wenigstens ein DRAM-EBI? Keiner. Sowas trifft man bei ARM9. Aber solange der TO sich ausschweigt, ist das nur Rätselraten. W.S.
W.S. schrieb: > Na klar, du Schlauberger. > > Welcher ARM7TDMI hat denn DRAM oder wenigstens ein DRAM-EBI? Keiner. > Sowas trifft man bei ARM9. NS7520 :P
W.S. schrieb: > Welcher ARM7TDMI hat denn DRAM oder wenigstens ein DRAM-EBI? Keiner. > Sowas trifft man bei ARM9. Meine Güte bist du wieder ne Vollpanne hier. Weder ARM7 noch ARM9 haben ein DRAM Controller, sondern der SoC in dem sie sitzen ;) Der TE sprach ja wohl eindeutig von einem Prozessor mit ARM Kern, da ist dann noch was drumrum und meine Aussage ist allgemeingültig. In deinen Zitaten ist durchaus zu lesen, dass du von Chip sprichst. Kannst du inzwischen nicht mal mehr die passenden Fachbegriffe verwenden?
Danke für eure Antworten, Michael F. schrieb: > Was spricht gegen JTAG als Debug Interface? Ich hab doch explizit erwähnt, dass ich JTAG als Debug Interface verwenden möchte? Ich hab nur die Besorgnis, dass das eventuell nicht klappt da eben die CPU nicht supported ist (weder von Keil noch von IAR) und ich nicht weiß, wie viel die JTAG-Schnittstelle über das Device wissen muss, damit ich debuggen kann (das Datenblatt ist sehr spärlich). Michael F. schrieb: > Woher soll der Bootloader kommen? Den müsste ich selbst entwickeln. Michael F. schrieb: > Einfach ein > ähnliches Device als Referenz nehmen, eine Kopie erstellen und anpassen. Vielen Dank, das werde ich mir anschauen. W.S. schrieb: > Grund: Der ARM7TDMI ist eine Architektur vor den Cortexen > und ich glaub nicht dran, daß Segger jetzt da noch Arbeit hineinsteckt. Erwarte ich doch auch gar nicht? Aber der J-Link EDU unterstützt den ARM7TDMI-Kern. W.S. schrieb: > Wenn du also mit dem Chip werkeln willst, wäre das Selber-Programmieren > angesagt: sowohl der für deinen Flash geeignete Bootlader als auch das > zugehörige Flash-Programm auf dem PC. Ja klar, das ist mir bewusst. Mw E. schrieb: > Dat geht per Jlink (oder IAR) Debugscript. Hast du dafür weitere Hinweise? Ich vermute mal, mit dem J-Link EDU wird das Debuggen nicht funktionieren da das Programm im externen Flash liegt und meines Wissens nach die EDU-Version keine Flash-Breakpoints unterstützt. Höchstens das Debuggen des Bootloaders wird vermutlich gehen, da der im internen SRAM lebt. Ich verstehe nicht, was der Name der CPU für eine Rolle spielt? Es ging mir darum, wie ich eine nicht-unterstützte CPU in IAR oder Keil so zum laufen kriege, dass ich entweder per JTAG debuggen kann oder dass wenigstens der Compiler mir eine .hex oder .bin-Datei erzeugt, die ich dann per UART-Bootloader flashen kann. Da ist der Name komplett irrelevant. Im Prinzip handelt es sich um eine CPU, die früher in Mobiltelefonen eingesetzt wurde und auch heute noch ggf. in SIM-Modulen, die man per UART mit AT-Software vom µC aus ansteuern kann (MT6205B von Mediatek). Gibt auch ein kleines Community-Projekt um Osmocom, die sich mit einer ähnlichen CPU beschäftigen (glaub es war die nächste oder übernächste Generation). Hab die CPU mit SRAM, parallelem Flash und PMIC in 7-facher Ausführung hier. Muss noch das PCB designen und dann kanns losgehen.
:
Bearbeitet durch User
Max M. schrieb: > Ich hab nur die Besorgnis, dass das eventuell nicht > klappt da eben die CPU nicht supported ist (weder von Keil noch von IAR) > und ich nicht weiß, wie viel die JTAG-Schnittstelle über das Device > wissen muss, damit ich debuggen kann (das Datenblatt ist sehr spärlich). Wenn das Datenblatt "sehr spärlich" ist, wieso tut man sich so was überhaupt an? Es gibt tonnenweise Cortex-M Derivate bei denen man keine Unmengen von Zeit mit ungewissem Ausgang verbrät... Wie bereits von mir geschrieben findet sich in ..\arm\config\ der ganze Kram mit dem die Devices innerhalb der Embedded Workbench definiert sind. Für JTAG, bzw. den Debugger wäre das Unterverzeichnis \debugger interessant und z.B. bei \Altera findest Du ein *.probeconfig File mit zusätzlichen Einstellungen für die JTAG Chain, falls die Default-Settings nicht passen. In dem gleichen Verzeichnis gibt es auch ein *.dmac (Debugger Macro) File in dem Du schauen könntest, wie man per Write-Befehl über den Debugger auf SFRs zugreift um beispielsweise darüber den RAM Controller zu konfigurieren (wie von Mw E. erwähnt). Meine bisherigen Erfahrungen in dem Bereich habe ich alle mit dem I-jet gemacht, eigentlich sollte das aber auch ähnlich mit dem J-Link funktionieren...
> Da ist der Name komplett irrelevant. Ausser IAR und Keil gibt es auch noch das ADS (ARM Development System) von ARM selber. Nur ohne Namen kann man da schlecht nach etwas suchen... Und ob man mit einem fuer die grosse Oeffentlichkeit nur sparsam dokumentierten SoC viel reissen kann?
Michael F. schrieb: > Wenn das Datenblatt "sehr spärlich" ist, wieso tut man sich so was > überhaupt an? Naja es ist Hobby und so. Ich mach das ja nicht beruflich. Danke auf jeden Fall für deine Tipps. Ich schau mir das definitiv genauer an! Außerdem wäre es natürlich cool wenn man irgendwann keine überteuerten GSM-Module mehr kaufen müsste wenn die CPUs darin doch so viel mehr Leistung haben als die Controller mit denen sie üblicherweise angesteuert werden (so ähnlich war es ja beim ESP8266 auch). pumuggl schrieb: > (ARM Development System) Gibts da eine kostenlose Lizenz (wahrscheinlich codegrößenbeschränkt)? pumuggl schrieb: > Nur ohne Namen kann man da schlecht nach etwas suchen Steht doch oben. MT6205B pumuggl schrieb: > Und ob man mit einem fuer die grosse Oeffentlichkeit nur sparsam > dokumentierten SoC viel reissen kann? Ja, kann man. Google mal nach Osmocom / Fernvale.
Max M. schrieb: > MT6205B von Mediatek Max M. schrieb: > Ich verstehe nicht, was der Name der CPU für eine Rolle spielt? Es ging > mir darum, wie ich eine nicht-unterstützte CPU in IAR oder Keil so zum > laufen kriege, dass ich entweder per JTAG debuggen kann oder dass > wenigstens der Compiler mir eine .hex oder .bin-Datei erzeugt, die ich > dann per UART-Bootloader flashen kann. Da ist der Name komplett > irrelevant. Ah, endlich ist die Katze aus dem Sack. also du glaubst, es sei egal, was für einen konkreten IC du da hast? Das ist ein gewaltiger Irrtum. Neben der CPU gibt es dort nämlich eine Menge Peripherie im Chip mit diversen Hardware-Registern, Speicherbereichen und so weiter - und dieses sollte man kennen, um mit so einem Chip überhaupt etwas anfangen zu können. Hat also dein Chip einen eingebauten Urlader, der erstmal den Takt und die diversen Stacks aufsetzt (jaja, mehrere!) und das externe Businterface freischaltet - oder ist tatsächlich der externe Flash das allererste, was die CPU zu sehen kriegt? Gibt es Konfigurationspins, die die Datenbreite des Flash festlegen? Alle solche Fragen stehen an und beantworten kann sie nur der Blick ins passnde Manual - sofern überhaupt zu kriegen. Immerhin schätze ich, daß diese Chips so rund 10..15 Jahre alt oder noch älter sind und seinerzeit nicht im öffentlichen Handel waren. So. Und wenn du alles Nähere herausgefunden hast, dann wäre die Frage, ob das Teil einen "UART-Bootlader" besitzt - oder ob du dir selber einen schreiben müßtest, den du dann in den externen Flash schreiben müßtest, um ihn benützen zu können. Alle weiteren Fragen folgen, wie z.B. die Interrupt-Bearbeitung. Du weißt, daß du ab Adresse null 7 Befehle (mit einer Leerstelle dazwischen) für die 7 Restart-Varianten hast, ja? Für den Kaltstart..DataAbort sollte es kein Problem geben, aber für die beiden letzten (INT und FIQ) mußt du dir dann etwas einfallen lassen. W.S.
Ist jetzt nicht böse gemeint aber ich hab das alles schon beachtet was du erwähnt hast. Es gibt ein Datenblatt in dem die Peripherie beschrieben ist. Man kann auch die Datenbusbreite umstellen. Über einen Pin wird festgelegt, von welchem Medium gebootet wird (wenn man im Factory Programming Mode ist, springt die CPU in den Speicherbereich des internen Boot-ROMs der dann das Beschreiben des internen SRAMs zulässt, so hab ich das Datenblatt zumindest verstanden). Und ja, die CPU ist knapp 17 Jahre alt. Und ja, der Name ist irrelevent wenn es einem darum geht wie man eine unbekannte CPU mit IAR / Keil zum laufen bekommt. Das Wort UNBEKANNT steckt ja schon im Satz. Keine Ahnung warum du aus einer Maus einen Elefanten machst. Ich glaub du hast wenig Ahnung.
Max M. schrieb: > Ich glaub > du hast wenig Ahnung. Von diesem speziellen Chip? Logisch. Den hab ich noch nie wissentlich in Händen gehabt. Naja, vielleicht in Form eines Mobiltelefons - aber nicht näher. Und wenn du denn schon zuvor alle Informationen und Unterlagen hattest, warum machst du hier dann so ein Faß auf? Selbst die Information über den NAMEN des Chips mußte dir erstmal mühsam aus der Nase gezogen werden. Macht es dir Spaß, hier andere zu mobilisieren, sich all das auszudenken, was dir möglicherweise weiterhelfen könnte - und dann heimlich über die anderen zu grinsen? Du hast ganz offensichtlich die Hilfsbereitschaft der Forenteilnehmer überstrapaziert. Sowas macht man nicht, sondern man legt gleich im Eröffnungspost offen, was los ist, welchen Stand man hat und wo die Hürde ist, die man grad niicht nehmen kann. So sag ich dir hiermit eines: Für Fragen des Einsatzes des JLink's bei ARM7TDMI befrage dessen Hesteller. W.S.
Keine Ahnung was mit dir falsch gelaufen ist. Ich hab nie nach Hilfe für speziell diese CPU gefragt und um JLink geht es mir gar nicht, das ist eh nur Mittel zum Zweck. Wie man eine nicht unterstützte CPU in IAR einpflegen kann hat Michael dankenswerterweise beantwortet. Du strapazierst hier höchstens deine Nerven mit den Posts die du von dir gibst.
:
Bearbeitet durch User
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.