ARM flashen per SWD

Ich kann nur empfehlen: Kauf dir ein j-link edu. Das kostet einmal Geld, 
spart aber eine Menge Frust an anderer Stelle. Fertige Bastellösungen 
die das SWD-Protokoll können kenne ich nicht. Und selbst wenn hast du 
immer noch das Henne-Ei-Problem. Beim ersten Versuch auf einem ARM 
sollte man sich wenigstens auf irgendwas verlassen können. Wenn deine 
komplette Entwicklungskette neu ist hast du ohnehin das Problem, dass du 
nicht weißt wenn's nicht geht wer denn nun Schuld ist. Dann auch noch 
ein selbst gebastelter SWD-Adapter dessen Funktions man nicht mal 
evaluieren kann?
Ich hatte mit STM32/Atolic sowie LPC1xxx/LPCXpresso angefangen. Da 
kriegt man erst mal ein Gefühl für das Ganze. Aktuell verwende ich 
Crossworks mit jlink. Mit Eclips in jeder Form stehe ich auf Kriegsfuß. 
Keil ist für den Anfang auch zu empfehlen. Solange die 32k reichen. Der 
Debugger (auch der von Crossworks) ist Lichtjahre besser als das 
Eclips-Geraffel.
Trotzdem schreibe ich für meine Projekte immer noch makefiles für die 
gnu-arm-Tools und gebe nicht auf bis das auch damit läuft. Damit lernt 
man sehr schnell und manchmal schmerzhaft was die IDE's teilweise 
verstecken.

avr3 schrieb:
> Der
> Debugger (auch der von Crossworks) ist Lichtjahre besser als das
> Eclips-Geraffel.
Das verstehe ich nicht ganz; Crossworks verwendet einfach nur den GDB 
(zB mit dem J-Link GDB Server). D.h. erstmal gibt es gar keinen Debugger 
von Crossworks. Den GDB bindet man typischerweise auch in eclipse ein 
(wie es bei Atollic schon voreingestellt ist), d.h. man verwendet genau 
den selben Debugger, nur eben mit anderer GUI. Ist die eclipse-GUI so 
unfassbar schlecht?

Kindergärtner schrieb:
> Das verstehe ich nicht ganz; Crossworks verwendet einfach nur den GDB
> (zB mit dem J-Link GDB Server). D.h. erstmal gibt es gar keinen Debugger
> von Crossworks. Den GDB bindet man typischerweise auch in eclipse ein
> (wie es bei Atollic schon voreingestellt ist), d.h. man verwendet genau
> den selben Debugger, nur eben mit anderer GUI. Ist die eclipse-GUI so
> unfassbar schlecht?

Crossworks verwendet nicht den GDB-Server sondern wie Keil auch die dll 
bzw. so.
Die GUI des Debuggers und der Funktionsumfang ist Sache der IDE. Wenn 
man nur mal mit LPCXpresso rum spielt merkt man nicht, dass einiges an 
Peripherie in der SFR-Ansicht disabled ist. Das geht dann erst bei den 
Kaufversionen. Atollic für STM32 und LPCXPresso für LPC1xxx und dann 
noch 5 andere Eclips-varianten für andere Cortexe? Das ist zu viel.
Ich finde Eclips unfassbar schlecht, ja. Kann anderen durchaus anders 
gehen. Mir reicht von der Sache aber auch ein einfacher Editor.
Es gibt Leute die brauchen keinen Debugger oder nur die rudimentären 
Sachen davon. Ist bei mir nicht der Fall. Und der Workflow vom 
Übersetzten bis zum ersten Breakpoint ist gefühlt mit Keil bzw. 
Crossworks 5mal schneller als mit den Eclips-Lösungen. Coocox ist in 
dieser Beziehung das aller letzte.
Aber wie gesagt, dass ist meine, wenn auch subjektive Meinung. ich habe 
das alles mal probiert und die Entscheidung so für mich getroffen.
In Fragen Lizenzpolitik ist Crossworks durch keinen andere kommerzielle 
IDE zu schlagen. Lizenziert wird pro User und nicht pro Rechner. Und ich 
kann prima meine externen Projekte debuggen die mit den gnu-arm-tools 
übersetzt sind und keine einzige Zeile Quellcode von Crossworks oder 
irgendeine Lib der IDE verwenden.

kaufe dir das Board hier: FRDM-KE02Z

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-KE02Z

da ist ein Programmer schon drauf und du kannst damit auch den schon 
vorhandenen Stecker zum externen Programmieren verwenden.

>gerade eben habe ich meine ersten ARM-Chips (Freescale MKE02Z64VQH2)
>bestellt. Jetzt wollte ich langsam mit der ersten Leiterplatte anfangen
>und weiß überhaupt nicht, wie man ein Programm ins Flash bringt.

Warum kaufst du die dann?

>Wie schätzt ihr die Chancen, dass ich einem 8-Bitter das SWD-Protokoll
>beibringe und den "großen" darüber flashe?

Geht gegen Null.

avr3 schrieb:
> Crossworks verwendet nicht den GDB-Server sondern wie Keil auch die dll
> bzw. so.
Ah tatsächlich. hat scheinbar den nachteil dass Crossworks (laut Doku) 
dafür aber nicht alle vom J-Link unterstützden Prozessoren kann (wie 
ARM11 und Cortex-A,R). Der Vorteil am GDB ist halt dass man auf 
Frontendseite ein einheitliches Interface hat und man so mit einer 
einzigen GUI (wie ddd oder eclipse etc) quasi alle erdenklichen Targets 
erreicht, ohne dass man dort explizit für jeden Programmer/Debugger 
etwas programmieren müsste.

avr3 schrieb:
> Atollic für STM32 und LPCXPresso für LPC1xxx und dann
> noch 5 andere Eclips-varianten für andere Cortexe? Das ist zu viel.
Das ist halt Atollic "schuld", dass die eclipse derart verunstaltet 
haben. Man kann auch ein "jungfräuliches" Eclipse nehmen und dort alles 
derart installieren/konfigurieren dass es alles Prozessoren und auch 
noch ganz andere Sprachen wir ruby oder java kann, alles in einem 
Programm.

avr3 schrieb:
> Ich finde Eclips unfassbar schlecht, ja.
Es ist halt sehr mächtig & flexibel, daher kann man nicht  mit 3 Clicks 
eine spezifische Funktionalität erreichen. Wenn (falls) man es aber 
konfiguriert kriegt funktionierts ganz gut.

avr3 schrieb:
> Und der Workflow vom
> Übersetzten bis zum ersten Breakpoint ist gefühlt mit Keil bzw.
> Crossworks 5mal schneller als mit den Eclips-Lösungen.
Jo. Dafür kann man in eclipse auch zB Java-Breakpoints setzen (zur 
Entwicklung der PC-Gegenstelle eines Programms) ohne für jede Sprache 
eine eigene IDE zu benötigen...

avr3 schrieb:
> Aber wie gesagt, dass ist meine, wenn auch subjektive Meinung.
Tjo...

avr3 schrieb:
> In Fragen Lizenzpolitik ist Crossworks durch keinen andere kommerzielle
> IDE zu schlagen.
Dafür ist eclipse, GDB, GCC komplett opensource :o)

gnd3 schrieb:
> Für ARM mit
> JTAG gibt's entsprechend einen 20-poligen oder einen 9-poligen Stecker.
> Aber der MKE02 kennt nur noch SWD - gibt's dafür schon einen
> Standard-Stecker?

SWD ist neben JTAG die HW-Schnittstelle die üblicherweise bei den ARMs 
verwendet wird. Die Schnittstelle ist im Prozessor integriert (siehe 
Datenblatt). Üblicherweise ist die Schnittstelle vom Prozessoer auf den 
10(9)-poligen Mini-JTAG oder den 20-poligen großen JTAG Stecker 
aufgelegt. Welchen Du verwendest ist ziemlich egal, Du kannst sogar 
einen eigenen "erfinden" - die Stecker sind jedoch empfohlen. 
Üblicherweise liegt die SWD-Schnittstelle auf dem 20-poligen großen 
Stecker auf.

So und jetzt zur Seite des PCs.
Dort brauchst Du ein Programmiergerät das die SWD-Schnittstelle der ARMs 
unterstützt. SW Diskussion siehe oben. Dami9t kannst Du schon 
üblicherweise flashen. Musst Du nur noch die beiden verheiraten, heißt 
also eletromechanisch komaptibel machen (20 polige Buchse auf 20-poligen 
Stecker oder Adapter). Fertig.

rgds

erstmal herzlichen Dank für alle Antworten!

avr3 schrieb:
> Kauf dir ein j-link edu.
user schrieb:
> kaufe dir das Board hier: FRDM-KE02Z

Eigentlich habe ich schon so etwas wie ein j-link, das meldet sich so:
#
  idVendor           0x1366 SEGGER
  idProduct          0x0101 J-Link ARM
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
#
nur, was kann ich damit anfangen?

Von den beiden gewinnt also ganz klar das FRDM weil es (laut Werbung) 
keine Software auf dem PC braucht:
#
FRDM-KE02Z comes with the mass-storage device (MSD) Flash Programmer 
OpenSDA Application preinstalled.

The MSD Flash Programmer is a composite USB application that provides a 
(...) an easy and convenient way to program applications into the KE02Z 
MCU. It emulates a FAT16 file system, appearing as a removable drive in 
the host file system with a volume label of FRDM-KE02Z. Raw binary and 
Motorola S-record files that are copied to the drive are programmed 
directly into the flash of the KE02Z and executed automatically.
#
Genial, genau so muss das sein. Und das für gute 10 Euro, ich bestelle 
gleich 2 oder 3 ;)

Dass das FRDM nur den KE02 versteht ist natürlich ganz schlecht. 
Eigentlich sollten ja alle ARM gleich sein, und besonders per SWD. ABER: 
der Flash-Speicher ist ja von Chip zu Chip unterschiedlich, also muss 
das Programmiergerät jeden einzelnen Chip kennen. Insofern wäre ich mit 
dem j-link auch nicht besser dran, wenn es um neue Chips geht.


holger schrieb:
> Warum kaufst du die dann?

Weil der S9S12G..LC nicht lieferbar ist. Der und der KE02 kommen im QFP 
mit 0.8mm Pitch, ansonsten gibt es nur 0.5mm oder QFN oder BGA. Außerdem 
sollte ich dankbar sein, dass ich mich jetzt mit ARM beschäftigen darf, 
das wurde doch endlich mal Zeit ;)

holger schrieb:
> >Wie schätzt ihr die Chancen, dass ich einem 8-Bitter das SWD-Protokoll
> >beibringe und den "großen" darüber flashe?

> Geht gegen Null.

Meinst du wegen fehlender/schlechter Doku? Früher wäre eine (vom Prinzip 
her) so einfache Schnittstelle im Datenblatt so genau beschrieben 
gewesen, dass ich gekaufte Lösungen garnicht in Betracht gezogen hätte. 
Aber nachdem Freescale sich da auf ARM verlässt, bin ich wohl auch 
verlassen.


6A66 schrieb:
> Üblicherweise ist die Schnittstelle vom Prozessoer auf den
> 10(9)-poligen Mini-JTAG oder den 20-poligen großen JTAG Stecker
> aufgelegt. Welchen Du verwendest ist ziemlich egal, Du kannst sogar
> einen eigenen "erfinden"

einen eigenen wollte ich ja vermeiden; ich dachte nur, evt. gibt's 
inzwischen einen ohne JTAG-Pins. Dann bleibe ich beim 9-poligen, es gibt 
eh' schon genug Standards.

6A66 schrieb:
> So und jetzt zur Seite des PCs.
> Dort brauchst Du ein Programmiergerät das die SWD-Schnittstelle
> der ARMs unterstützt.

witzigerweise hat mich die Suche nach segger j-link zu openOCD mit 
FT2232 geführt. Das wäre die Lösung ohne Programmiergerät. Den FT2232 
bringe ich schon noch unter, notfalls auf der Lötseite ;)

Nochmal vielen Dank, jetzt sehe ich schon klarer...

gnd3 schrieb:
> Eigentlich habe ich schon so etwas wie ein j-link, das meldet sich so:
> nur, was kann ich damit anfangen?
Wie schafft man es sich einen J-Link zu kaufen ohne in der Lage zu sein 
auf die Website (segger.com) zu gehen und sich die Anleitung anzusehen? 
Da steht alles haarklein erklärt...

gnd3 schrieb:
> Genial, genau so muss das sein. Und das für gute 10 Euro, ich bestelle
> gleich 2 oder 3 ;)
Toll, dafür kann man damit nicht debuggen...

gnd3 schrieb:
> Meinst du wegen fehlender/schlechter Doku? Früher wäre eine (vom Prinzip
> her) so einfache Schnittstelle im Datenblatt so genau beschrieben
> gewesen,
Da das SWD eine Menge kann ist das eben nicht mehr so einfach (wie zB 
beim AVR).

gnd3 schrieb:
> Früher wäre eine (vom Prinzip
> her) so einfache Schnittstelle im Datenblatt so genau beschrieben
> gewesen, dass ich gekaufte Lösungen garnicht in Betracht gezogen hätte.

Ich habe gute Nachrichten für dich. Du brauchst nichts zu kaufen, 
sondern lade dir einfach die "ARM® Debug Interface Architecture 
Specification" runter. Goggle einfach nach: ARM Debug Interface 
Architecture Specification

Dort steht alles drin was du brauchst :-)

Kindergärtner schrieb:
> gnd3 schrieb:
> > Eigentlich habe ich schon so etwas wie ein j-link, das meldet sich so:
> > nur, was kann ich damit anfangen?
> Wie schafft man es sich einen J-Link zu kaufen ohne in der Lage zu sein
> auf die Website (segger.com) zu gehen und sich die Anleitung anzusehen?
> Da steht alles haarklein erklärt...

Naja, der Weg zu segger.com war nicht so offensichtlich. Es ist ein 
Freescale KwikStik bei dem etwas j-link ähnliches integriert ist. Auf 
den Tipp von avr3 hin hab' ich heute viel über j-link gelesen, aber ich 
glaube immer noch, dass man PC-Software von segger braucht (mindestens 
eine DLL).

Das FRDM-KE02Z läuft zwar auch nur mit geheimer Firmware, aber 
wenigstens brauche ich auf dem PC nichts weiter.
Kindergärtner schrieb dazu:
> Toll, dafür kann man damit nicht debuggen...

Aber es kann flashen -- ohne das Teil kann man nicht einmal eine LED 
blinken lassen. Also ist es eine echte Alternative zum Selbstbau.

Dirk schrieb:
> Goggle einfach nach: ARM Debug Interface
> Architecture Specification
#
This document is only available in a PDF version to registered ARM 
customers.
Non-Confidential Restricted Access
#
na immerhin nicht top secret :) trotzdem danke!

gnd3 schrieb:
> aber ich
> glaube immer noch, dass man PC-Software von segger braucht (mindestens
> eine DLL).
Ja und??? Wo ist das Problem die Software zu installieren? Keil µVision 
hat zB schon alles mitgeliefert was man braucht, da musste nur noch auf 
"Flashen" drücken. Segger liefert sogar GDB-Server für Linux, und dank 
Anleitung ist es auch kein Problem den zu installieren.

gnd3 schrieb:
> bei dem etwas j-link ähnliches integriert
Kann gut sein, Segger liefert die "J-Link-Chips" auch "nackt" zum 
Verbauen durch Weiterverarbeiter.

gnd3 schrieb:
> Aber es kann flashen -- ohne das Teil kann man nicht einmal eine LED
> blinken lassen.
Ach, mit dem J-Link ist mir das aber auch schon gelungen.
> Also ist es eine echte Alternative zum Selbstbau.
Der J-Link ist noch eine viel bessere Alternative. Wenn du schon einen 
der besten JTAG-Flasher&Debugger hast (J-Link), warum bestehst du dann 
noch darauf so eine Frickellösung zu verwenden?!

> Keil µVision hat zB schon alles mitgeliefert was man braucht,
> da musste nur noch auf "Flashen" drücken.

Beitrag "Keil µVision preis"
> 1700,- nur IDE und Debugger, d.h. ohne Compiler

1700,- und wieviel Gigabyte nur zum flashen? Mit dem ganzen IDE-Kram 
kann ich nichts anfangen, sowas muss auf der Kommandozeile 
funktionieren. Außerdem ich bin allergisch gegen "Projekte". Und vor 
allem ist noch garnicht sicher, ob der KE02 überhaupt schon unterstützt 
wird.

Warum soll ich die IDE-Bedienung lernen? Ich muss sowieso verstehen, was 
innen drin wirklich passiert, also kann ich das Makefile auch gleich 
selbst schreiben.

> Wenn du schon einen der besten JTAG-Flasher&Debugger hast (J-Link),
> warum bestehst du dann noch darauf so eine Frickellösung zu verwenden?!

Moment, von der Frickellösung "SWD selbst bauen" bin ich doch schon weg. 
Ich bin überzeugt, dass ich mit dem FRDM-Board schneller zum Ziel komme 
als mit dem J-Link. Wenn das nicht wie in der Werbung funktioniert, 
können wir nochmal verhandeln ;)

Der j-link Unterstützt deine die:

  Freescale MKE02Z16xxx2
  Freescale MKE02Z32xxx2
  Freescale MKE02Z64xxx2

seit Version 4.72 aktuell ist 4.78
http://www.segger.com/j-link-release-notes.html

gnd3 schrieb:
> 1700,- und wieviel Gigabyte nur zum flashen? Mit dem ganzen IDE-Kram
> kann ich nichts anfangen, sowas muss auf der Kommandozeile
> funktionieren. Außerdem ich bin allergisch gegen "Projekte". Und vor
> allem ist noch garnicht sicher, ob der KE02 überhaupt schon unterstützt
> wird.
>
> Warum soll ich die IDE-Bedienung lernen? Ich muss sowieso verstehen, was
> innen drin wirklich passiert, also kann ich das Makefile auch gleich
> selbst schreiben.

Ich habe auch meinen Editor und makefiles. Trotzdem benötige ich einen 
guten Debugger. D.h. einen der mir auch die Peripherie vernünftig 
anzeigt, Watch-Variablen automatisch während des "Runs" aktualisiert 
u.s.w. Breakpoints und stepin, stepout können alle. Das reicht mir 
persönlich aber bei weitem nicht. Und da steckt auch die Arbeit drin. 
Und das für alle erdenklichen ARM-Derivate ist schon eine Leistung die 
man nicht für lau erbringen kann. Für Eclipse in Rohform gibts nur das 
"Eclipse Embedded Systems Register View". Mit gefühlten 20 unterstützen 
Chips...
Wer damit klar kommt ok. Manche brauchen auch gar keinen Debugger. Ich 
könnte aber nicht ohne.
Viele die STM32 benutzen werden sowas auch nicht in der Form benutzen. 
Die arbeiten auf die STM32-Libs und haben mit den Registern nichts am 
Hut. Leider lernt man so aber den µC nicht kennen. Auch nicht mein Ding.

jetzt macht ihr mich langsam nachdenklich, von wegen "guter Debugger". 
Bisher hab' ich für meinen "Haupt-Chip" einen selbst geschriebenen 
Simulator benutzt. Der hat mir natürlich alles angezeigt, was ich sehen 
wollte. Ich bin ja gespannt, wie ich dann ohne den auskomme... und ob 
man für C eher einen Debugger braucht als für Assembler.

gnd3 schrieb:
> Ich bin ja gespannt, wie ich dann ohne den auskomme... und ob
> man für C eher einen Debugger braucht als für Assembler.

Es ist nicht die Frage ob "man" das braucht. Ich habe nur gesagt ich 
brauche das. Und ja, ich kenne es zur genüge auch anders. Z80 
handcodiert ohne Assembler, denn der gerade gebaute "Computer" war der 
einzige den ich hatte. Z8 und 8051 mit Monitorprogrammen, avr 
ausschließlich mit LED an/aus oder printf und UART. Klar geht das auch 
so. Wehe aber man gewöhnt sich mal an einen ordentlichen Debugger, dann 
ist alles andere Krampf.

gnd3 schrieb:
> 1700,- und wieviel Gigabyte nur zum flashen?
Es gibt eine free Version die aber auf 32kB begrenzt ist.
> Mit dem ganzen IDE-Kram
> kann ich nichts anfangen, sowas muss auf der Kommandozeile
> funktionieren.
Tut es glücklicherweise auch, es gibt auch Kommandozeilen-Tools von 
Segger genau dafür. Da musst du nur tatsächlich ein paar Seiten PDF 
lesen um die Bedienung zu erlernen. Hättest du mal auf der Segger Seite 
nachgeschaut wüsstest du das auch.

gnd3 schrieb:
> Warum soll ich die IDE-Bedienung lernen? Ich muss sowieso verstehen, was
> innen drin wirklich passiert, also kann ich das Makefile auch gleich
> selbst schreiben.
Darfst du auch gerne, makefiles haben doch nichts mit flashen & debuggen 
zu tun...

gnd3 schrieb:
> Ich bin überzeugt, dass ich mit dem FRDM-Board schneller zum Ziel komme
> als mit dem J-Link.
Wenn dein Ziel ist "Ein image drauf flashen" dann möglicherweise. Und 
dein Image natürlich schon funktioniert. Wenn dein Ziel aber ist dass du 
auchmal nachschauen willst was da tatsächlich auf der Hardware passiert, 
das flashen auch schnell gehen soll, mit einer Reihe von Prozessoren 
funktionieren soll, wird der J-Link da besser sein. Wenn man schon die 
ganze Debug-Hardware da hat, sich damit unendlich viel Arbeit beim 
Fehlersuchen ersparen kann, warum um die paar Minuten geizen die 
Anleitung vom J-Link zu lesen? Es gibt so viele Fehler da kannst dir 
ohne Watchpoints einen Wolf suchen.

gnd3 schrieb:
> Bisher hab' ich für meinen "Haupt-Chip" einen selbst geschriebenen
> Simulator benutzt.
Wenn du einen Simulator für die STM32 geschrieben kriegst und den 
billiger als Keil anbietest dürftest du damit einiges an Geld verdienen 
können. Aber das wird definitiv länger dauern als das Lesen der 
Anleitung vom J-Link. Die ganzen lustigen Hardwarebugs vom STM32 musst 
du natürlich mitsimulieren.

gnd3 schrieb:
> und ob
> man für C eher einen Debugger braucht als für Assembler.
An sich nicht. Da man aber mit High-Level-Sprachen wie C, C++ 
tendentiell viel mächtigere, komplexere Programme schreiben kann steigt 
die Nützlichkeit eines Debuggers dort drastisch an.

Äh, das ganze gilt natürlich nicht nur für die STM32.