Hallo ! Hab mir für den Einstieg in die ARM-Welt (genauer gesagt Cortex-M3) ein Evaluation Board von Luminary (EKK-LM3S6965) gekauft. Komm mit der Programmierung so weit auch gut zurecht. (Beruflich arbeite ich mit M16C, früher 8051) Hab jetzt aber doch ein paar Fragen zu den Luminary-Teilen: *) Im User-Manual des Boards steht, dass es über die JTAG Schnittstelle andere Luminary Micros programmieren/debuggen kann. Leider finde ich da keine wirklich konkreten Informationen. Wie muss ich das verstehen ? Kann ich einen eigenen Controller über JTAG am EV-Board anschliessen und dann in den Entwicklungsumgebungen (Keil/Crossworks) transparent mit diesen arbeiten ? D.h. kann ich dann einfach den Target Treiber von Luminary auswählen um über das EV-Board (über USB am Computer angeschlossen) meine eigene Hardware programmieren zu können ? *) Was ist der Unterschied zwischen JTAG und diesem SWD ? Hab da bis jetzt nur herausgefunden, dass SWD weniger Pins benötigt. *) Gibt es eine Möglichkeit, eine eigene Hardware (ohne der CPLD-Logik vom EV-Board) so aufzubauen, dass ich über den Luminary Treiber per USB in Keil/Crossworks damit arbeiten kann ? D.h. nur mit einem FT2232 und eventuell ein paar Logikgattern. Wäre nämlich toll, wenn ich für die Anfänge keinen eigenen JTAG-Adapter brauchen würde. Besten Dank und schöne Grüße, Thomas
Ich habe dunkel in Erinnerung, dass diese Erleuchteten mit integriertem Bootloader daherkommen. Damit wäre dann JTAG nicht zwingend.
Ja gut, aber das ist dann ja nur zum Programmieren und nicht zum Debuggen geeignet, oder ?!
Kommt drauf an, wie du üblicherweise zu debuggen pflegst. Mir sind JTAG-Debugger meist zu umständlich. Es gibt Fälle, wo sie nützlich sind, aber i.d.R. reicht mir eine serielle Ausgabe aus, plus ein paar LEDs wenn's zeitkritisch ist. Egal ob ARM oder AVR.
@ Thomas B. 1. & 3. Ein externer Controller wird automatisch erkannt, sobald man ihn angesteckt hat. Die Debug Out LED leuchtet dann. (DB Abschnitt Debugging) Die Logik ist nur zum Umschalten des JTAG-Interfaces gedacht. Daher müsste man auch ein abgespecktes JTAG-Interface ohne die Logik bauen können. Der FT2232 muss dann nur mit den Luminary IDs programmiert werden, damit er auch vom Treiber als Luminary Gerät erkannt wird. 2. http://www.arm.com/products/solutions/SWD.html
Ach naja, ich hab das "Anhalten und Reinschauen" beim Debuggen gerade bei größeren oder komplexeren Programmen doch sehr zu schätzen gelernt. Debug-Ausgaben über die serielle Schnittstelle verwende ich aber auch. D.h. wenn die Möglichkeit da ist, würde ich das schon auch gern nutzen.
Hi Leutz, der JTAG OUT ist wirklich nur ein jtag out; d.h. wenn es funktioniert kann man damit nur andere devices programmieren. Das Doard, auf dem der JTAG Anschluss drauf ist, lässt sich damit weder debuggen noch programmieren. Standard JTAG hat eine Hand voll Pins. SWD steht für Serial Wire Debug, und ist eine Art "Zusammenfassung" einiger JTAG Pins auf eine Leitung. Tipp: Immer das Luminary Unlock Tool zur Hand haben (geht erst ab Chip Rev.C) :-) VG, /th.
Random ... wrote: > der JTAG OUT ist wirklich nur ein jtag out; d.h. wenn es funktioniert > kann man damit nur andere devices programmieren. > Das Doard, auf dem der JTAG Anschluss drauf ist, lässt sich damit weder > debuggen noch programmieren. Was meinst Du damit genau? Über den USB-Anschluss auf dem LMI Board kann man den Controller auf dem Board selbst auch debuggen...
Lt. Auskunft vom Techn. Support von LMI kann man mit dem JTAG OUT auf dem kleinen Lumi EK das Board selbst nicht debuggen oder proggen. Ich wäre da lieber mit dem uLINK drangegangen, aber das Board lässt sich nur über den FTDI JTAG proggen. VG, /th.
Welches LMI Board ist denn für dich klein? Also bei dem EK-LM3S811 geht das genauso und ein kleineres kenne ich nicht.
@Random Also im UserManual zum LM3S9665 Kit steht, dass mit dem Board 3 Varianten funktionieren: "Internal ICDI" (über USB), "ICDI out to JTAG/SWD" (das Board arbeitet als externer Debugger) und "In from JTAG/SWD" (mit ULink, JLink usw.). Was du vielleicht meinst: der Controller des EV-Board ist während der Verwendung als Debugger nicht ansprechbar. Das Unlock-Tool hab ich allerdings auch schon verwenden müssen. Weiß aber nicht genau was ich gemacht habe, da es nach dem Einspielen eines mitgelieferten Demo-Files passierte. Weil du das so explizit schreibst: Tritt das nur bei Verwendung des SWD-Interfaces auf ?? @ Andreas Watterott Du meinst also, dass der CPLD nur zum Umschalten zwischen internem Debuggen und externem Debug-Modus verwendet wird ? Also Umschalten zwischen "Internal ICDI" und "ICDI out to JTAG/SWD" ?
So ist es. Am Ende des DB vom EK-LM3S6965 ist auch ein Schaltplan.
Ja den Schaltplan hatte ich schon gesehen. Nur kann ich so auf Anhieb aus dem Schaltplan der CPLD-Logik nicht herauslesen was das Teil wann macht. (Die Schaltung an sich ist mir klar, nur müsste ich dazu wohl wissen wie genau das JTAG-Protokoll arbeitet). Besten Dank !
Thomas B. wrote: > @Random > Also im UserManual zum LM3S9665 Kit steht, dass mit dem Board 3 > Varianten funktionieren: "Internal ICDI" (über USB), "ICDI out to > JTAG/SWD" (das Board arbeitet als externer Debugger) und "In from > JTAG/SWD" (mit ULink, JLink usw.). Oki, ich meinte das LM3S811 EK Kit. Die Variante von vor ca. 1,5J (ich weiss nciht, wie es jetzt ist) konnte man tatsächlich per JTAG nciht proggen/debuggen, das war nur ein JTAG OUT. > Was du vielleicht meinst: der Controller des EV-Board ist während der > Verwendung als Debugger nicht ansprechbar. s.o. > Das Unlock-Tool hab ich allerdings auch schon verwenden müssen. Weiß > aber nicht genau was ich gemacht habe, da es nach dem Einspielen eines > mitgelieferten Demo-Files passierte. Ich hab mit div. Kits gearbeitet (Vom DEV-Board über EKs), und auch meine DA damit gemacht. Hatte viele Probleme. Dank des guten Support sind wohl die Probs, die ich hatte, mit in die Rev.C eingeflossen, da mittlerweile verschiedene Unlock-Verfahren existieren (LMI Flash Tool hat zwei Gruppen von Devices, und je nachdem welche man auswählt versucht der auf verschiedene Arten, den Core wieder zu erreichen). Es kommt (öfters) vor, dass sich der Controller beim Proggen scheinbar verschluckt und dann nciht mehr erreichbar ist. Wenn das Unlock-Tool hilft, super, wenn nicht, --> Tonne. Rev.B: --> Tonne. Dabei ist es egal, ob man eine Demo verwendet, oder eigenen Code schreibt. Achtung: Nicht ansprechbar per JTAG / USB wird der Core, wenn man die JTAG Pins als GPIO konfiguriert, das ist aber bei allen so. Vertut man sich im Clock Tree (z.B. durch schreiben eines Null-Dividers), dann hilft auch das Unlock Tool nicht mehr (Stand: vor einem Jahr, Rev.C). > Weil du das so explizit schreibst: Tritt das nur bei Verwendung des > SWD-Interfaces auf ?? Egal. > @ Andreas Watterott > Du meinst also, dass der CPLD nur zum Umschalten zwischen internem > Debuggen und externem Debug-Modus verwendet wird ? Also Umschalten > zwischen "Internal ICDI" und "ICDI out to JTAG/SWD" ? Das mit dem CPLD kenne ich noch nicht, das ist neu. Ist auf den alten LM3S811 EKs nicht drauf. VG, /r.
Random ... wrote: > Oki, ich meinte das LM3S811 EK Kit. Die Variante von vor ca. 1,5J (ich > weiss nciht, wie es jetzt ist) konnte man tatsächlich per JTAG nciht > proggen/debuggen, das war nur ein JTAG OUT. Du meinst wahrscheinlich, dass man keinen externen JTAG-Adapter an das Board anschließen kann. -> Das Board hat keinen JTAG-Eingang. Der FT2232 kann aber entweder den onboard Controller oder einen externen MCU debuggen. Ansonsten könnte man den Controller auf dem Kit ja nie über JTAG erreichen.
@Random Hm, dass man ab und zu das Unlock-Tool benötigt hatte ich schon gelesen, aber dass man den Controller dauerhaft aussperren kann wusste ich nicht. Ist dir das passiert ? Ich denke, dass ich die Revision C habe (wegen dem Display), allerdings steht auf der Rückseite "EK-LM3S6965-D" was mich auf eine Revision D schliessen lassen würde - wenn es sie offiziell geben würde.
> *) Gibt es eine Möglichkeit, eine eigene Hardware (ohne der CPLD-Logik > vom EV-Board) so aufzubauen, dass ich über den Luminary Treiber per USB > in Keil/Crossworks damit arbeiten kann ? D.h. nur mit einem FT2232 und > eventuell ein paar Logikgattern. > Wäre nämlich toll, wenn ich für die Anfänge keinen eigenen JTAG-Adapter > brauchen würde. Die Geschichte mit dem FTDI nennt sich OPEN-OCD. Ist für's Hobby nicht schlecht, aber relativ langsam im Vergleich zum ULINK-II oder anderen JTAG Adapter der gehobenen Preisklasse. Ausserdem ist das ein Level Shifter drin, der die Schaltung und den JTAG elektrisch trennt, so dass man normalerweise nur den Level Shifter killt, wenn hardwareseitig was schief geht. Es gibnt ausserdem im Zusammenhang mit STM32 Evalboards einen ULINK in der "light" Ausführung für ca. 100 Euro (zzgl. Evalboard). Das Teil hat zwar keinen Level Shifter, soll aber laut Keil den vollen Funktionsumfang (Geschwindigkeit, Debug, ..) haben. Hab aber noch keine Erfahrungen dazu gesammelt. Vielleicht hab ich mal in den nächsten Wochen so ein Teil hier rumliegen.... Dann kann ich mal einen Erfahrungsbericht liefern, da ich das bisher nur auf der Embedded World gesehen hab.
Wo merkt man eigentlich den Geschwidigkeitsunterschied bei JTAG? Ich habe das bisher nur an der längeren Flashdauer bemerkt.
> Hm, dass man ab und zu das Unlock-Tool benötigt hatte ich schon gelesen, > aber dass man den Controller dauerhaft aussperren kann wusste ich nicht. > Ist dir das passiert ? Mit meinem ersten (LM3S811, DEV-Kit) funzte das eigentlich sehr gut mit dem ULINK und µVision. Ich hatte nur Probleme, weil die Sachen neu waren und ich ebenfalls in der Materie ARM neu war. Scvhwirigkeiten bereitete mit die komische Driverlib mit n-stufigen #defines, und ein paar Programmierkonzepte. Auf der Elektronica, wo mein System lief, wurde der Core am letzten Tag durch unsachgemässe Handhabung "gelockt" (ich war an diesem Tag nicht auf der Messe). KA, elektrostatische Aufladung oder so ... Jedenfalls lief die Software noch, aber kein JTAG/SWD access möglich. Auf diese Art sind auf der Embedded noch zwei weitere Lumis 828 "gestorben". Lock-out, aber Soft lief. Alles Rev.B. Weitere Probleme gabs bei der Umsetzung zwischen den Revisionen B und C. Undokumentiert war, dass die Clocks nach dem Einschalten eines Peripherals erst ne Weile brauchen. Das war in der riverlib implizit in den funktionsaufrufen/returns versteckt, also ungefähr (Pseudocode!): setClockEnable(UART0); setUart0(57600, 8, 'n', 1); Der Rücksprung von der setClockEn und der Einsprung in die setUart reichten aus, dass sich die Clocks einschwangen. Machte man das über Registerprogrammierung (mein Favorit), dann ging das ab Rev.C schief und führte zu einem Hard Fault (Hardware nicht da). KA, warum das beim Rev.B funktioniert hat. An sowas bitte denken!!! Z.B. macht es hier sinn (wenn man den UART im Griff hat), sich ein paar "Bluescreens" einzubauen:
1 | // Debug!
|
2 | void hardfault_handler(void) |
3 | {
|
4 | printf("\nHard Fault!"); |
5 | while(1); |
6 | }
|
7 | |
8 | void busfault_handler(void) |
9 | {
|
10 | printf("\nBus Fault!"); |
11 | while(1); |
12 | }
|
13 | |
14 | void usagefault_handler(void) |
15 | {
|
16 | printf("\nUsage Fault!"); |
17 | while(1); |
18 | }
|
Die Namen müssen nur mit denen in der Interrupt-Vectortable übereinstimmen. Printf-retargeting über fputc reicht aus. > Ich denke, dass ich die Revision C habe (wegen dem Display), allerdings > steht auf der Rückseite "EK-LM3S6965-D" was mich auf eine Revision D > schliessen lassen würde - wenn es sie offiziell geben würde. Rev.B gibt es (sollte man nciht mehr verwenden) und Rev.C (nummer). http://www.luminarymicro.com/home/errata.html Mit der Rev.C sind die mittlerweile um einiges besser geworden, zumal ein paar Rettungsanker für den Core mit eingebaut wurden. Bei der Rev.C hatte ich aber dauernd das Problem, was auch schon oben geschildert wurde, dass sich der Core trotz richtiger Software "lockt". Hier sollte das Unlock-Tool aber helfen. Mein persönliches Fazit: Der µC ist vom Konzept her sehr schön, mit interessanten Peripherals versehen und hat auch - wenn man sich erst mal eingearbeitet hat - ein nettes Programmiermodell. Allerdings habe ich zu viele Probleme gehabt, was den µC leider erst mal wieder zurückstellt... > Die Geschichte mit dem FTDI nennt sich OPEN-OCD. Ist für's Hobby nicht > schlecht, aber relativ langsam im Vergleich zum ULINK-II oder anderen > JTAG Adapter der gehobenen Preisklasse. Ausserdem ist das ein Level > Shifter drin, der die Schaltung und den JTAG elektrisch trennt, so dass > man normalerweise nur den Level Shifter killt, wenn hardwareseitig was > schief geht. Jap, ich hatte das Glück, von Anfang an mit ULINK(2) unterwegs zu sein, und habe den ebenfalls zu hause (z.B. für's AT91SAM7X-Kit). Der ULINK / ULINK2 von Keil in Verbindung mit µVision ist eine sehr schöne, einfache Möglichkeit, einen Core kennenzulernen. Allerdings hat das auch seinen Preis, der für Hobbyisten sicherlich nicht immer in Frage kommt. Trotzdem: Wer sich so ein Dingen zulegt, hat was gutes (eigene Erfahrung, jetzt seit 2 Jahren). > Es gibnt ausserdem im Zusammenhang mit STM32 Evalboards einen ULINK in > der "light" Ausführung für ca. 100 Euro (zzgl. Evalboard). Das Teil hat > zwar keinen Level Shifter, soll aber laut Keil den vollen > Funktionsumfang (Geschwindigkeit, Debug, ..) haben. Der ULINK ME ist seit ca. einem Jahr erhältlich, und wesentlich günstiger als sein grosser Bruder. Es ist eine etwas abgespeckte Variante des grossen ULINK2. Der Levelshifter wurde weggelassen, und die Möglichkeiten auf ARM basierte µCs beschränkt. Man kann damit alle ARM basierten µCs per JTAG/SWD programmieren und debuggen, Breakpoints, Watches, Register anschauen funktionieren ebenfalls. > Hab aber noch keine > Erfahrungen dazu gesammelt. Vielleicht hab ich mal in den nächsten > Wochen so ein Teil hier rumliegen.... Dann kann ich mal einen > Erfahrungsbericht liefern, da ich das bisher nur auf der Embedded World > gesehen hab. Funktioniert - wieg gesagt - genau so wie der ULINK2, nur halt ohne Levelshifter. Die STM32-Boards sind übrigends sehr zu empfehlen. Hab da eins von bekommen und war sofort gefesselt. Sehr schönes Programmiermodell, keine Probleme mit Lockouts etc. Clock Tree/PLL lässt sich auch einfacher "bedienen". VG, /r.
@Random Im Datasheet vom LM3S6965 gibts auf Seite 57 eine Vorgehensweise zum Unlocken des Controllers - vermutlich genau das, was das Unlocker Tool vom LMI Flasher macht. Hier wird das aber so dargestellt, dass es zwar passieren kann, dass der Controller gelockt wird, aber dass er immer wieder "zurückgeholt" werden kann. Aber Danke für die Tipps ! Sowas findet man ja leider selten in den Datenblättern. Ich nehme mal an, dass man den ULINK-ME nicht einzeln sondern nur im Bundel mit einem Kit bekommt, oder ? Hab jetzt etwas gesucht aber nur die EV/Starter-Kits gefunden. Bei Digikey kostet das ST32-Kit STM3210B-SK/KEIL 253 Euro und das MCB2103UME 173 Euro, und das ist mir jetzt für den Einstieg doch etwas zu viel (da ich ja nur gern den ULINK-ME hätte).
Thomas B. wrote: > @Random > Im Datasheet vom LM3S6965 gibts auf Seite 57 eine Vorgehensweise zum > Unlocken des Controllers - vermutlich genau das, was das Unlocker Tool > vom LMI Flasher macht. Hmmm ... kenne ich noch nciht, ist neu. Ich hab seit nem Jahr nix mehr mit den Dingern gemacht ;-) Gleich mal nachsehen... > Hier wird das aber so dargestellt, dass es zwar passieren kann, dass der > Controller gelockt wird, aber dass er immer wieder "zurückgeholt" werden > kann. Nein, mit dem Clock Tree kann man den dauerhaft totsetzen: Ich hab - im Nachhinein dumm - gedacht, dass ich mit "null" im Prescaler diesen ausser Funktion setze. Allerdings muss da ein Wert >= "1" rein, und der MUX bekommt die "null". Da der Prescaler mit div/0 nix anzufangen wusste war der Core damit "totally scrwewd up" g Unrettbarer Fall für die Tonne in so einem Fall. Von daher gehe ich beim Lumi auch nur ungern an den Clock Tree. > Aber Danke für die Tipps ! Sowas findet man ja leider selten in den > Datenblättern. Jap, it took me much time to find out :-( Hatte zeitweise nen Eimer danebenstehen zum ko**** :-) Durch Zufall hab ich das dann rausgefunden, das in der DriverLib ein verstecktes Timing drin ist. > Ich nehme mal an, dass man den ULINK-ME nicht einzeln sondern nur im > Bundel mit einem Kit bekommt, oder ? Hab jetzt etwas gesucht aber nur > die EV/Starter-Kits gefunden. Eine nette Mail an Keil und ich denke er macht dir nen Angebot :-) > Bei Digikey kostet das ST32-Kit STM3210B-SK/KEIL 253 Euro und das > MCB2103UME 173 Euro, und das ist mir jetzt für den Einstieg doch etwas > zu viel (da ich ja nur gern den ULINK-ME hätte). Schreib ne Mail an Keil und bitte um ein Angebot. Ich denke er macht dir (ev. auch im Bundle mit einem STM32) ein nettes Angebot, wenns für deine privaten Basteleien ist. Anmerkung: Ich denke mittlerweile sind die Lumisachen einigermassen aus den Anfangsproblemen raus. Ich war zwar derbe am fluchen über diese Dinger, trotzdem sind sie vom Prinzip her nett zu programmieren und haben einige interessante peripherals. Vielleicht lege ich mir in nem Jahr mal wieder ein DEV-Kit zu... Weiter bin ich mal gespannt, was von den anderen Firmen noch kommt. LMI war ja das "Startup" des Cortex-M3. Die Implementierung von STM funktioniert sehr gut bisher, keine Probleme mit gehabt (wenn auch in der GPIO-Programmierung etwas sonderbar, aber dafür hab ich hier im Forum mal ein Mini-Tutorial gemacht). Beitrag "STM32 alias cortex m3 brauchbar?" Mal schauen, ob und was von Atmel, NXP usw. (also die anderen Hersteller von General Purpose µCs) noch so schönes kommt. VG, /r.
Danke für den Tipp mit Keil, werd denen eine Mail schreiben und erwähnen, dass ich Student bin (zwar im Endstadium, neben Arbeit DA), aber doch.
Naja, im Hauptteil der Arbeit gehts um ein Bedienterminal (Basis ist hier ein fertiges ARM9-Modul auf dem ich ein Linux laufen lasse), Implementierung des PTP-Stacks und Verteilung der Zeit über ein Wireless-Netzwerk (eigene Anpassung des MiWi-Stacks von Microchip). Zusätzlich fliesst auch ein Projekt ein, an dem ich vor der DA gearbeitet habe. Die Arbeit ist also relativ breit gefächert (mehrere Platinen entwickeln, Softwareentwicklung, usw), macht aber Spaß. Vor allem weil ich ja beruflich schon einige Jahre in dem Bereich zu tun habe und daher nicht irgendwo frustriert an "Anfängerproblemen" hängenbleibe. Die Luminary's bzw. konkret die ARMs schau ich mir aber rein privat an, brauch ich an sich für die DA nicht. Beim ARM9 Modul beschränkt sich (nach der Konfiguration) die Tätigkeit ja auf Anwendungsprogrammierung (die am PC stattfindet). Deswegen habe/brauche ich dazu auch keinen JTAG-Debugger.
Versuch, ein gutes Angebot von Keil für's MCBSTM mit ULINK ME zu bekommen. Da wirste einiges an Spass mit haben. Ich hab mich da mittlerweile ziemlich gut drin eingearbeitet. VG, /r.
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.