Ich habe das Atmel Cortel M3 Evaluation Board zugelegt. Das Board
besitzt einen Atmel SAM3U µC.
Laut Atmel soll der SAM-ICE von Segger für den Download der Firmware
verwendet werden können. Jedoch habe ich es weder mit dem IAR-IDE noch
mit Keil hinbekommen.
Die Firmware auf dem Segger SAM-ICE ist bereits von 2008. Ich habe alles
von Segger heruntergeladen und installiert. Jedoch konnte ich keine
Firmwareupgrade auf dem SAM-ICE durchführen.
Zu welchen DOWNLOADER und DEBUGGER könnt ihr mir raten?
Ich möchte keinen Open Source Compiler verwenden. Demach sollte er
leicht in die IDE IAR oder Keil implementierbar sein.
Ich habe bei Segger gelesen das momentan der J-Link das aktuelle Produkt
ist und dies auch mit IAR und Keil benutzbar ist.
Hat jemand schon den J-Link ausprobiert?
Servus,
habe hier in der arbeit einen Ulink2. Geht gut aber ein bisserl teuer.
Kann aber dafür trace und auch SWD.
Den Segger EDU hab ich Zuhause. Billig und für daheim echt super. Kann
auch SWD aber soweit ich weiß keinen trace. Aber muss gestehen hab ich
daheim auch noch nicht probiert.
Der Ulink geht halt nur mit Keil der Segger auch mir Eclipse oder
ähnlichen IDE's.
Gruß
Stumpf
Johann schrieb:> Hat jemand schon den J-Link ausprobiert?
Das SAM-ICE von Atmel ist ein Segger J-Link.
Benutzt habe ich ihn schon, aber für die SAM3s bekommst du wohl nicht
mehr (wie früher) die Software von Segger kostenlos (limitiert auf
die Benutzung mit Atmel-Controllern). Die älteren Versionen wiederum
weigern sich, mit SAM3 zu arbeiten.
Daraufhin habe ich den Segger-Softwarekrempel in die Ecke geworfen und
OpenOCD benutzt. Geht astrein, und ist mir (im Gegensatz zu dir)
letztlich ohnehin lieber gewesen, da die Toolchain davor bei mir auch
Opensource ist.
Johann schrieb:> Laut Atmel soll der SAM-ICE von Segger für den Download der Firmware> verwendet werden können. Jedoch habe ich es weder mit dem IAR-IDE noch> mit Keil hinbekommen.
Hi,
der blaue JLink a'la SAM-ICE sollte mit der Keil µVision funktionieren.
Als Debugger dann JLink auswählen.
VG,
/th.
Johann schrieb:> Ich möchte keinen Open Source Compiler verwenden. Demach sollte er> leicht in die IDE IAR oder Keil implementierbar sein.
Schau dich doch einmal bei Raisonance (http://www.raisonance.com/) um.
Ich habe bei Keil auf JLink umgestellt. Jedoch bekomme ich ich immer
einen Hinweis das es neuere Version gibt.
Außerdem bekomme ich immer einen Errror wenn ich das Blink
Beispielprogramm draufspielen will.
Die neuen JLINK sind jedoch schwarz und habe einen anderen Inhalt.
Deshalb dachte ich das ich den mal ausprobieren. Kostet zwar fast 400€
der neue JLink das spielt jedoch momentan keine Rolle.
Von Open Source bin ich momentan geheilt. Irgendwas geht doch immer
nicht. Miestens ist alleine schon die Installation sehr aufwendig.
"früher" gab es JTAG. Dieses IF wurde nun etwas eingedampft, auf eine
Serial Wire Debug (SWD), mit einem Serial Wire Out (SWO) Pin. Das
zusammen ergibt das SWJ (Serial Wire/JTAG), wenn der Controller beides
unterstützt.
Dazu parallel gibt es noch das 1-4Bit/Pin Trace Interface.
An Trace-fähigen Units gibt es die DWT (Data Watch & Trace), die ITM
(Instrumentation Trace Unit) und die ETM (Embedded Trace Macrocell).
Die DWT kann Speicherzellen (z.B. Variablen) Tracen und ausgeben.
Weiterhin ermöglicht sie komplexe Breakpoints, z.B. "Break when 'x' is
read" oder "Break when x==0x55".
In µVision wäre das (Command Window):
BS READ myVar
BS READWRITE myVar==0x55
Dafür hat die DWT 4 Units. Ein einfacher Watch (Variablenwert ausgeben
oder BP) erfordert eine Unit. Ein komplexer BP (myVar==0x55) erfordert 2
Watches.
Die ITM hat 32 output-channels, über die das Userprogramm auf der CPU
Informationen ausgeben kann.
ITM kann weiterhin alle n Instructions (Divder einstellbar) den PC
samplen und ausgeben, sowie die ISR Entry/Exit/Returns ausgeben. Das
ermöglicht ein rudimentäres Trace.
Die ETM Unit ermöglicht ein vollständiges Tracing.
Diese 3 Units werden über die Trace Port Interface Unit (TPIU) zu einem
Datenstrom zusammengefasst, und über den SWO Pin oder das 1-4Bit Trace
Interface ausgegeben.
Anm.: ETM über SWO macht keinen Sinn und ist deswegen idR. nicht
auswählbar.
------
Ab hier kann ich nur für µVision / ULINK sprechen:
Der ULINK2 kann den SWO Pin samplen, und die Informationen auf
verschiedene Fenster ausgeben.
Bei ITM sind die channel 0 und 31 lt. CMSIS Standard für printf (Ch.0)
und RTOS Status (Ch.31) reserviert.
Im µVision landen die ITM Ch.0 Ausgaben im ITM printf Viewer. Das ist
ein Terminal mit grundlegender VT100 Funktion, weiterhin kann man die
Daten als reine ASCII, HEX oder im ASCII/HEX Mixed Mode ansehen.
Die RTOS Daten landen im µVision Falle (RTX) im RTX Status Window und im
Event Viewer, der die Taskwechsel anzeigt.
---
Der ULINK pro unterstützt den 1-4Bit Trace Port und den SWO in Full
Speed (jenseits 100MHz, genaue Zahl weiss ich gerade nicht). Die
Funktionalität ist hier wie die vom ULINK2 (allerdings Faktoren
schneller), zusätzlich kann ein vollständiger Trace aufgenommen werden.
Diesen kann man sich entweder im Trace Window anzeigen lassen zur
Fehlersuche (z.B. bei Hard Fault), oder einfach nur als Code Coverage
nutzen.
Zur Übertragung mit höherer Bandbreite können die ITM Daten auch per
4Bit Trace Port übertragen und in ein File geloggt werden (macht Sinn
für ITM Ch. 1-30).
VG,
/th.
Johann schrieb:> Die neuen JLINK sind jedoch schwarz
Das blau ist halt die Atmel-Farbe, die Segger deren OEM-Version dann
verpasst. Inhaltlich hat sich von der Hardware meines Wissens nichts
geändert (zumindest sollten sie aufwärtskompatibel sein).
> Außerdem bekomme ich immer einen Errror wenn ich das Blink> Beispielprogramm draufspielen will.
...
> Von Open Source bin ich momentan geheilt.
Naja, deine Aussage "irgendwas geht doch immer nicht" trifft wohl hier
gerade genauso zu. Selektive Wahrnehmung?
Aber du hast doch für die Software was bezahlt, damit solltest du doch
deren Support befragen können, wie man das SAM-ICE damit nun zum Laufen
bekommt.
> Die neuen JLINK sind jedoch schwarz und habe einen anderen Inhalt.
JLinks gibtz in allerlei Gewand :-)
Schwarz: Original JLink, kommerziell nutzbar
Weiss : Original JLink, Education Version (mMn. eine schlaue Antwort
auf die China Replikate)
Blau : SAM-ICE, der spricht nur mit Atmels µCs
Gelb : IAR, der mag nur die IAR Toolchain
Schwarz, anderes Gehäuse: mIDAS, Analog Devices Version
OnBoard: Ein mit auf das Board gelöteter Microcontroller, der den JLink
enthält. Z.B. bei EnergyMicro oder Freescale/Kinetis.
Vielleicht gibtz noch andere, aber mehr hab ich noch nicht in den
Fingern gehabt :-)
VG,
/th.
Johann schrieb:> Außerdem bekomme ich immer einen Errror wenn ich das Blink> Beispielprogramm draufspielen will.
Was für einen Fehler bekommst du?
In Keil µVision:
Der JLink muss unter "Debug" und "Utilities" der Target Options
eingestellt sein.
Hier wird unterschieden, weil zwei verschiedene Debugger verwendet
werden können, z.B. NXP FlashMagic nur zum Flashen.
Weiterhin muss unter den Settings für den JLink bei "Debug" JTAG oder SW
(je nach Anwendung oder was der µC kann) ausgewählt sein. Soll SWO
verwendet werden, muss hier SW eingestellt sein!
Unter Trace kann man dann Trace enablen und den ITM Ch.0 auswählen, für
CMSIS printf (retargeting fputc -> ITM_SendChar() nicht vergessen!).
Unter Flash Download muss der korrekte Flash Algorithmus ausgewhlt
werden.
Ist alles korrekt eingestellt, sollte der JLink die MCU flashen &
debuggen.
VG,
/th.
Random ... schrieb:> Schwarz: Original JLink, kommerziell nutzbar
Meiner ist auch schwarz, aber ich darf ihn nicht kommerziell nutzen. Er
war der Vorläufer der Education Version (none commercial).
Also rein die Gehäusefarbe als Kriterium reicht nicht.
Johann schrieb:> Was ist denn TRACE und SDW?>> Der Keil ULINK2 kostet ja 500€ und die Pro sogar über 1000€
Bei Ebay habe ich schon preiswertere Versionen gesehen.
900ss D. schrieb:> Random ... schrieb:>> Schwarz: Original JLink, kommerziell nutzbar>> Meiner ist auch schwarz, aber ich darf ihn nicht kommerziell nutzen. Er> war der Vorläufer der Education Version (none commercial).> Also rein die Gehäusefarbe als Kriterium reicht nicht.
ok. Ich schrieb ja auch, das ich nur die gelistet hab, die ich selber
hier liegen habe. Irrtümer vorbehalten :-)
Trotzdem ein guter Zug vom Segger. Ich würde mir jedenfalls zum Basteln
keine China Kopie kaufen, wenn ich das Original für nen Fuffi krieg :-)
Random ... schrieb:> Jörg Wunsch schrieb:>> Naja, deine Aussage "irgendwas geht doch immer nicht" trifft wohl hier>> gerade genauso zu. Selektive Wahrnehmung?>> Gerade aktuell:> Beitrag "Eclipse: "cannot run program make" + findet GDB-command nicht"
Ja, Fehler: ein Plugin war nicht richtig installiert ... kann einem
mit kommerzieller Software natürlich nieee passieren. ;-)
Mir ging's ja auch nur darum, dass bei "opensource irgendwas immer
nicht geht", während im gleichem Atemzug beklagt wird, dass Keil
(und wohl auch IAR) genauso ihren Kuddelmuddel bereiten. Systeme
dieser Komplexität neigen halt immer mal dazu, irgendwo Spirenzchen
zu machen, egal ob Opensource oder kommerziell. Wenn ich mir
überlege, wie viele Stunden ich schon vertrödelt habe nur für das
$@!#&e Lizenzgewurschtel von IAR, und was man hätte in der gleichen
Zeit sinnvolles tun können. Oder eben besagte Segger-Software, da
hatte ich ernsthaft erwartet, dass der Betrieb des SAM-ICE damit
schneller zu haben wäre als mit OpenOCD (das in der Tat erstmal einen
gewissen Einarbeitungsaufwand bezüglich der Konfiguration braucht).
Pustekuchen! Ich hätte mir die Segger-Software dann auch gleich
klemmen können und die dafür vertrödelte Stunde Zeit zum Studium
der OpenOCD-Doku benutzen können, das wäre sinnvoller investiert
gewesen. Der Kram tut wenigstens, nachdem er einmal konfiguriert
ist, statt mir an den Kopf zu werfen, dass ich nun (trotz SAM-ICE +
Atmel-MCU) noch extra Geld für eine Lizenz blechen solle.
Vorsicht, meine Meinung:
Hast nicht ganz Unrecht, die Komplexität ist nun mal sehr hoch. Ich kann
hier nur für µVision und etwas Open Source für ARM und AVR sprechen.
Bis ich bei meinem AVR Einstieg vor etlichen Jahren (AVR Studio
unterstützte damals nur ASM, WinAVR war das Compilerpaket) alles
zusammenhatte, was ich an make, compiler, script etc. brauchte, das war
schon ein Weilchen. Ausserdem hab ich im Wesentlichen an dem Dingen C
gelernt.
Dann hab ich mal mit Code Sourcery und Ride rumgespielt, auch das lief
nicht von Anfang an (aber schon besser).
Mit IAR hab ich auch ein wenig gearbeitet, aber zu wenig, als dass ich
etwas drüber sagen könnte.
Das Keil µVision war - als ich damals meine DA geschrieben habe,
wirklich ein sehr hilfreiches Überraschungspaket, was tatsächlich
out-of-the-box funktionierte, sodass ich mich voll auf auf das
Kennenlernen der ARM Welt am Beispiel von LPC2148 und LMI3S828 (Luminary
Cortex-M3) konzentrieren konnte - und das allein war als Umstieg von AVR
schon mehr als genug!
Mittlerweile arbeite ich sehr gerne auf beiden Seiten des Keil µVision
sowie mit diversen Cortex-M3 MCUs (vorwiegend STM32F107 und LPC1768),
und möchte beides nicht mehr missen :-)
Vor allem bekommt man bei einem kommerziellen Produkt ein mindestens
gutes Gesamtpaket aus IDE/Debugger und Middleware, was auch
zusammenspielt. Bei meinem derzeitigen Bastelprojekt hätte ich überhaupt
keine Lust, mir die ganzen Open Source Komponenten für ein RTOS, TCP
Stack, USB Stack, Flash FileSystem etc. erst zusammenstückeln zu müssen.
Das Zeug "läuft einfach" und vor allem, es läuft zusammen!
VG,
/th.
Danke für die Infos Random
Ich habe bis jetzt nur die Testversion, daher kann ich leider den
Support nicht fragen :-)
Ich bin mir noch nicht sicher ob es die IAR oder die Keil Version sein
wird, deshalb wollte ich beide mal ausprobieren indem ich das
Beispielprojekt durcharbeite.
Nun zu meinem Fehler. (Ich kann es erst heute Abend genau beschreiben,
da ich die Hardware gerade zu Hause habe)
Ich habe den Debug auf JLink umgestellt. Jedoch erinnerich ich mich wage
das der Fehler mit dem korrekten Flash Algorithmus zu tun hatte. Was
muss ich denn da wo einstellen? Gibt es dazu ein Tutorial für die Atmel
Cortex M3.
Da ich nur die Cortex M3 von Atmel benutzen wollte werde ich dann beim
blauen Segger JLink bleiben.
Bis jetzt habe ich noch keinen Flash Algo ausgewählt, da ich ja den
internen Flash vom Atmel Cortex M3 verwenden wollte.
Bis jetzt hatte ich halt nur mit den Atmel 8 Bit µC einige Jahre zu tun.
Da gibt es den Codevision den muss man nur installieren und dann geht
alles wie von Zauberhand :-)
Johann schrieb:> Danke für die Infos Random
null problemo :-)
> Ich habe bis jetzt nur die Testversion, daher kann ich leider den> Support nicht fragen :-)
Kannst mich gern fragen, was du wissen musst. Ich schau tagsüber immer
mal wieder hier rein.
> Ich bin mir noch nicht sicher ob es die IAR oder die Keil Version sein> wird,
Wenn du Fragen zur Keil IDE oder zur verfügbaren Middleware hast, frag
einfach. Bei IAR kann hier sicherlich jemand anderes weiterhelfen.
> deshalb wollte ich beide mal ausprobieren indem ich das> Beispielprojekt durcharbeite.
Da ist der JLink immer die beste Wahl, weil der von diversen IDEs
unterstützt wird.
> Nun zu meinem Fehler. (Ich kann es erst heute Abend genau beschreiben,> da ich die Hardware gerade zu Hause habe)>> Ich habe den Debug auf JLink umgestellt. Jedoch erinnerich ich mich wage> das der Fehler mit dem korrekten Flash Algorithmus zu tun hatte. Was> muss ich denn da wo einstellen? Gibt es dazu ein Tutorial für die Atmel> Cortex M3.
Schau einfach mal in ein Beispielprojekt:
c:\keil\ARM\Boards\
Die sollten auf SAM-ICE oder ULINK konfiguriert sein. Such deinen Chip
raus, und schau nach, was für ein Flash Algo da eingestellt wurde.
> Da ich nur die Cortex M3 von Atmel benutzen wollte werde ich dann beim> blauen Segger JLink bleiben.>> Bis jetzt habe ich noch keinen Flash Algo ausgewählt, da ich ja den> internen Flash vom Atmel Cortex M3 verwenden wollte.
Keil µVision unterstützt das eigene Flashen des JLink derzeit nicht.
Daher musst du zum Flashen den richtigen Flash Alg. einstellen.
Project -> Options for Target (Oder den kleinen Zauberstab) -> Utilities
-> JLink auswählen -> Settings
VG,
/th.
Wenn ich das richtig sehe dann wird der Cortex M3 von dem SAM-ICE nicht
unterstützt. siehe Datensheet Seite 44.
Dort steht das alles unter J-Link Version 8 keinen Cortex M3
unterstützt.
http://www.farnell.com/datasheets/1509847.pdf
Johann schrieb:> Dort steht das alles unter J-Link Version 8 keinen Cortex M3> unterstützt.
Gut, meins ist eine V8.0.
Kommt denn Keil mit einem simplen Wiggler klar, oder mit einem
einfachen FT2232-basierten JTAG-Adapter? Unter OpenOCD habe ich
beides schon alternativ zum SAM-ICE benutzt.
Jörg Wunsch schrieb:> Kommt denn Keil mit einem simplen Wiggler klar, oder mit einem> einfachen FT2232-basierten JTAG-Adapter? Unter OpenOCD habe ich> beides schon alternativ zum SAM-ICE benutzt.
Hi,
"klarkommen" ist nicht das Problem, das Interface ist offen. Die Frage
ist, ob es einen AGDI Treiber für die Debug-Unit für µVision gibt.
http://www.keil.com/appnotes/docs/apnt_173.asp
VG,
/th.
Random ... schrieb:> "klarkommen" ist nicht das Problem, das Interface ist offen. Die Frage> ist, ob es einen AGDI Treiber für die Debug-Unit für µVision gibt.
Das würde für mich natürlich "klarkommen" implizieren. Wenn ich dir
sage, dass OpenOCD mit allen drei Varianten klar kommt, dann meine
ich ja auch nicht, dass du prinzipiell die Möglichkeit hast, dir den
Sourcecode dafür zu schreiben ;-), sondern dass selbiger bereits
existiert und funktioniert.
Ne leider läuft es nicht. Ich war gestern Abend krank. Ich habe den
neuen J-Link bei Farnell bestellt. Dort stand leider nicht welches
Version es ist. Ich hoffe mal das es die VErsion 8 ist,
Den FTDI 2232 verwende ich sehr oft als USB-High Speed. Den kann man
auch als JTAG betreiben. Wie bereits oben beschrieben kommt es auf den
Preis nicht an.
Der neue J-Link müste morgen da sein dann werde ich diesen auch gleich
ausprobieren
Wie teuer ist denn der Keil Compiler?
So ich habe nun den neuen J-Link Verion 8 bekommen. Damit ging es mit
dem IAR-Compiler gleich.
Achtung falls jemand Windows 7 verwendet, bitte installiert den Compiler
direkt unter c:\IAR oder c:\Keil
Bitte nicht unter Program Files(x86) da hat man nur eingeschrenkte
Rechte unter Windows 7, dadruch enthält man nur Fehler beim compilieren
und Debuggen.
Ich habe anschließend den IAR-Compiler deinstalliert und anschließend
unter c:\IAR installiert und schon lief alles sofort
ich hab keineerlei probleme damit IAR unter Program Files (x86)
auszuführen.
man sollte seine Projekte nur nicht im programm verzeichniss ablegen.
sondern wo anders. Das verzeichniss ist für programme da, nicht für die
eigenen daten!
Jörg Wunsch schrieb:> Kommt denn Keil mit einem simplen Wiggler klar
Erstmal nö.
Keil kommt mit jedem JTAG-Adapter klar, für den es eine Treiber-DLL im
System hat. Wenn also jemand für nen Wiggler oder ein Xilinx-Kabel#3
oder einen Altera-Byteblaster (oder nochwas anderes) eine passende DLL
schreibt, dann kommt Keil auch damit klar.
Guck dich mal bei Nuvoton um. Die haben sich einen eigenen billigen
Programmieradapter auf Basis ihrer eigenen Chips gebastelt und dafür
gibt es nen Treiber für Keil.
W.S.
