Hallo, mich quälen ein paar Fragen zu JTAG, SWD.. Ein Segger J-Link EDU, kann ich diesen in Kombination mit OpenOCD für jeden Cortex M0/M0+ nutzen? z.b. Raspberry PI pico, SAMD21, oder welche von NXP? Was bedeutet eigentlich das EDU, hat der debugger einen eingeschränkten Funktionsumfang?
segger schrieb: > Was bedeutet eigentlich das EDU, hat der debugger einen eingeschränkten > Funktionsumfang? findet man beim Hersteller in wenigen Sekunden: https://www.segger.com/products/debug-probes/j-link/models/model-overview/ zu ersten Frage: ja, sollte funktionieren. Es gibt jlink als interface in OOCD.
Johannes S. schrieb: > zu ersten Frage: ja, sollte funktionieren. Es gibt jlink als interface > in OOCD. Unter Windows ist es nur blöd, dass OOCD die libusb benutzt. Man muss jedes mal den USB Treiber umkonfigurieren (Zadig) wenn man das Interface mal mit OOCD benutzt und mal mit Software die das ohne diese Hampeleien macht. Ich hab es aber nur einmal versucht, wenn jemand was anderes weiß lerne ich gern dazu.
deshalb würde ich das in der Kombi auch nicht benutzen, und gerade JLink wird ja von fast allen Entwicklungsumgebungen und Werkzeugen unterstützt. Benutze auch gerade die light Version mit einem Nucleo F746 Board in VSCode, da funktioniert der JLink besser als der STLink.
segger schrieb: > Ein Segger J-Link EDU, kann ich diesen in Kombination mit OpenOCD für > jeden Cortex M0/M0+ nutzen? https://www.segger.com/products/debug-probes/j-link/ "OpenOCD Support J-Link can be used with OpenOCD (Open On-Chip Debugger). OpenOCD is an open-source software that can interface basically any debug probe. It provides a standardized API, allowing an IDE to support OpenOCD. There are several tutorials on the internet that describe how to use J-Link with OpenOCD. Note: OpenOCD is a 3rd party software, so SEGGER cannot provide any guarantees etc. Using J-Link with OpenOCD bypasses all J-Link specific features like flash programming, unlimited flash breakpoints and the J-Link high debugging speed. OpenOCD will handle J-Link as a simple sequence generator which will affect debug performance. Please also note that using J-Link with OpenOCD is not covered by the standard J-Link support. Support for OpenOCD is provided by the OpenOCD community." Was möchtest du denn genau machen? Mit einer IDE debuggen? Dann wäre eines von denen vielleicht was für dich: https://www.segger.com/products/development-tools/embedded-studio/ https://www.segger.com/products/development-tools/ozone-j-link-debugger/
Vielen Dank für die reichlichen Antworten. >>Was möchtest du denn genau machen? Mit einer IDE debuggen? >>Dann wäre eines von denen vielleicht was für dich: Ich möchte eigentlich nur flaschen und das debuggen steht nicht so im vordergrund. IDE´s nutze ich weniger gern, .. die M0+ von NXP und Microchip lassen sich auch bare-metal programmieren.
segger schrieb: > die M0+ von NXP dann reicht sogar ein USB-UART für 2€, auch die kleinen LPC haben einen seriellen Bootloader. Aber es ist schon sinnvoll das Debuggen zu nutzen. VSCode + CortexDebug Extension, mit dem JLink läuft das in ein paar Minuten.
Ok, dann schau bitte mal hier: https://www.segger.com/products/debug-probes/j-link/technology/flash-download/#download-into-flash-memory-for-development-purposes Für dich am einfachsten wäre wahrscheinlich J-Flash Lite.
Ohhh jflashlite ist für mich neu. Aber finde ich super. Hatte immer mal das Problem "nur" ein fremd .bin oder .hex zu haben und bisher musste ich dann immer auf openocd + jlink zurückgreifen.
Johannes S. schrieb: > deshalb würde ich das in der Kombi auch nicht benutzen, und gerade JLink > wird ja von fast allen Entwicklungsumgebungen und Werkzeugen > unterstützt. > Benutze auch gerade die light Version mit einem Nucleo F746 Board in > VSCode, da funktioniert der JLink besser als der STLink. Welche Debuggerumgebung nutzt Du denn dann in VSCode? Ich dachte, dass wäre in der Regel auch mit OpenOCD?
:-D :-D man darf sich nur nicht verschreiben beim googlen.. Wenn man a gegen e tauscht kommt man ganz woanders raus...
Die schon genannte Cortex-Debug Extension. Die schwatzt mit dem gdb per STLink, Jlink, BMP, OOCD.
Johannes S. schrieb: > Die schon genannte Cortex-Debug Extension. Die schwatzt mit dem gdb per > STLink, Jlink, BMP, OOCD. Bin in dem Thema leider nicht so firm. Habe diesen Thread von Dir gefunden: Beitrag "Debuggen mit VSCode und Cortex-Debug Extension" 1. Hätte man, wenn man in der Konstellation OpenOCD benutzen würde, das o.g. libUSB-Problem nicht trotzdem? 2. Wieso werden JLink und OpenOCD zusammen aufgelistet? Das eine ist doch ein Programmieradapter und das andere Software. Oder ist da mit Jlink der Jlink-gdbserver gemeint?
Gibt es den J-link EDU eigentlich zwischenzeitlich wieder irgendwo ? Es gab ihn zumindest mal bei Farnell und RS-Components. Der eine findet ihn gar nicht mehr, der Andere behaupte nicht mehr lieferbar. Haben die die Schülerausweise nicht genug kontrolliert oder soll der chinesische Handel wieder gefördert werden? Ich habe zwar einen J-Trace in der Schublade, aber unterwegs wo die Gefahr ist daß er verlorgen benutze ich diesen ziemlich ungern. Den Trace braucht man auch wirklich nur ziemlich selten.
Könnte ein DAPLink-Adapter eine Alternative sein? https://electronics.stackexchange.com/questions/405134/swdap-vs-cmsis-dap-vs-daplink
J. V. schrieb: > Gibt es den J-link EDU eigentlich zwischenzeitlich wieder irgendwo ja, da wo es ihn meistens gibt: https://www.ak-modul-bus.de/stat/segger_j_link_edu.html
Wenn gar nix mehr geht und die Not gross ist kann man ja einen kleinen ST-Link-Nachbau aus Fernost zu einem J-Link um-flashen.
temp schrieb: > ja, da wo es ihn meistens gibt: Also gibt es ihn effektiv NICHT. Nicht für Normalsterbliche. Denn da kann man ihn nur kaufen, wenn man nachweisen kann, daß man Schüler/Student ist. > Der J-Link EDU wird nur für den Hobbybereich und für Ausbildungszwecke > an Privatpersonen, Schulen, Universitäten und NPOs (Non Profit > Organizations) verkauft, nicht jedoch an Firmen oder an Personen, > die das Gerät in einem beruflichen Umfeld einsetzen. > > Für letztere Gruppe sind die kommerziellen Versionen des J-Link > EDU gedacht. Wir machen Ihnen hierzu gerne ein Angebot. > > Wir sind von SEGGER angehalten, die Zugehörigkeit zum berechtigten > Personenkreis ggf. nachzuprüfen. Mailen Sie uns bitte parallel zur > Bestellung einen Nachweis über Ihre Zugehörigkeit zum berechtigten > Personenkreis als Antwort-Email auf Ihre Bestellbestätigungs-Email. Man kann nicht nachweisen, daß man eine Privatperson ist. Geht nicht. Tatsächlich muss man ein Opensource-Projekt damit machen und das offenlegen, bevor man den Adapter überhaupt kaufen kann: > Bitte senden Sie uns einen Nachweis z.B. Schüler-/Studentenausweis > o.ä. per Email oder einen Link oder eine Beschreibung auf ein > (geplantes) Hobbyprojekt von Ihnen. (kommt aus 'ner Mail von AK Moduldings) Ich kann gut verstehen, daß viele darauf keinen Bock haben und dann irgendeinen China-Clone verwenden. Für ein Hobbyprojekt, das man nicht veröffentlichen will, soll man den Gewerbevolltarif bezahlen, also mehrere hundert Euro abdrücken.
Émile schrieb: > Denn da kann man ihn nur kaufen, wenn man nachweisen kann, daß man > Schüler/Student ist. Oder man macht vorab ein kleines Projektchen mit dem Lehrling und hofft, dass der Lehrling das Ding anschliessend nicht mehr braucht.
Émile schrieb: > Denn da kann man ihn nur kaufen, wenn man nachweisen kann, daß man > Schüler/Student ist. Nein. Man darf ihn schließlich auch als Privatmensch kaufen, steht ja explizit so. Bei mir gab es eine Nachfrage, weil ich das auch beruflich mache. Ich habe ihnen demonstriert, dass mein Brötchengeber mich dafür sehr wohl passend ausstattet, aber dass ich mich halt sehr lange schon auch privat mit MCUs beschäftige. Aber Segger scheint ihnen recht aggressiv da auf die Bude gerückt zu sein, damit die EDUs ihnen nicht die Marge der kommerziell verkauften versauen. (Wobei das natürlich die Frage aufwirft, ob man sich angesichts derartiger Geschäftsgebaren unbedingt mit Segger einlassen will oder doch lieber eine andere Variante wählt. Cortex-M-Debugging ist ja nun keine Raketenwissenschaft, das können viele.)
Mir scheint, dass die Segger die besseren Treiber haben als z.B. KEIL mit deren ULINK2. in uVsion sind bei mir die ULINKs absolut lahm wie Sau und das ganze Programm wird träge&zäh. Bei Segger keinerlei Probleme(das ist sicher kein generelles Problem, aber der Support zuckt da nur mit den Achseln) Offiziell sind die EDUs aufgrund Chiplieferproblematik nur begrenzt verfügbar. Ob das stimmt oder nur ein Vorwand ist, um sich da nicht die Gewinne zu kannibalisieren vermag ich nicht zu beurteilen. Was für Alternativen gibts denn noch so zum Hobbypreis? ST-Link?
:
Bearbeitet durch User
A. B. schrieb: > Mir scheint, dass die Segger die besseren Treiber haben als z.B. KEIL > mit deren ULINK2. Das liegt auch an der Hardware. Die einfachen mit FT232 die es früher viel gab haben langsames Bitbangig über USB gemacht. Bei den besseren ist ein µC drin der das SWD Protokoll macht. Die günstigen hatten bisher USB-FS mit 12 MBit/s, der STLinkV3 oder die teureren von Segger können USB-HS und sind damit deutlich schneller. Der STLink V3 ist immer noch günstig zu bekommen, den gibt es mehreren Varianten. Nur die Lieferbarkeit war schlecht, aber zumindest der STLINK-V3MINIE ist jetzt erhältlich. Für andere µC als STM32 ist auch Black Magic Probe interessant, da ist der gdbserver auf der Probe mit drauf. Da gibt es auch gerade ein neues Release und die org. Hardware ist auch erschwinglich.
Émile schrieb: > Man kann nicht nachweisen, daß man eine Privatperson ist. Geht nicht. Jeder Mensch ist auch irgendwo eine Privatperson. Immer. Oliver
:
Bearbeitet durch User
J. S. schrieb: > Die einfachen mit FT232 die es früher viel gab haben langsames Bitbangig > über USB gemacht. Reines Bitbanging eigentlich nie. Gibt zwar bei AVRDUDE diese Option (Bitbanging mit einem 08/15 FTDI), aber für SWD kenne ich das nur mit FTDIs, die auch MPSSE unterstützen. Da wird kein Bitbanging über USB direkt gemacht. Die gibt es auch wahlweise Fullspeed (FT2232) oder Highspeed (FT232H). Selbst die Fullspeed-Variante ist durchaus brauchbar und allemal vergleichsweise preiswert (vor allem, wenn man mit 3,3 V auskommt und keine Levelshifter braucht). > Bei den besseren ist ein µC drin der das SWD Protokoll > macht. Das dürfte bei den genannten ST-Link so sein und auch bei den AtmelICE, aber letztere sind mittlerweile nicht mehr günstig. Als Atmel sie neu rausgebracht hatte, war die Variante mit dem nackten PCB sogar günstiger als der alte AVR Dragon. > Die günstigen hatten bisher USB-FS mit 12 MBit/s, der STLinkV3 oder die > teureren von Segger können USB-HS und sind damit deutlich schneller. Bei Segger hängt das von der Hardwareversion ab, ab V10 ist es Highspeed-USB, egal ob Pro oder EDU. Hat sich aber manchmal recht mimosenhaft, wenn es an einem USB-Hub hängt. Dann blinkert da die grüne LED heftig.
Émile schrieb: > Tatsächlich muss man ein Opensource-Projekt damit machen und das > offenlegen Nein, man soll ihnen nur ein Projekt zeigen. Es steht nichts davon, dass das Opensource sein müsse, und es darf sogar ein nur geplantes Projekt sein, also Paperware. Aber mal ehrlich: für ein paar erste Schritte mit einem Controller kauft sich eh keiner ein originales J-Link. Dafür sind auch die 75 Euro für das EDU zu teuer. Das machst du nur, wenn du schon bissel was getan hast, und dann kannst du ihnen auch ein Foto von einem Steckbrett oder sowas senden.
https://www.segger.com/products/debug-probes/j-link/models/model-overview/ Hier noch ein Vergleich der Modelle. Der EDU hat eine geringere Geschwindigkeit. Wie sehr das stört muss jeder selbst entscheiden
A. B. schrieb: > geringere Geschwindigkeit als was? Das EDU ist hardwaremäßig identisch mit dem Plus Classic.
Naja wenn jemand einen Trace in der Schublade liegen hat.. Vermute ich mal stark, dass er den EDU nicht unbedingt nach der zugehörigen Lizenzbestimmung -> "Nur Hobby / Privat keine Professionellen Projekte" nutzen würde.. Weil wer leistet sich für Privat schon einen Trace und meckert dann über die Preise eines EDU als "2. Gerät"?
segger schrieb: > Ein Segger J-Link EDU, kann ich diesen in Kombination mit OpenOCD für > jeden Cortex M0/M0+ nutzen? > z.b. Raspberry PI pico, SAMD21, oder welche von NXP? segger schrieb: > Ich möchte eigentlich nur flaschen und das debuggen steht nicht so im > vordergrund. IDE´s nutze ich weniger gern, .. Für solche Randbedingungen wurde die Black Magic Probe erfunden und die darf jeder kaufen. Einziger Nachteil: kein Gehäuse, ich würde das RX2KL07-S-5 oder evt. RX2KL06-S-5 von Reichelt verwenden. https://1bitsquared.de/products/black-magic-probe > die M0+ von NXP und Microchip lassen sich auch bare-metal programmieren. Jeder Cortex-M lässt sich bare-metal programmieren, beim RPi scheitert das auch nur an der Dokumentation.
Bauform B. schrieb: > Für solche Randbedingungen wurde die Black Magic Probe erfunden und die > darf jeder kaufen. Wie gesagt, jeder FTDI mit MPSSE geht genauso. Auch debuggen geht damit. > Jeder Cortex-M lässt sich bare-metal programmieren, beim RPi scheitert > das auch nur an der Dokumentation. Das ist auch ein Cortex-A.
> Für solche Randbedingungen wurde die Black Magic Probe erfunden und die > darf jeder kaufen. Wenn ich das richtig sehe/verstehe kann die aber nur einige wenige MCUs. Wenn man damit auskommt okay. Aber letztlich bezahl man bei Segger fuer die ellenlange Liste der unterstuetzten MCUs und die Arbeit das alles einzubauen und nicht fuer die Hardware. Olaf
Der J-Link kann auch Cortex-A und mit Open-OCD dann sogar welche die nicht von Segger Unterstüzt werden (I.MX-8QM z.b.)
ja, dann ist das aber sicher nicht mehr Hobby und gewerblich sollte man sich einen 'guten' Segger leisten können. Mit BMP habe ich schon LPC, STM32 und nRF µC programmiert, das ist schon ein große Palette. Und Hobby ist heute ja nahezu only STM32, ESP und jetzt ein bisschen noch der RP2040.
Jörg W. schrieb: > als was? > > Das EDU ist hardwaremäßig identisch mit dem Plus Classic. hast recht. Ich bin vom EDU mini ausgegangen, da ich diesen und den Base in verwendung habe. mea culpa
olaf schrieb: >> Für solche Randbedingungen wurde die Black Magic Probe erfunden und die >> darf jeder kaufen. > > Wenn ich das richtig sehe/verstehe kann die aber nur einige wenige > MCUs. Denke ich nicht. Die Cortex-M haben doch ein einheitliches Debug-Interface. Ich kann mit einem STlink einen Atmel-ARM flashen und debuggen, ich kann mit einem Atmel-ICE einen STM flashen und debuggen, ich wüsste keinen Grund, warum das eine oder andere nicht gehen sollte. Schwieriger wird es erst dann, wenn du irgendein Firmware-Schnipsel in die MCU laden musst, damit bspw. ein QSPI-Flash oder dergleichen beschrieben werden kann; dann wirst du zuweilen halt nur für Segger den vorgekochten Support finden, wenngleich ich irgendwo gesehen habe, dass OpenOCD sowas wohl auch kann.
No Y. schrieb: > Der J-Link kann auch Cortex-A und mit Open-OCD dann sogar welche die > nicht von Segger Unterstüzt werden (I.MX-8QM z.b.) OpenOCD kann das auch mit allen möglichen JTAG Interfaces, inklusive den ganz einfachen mit FTDI Chip. Mit dem J-Link haben die Features von OpenOCD nichts zu tun.
> Ich kann mit einem STlink einen Atmel-ARM flashen und > debuggen, ich kann mit einem Atmel-ICE einen STM flashen und debuggen, DA bin ich ueberrascht. Haette gerade das die ST-Link mit Segger-Brain dann nur ST flashen koennen, alleine schon aus Prinzip. :) Geht damit dann ein RP2040? > ich wüsste keinen Grund, warum das eine oder andere nicht gehen sollte. Die muessten doch sogar die genauen Untertypen wissen damit die z.B wissen wie gross Flash und Ram ist und wo das im Speicher liegt. Olaf
@Dieter: Schon klar. Aber J-Link kann von sich schon Cortex-A aber halt nicht alle. Und die die nicht gehen kann man mit OpenOCD betüddeln.. Das war nur ein Hinweis weil die BMP ja scheinbar kein Cortex-A kann? Und Cortex-A kann sehr wohl Hobby sein.. Siehe BeagleBone z.b...? Gut 8QM ggf. eher nicht aber die Radxa / Tinker usw. Boards sind auch alle Hobby / Cortex-A Boards.. RP2040 geht auch nur mit den "neueren" J-Link deswegen (und wegen Cortex-A) musste auch mein V8 einem neuen J-Link weichen..
:
Bearbeitet durch User
olaf schrieb: > DA bin ich ueberrascht. Natürlich geht das nicht mit den Hersteller-Tools, die wollen nur jeweils ihrs bedienen. Aber die Hardware selbst kümmert sich nicht drum, welche Device-ID dahinter steckt. OpenOCD kann daher mit jedem der Tools arbeiten, und es sind natürlich auch nicht die Hardware-Tools sondern OpenOCD, was die Kenntnis über die Adressen und Speichergrößen und so hat. Die Hardware ist nur Bindeglied.
STLinkV3 können afaik nur mit ST, auch wenn man die mit BMP hosted betreibt. Ob BMP da jetzt native drauf läuft weiß ich nicht. Auch die Nucleo oder LPCLink2 mit JLink weigern sich mit fremden zu sprechen.
> Natürlich geht das nicht mit den Hersteller-Tools, die wollen nur > jeweils ihrs bedienen. Das verstehe ich jetzt nicht. Ich denke du benutzt einen ST-Link den du auf Segger J-Link umgeflasht hast. Dann musst und willst du doch auch die Segger-Software nutzen. Das ist doch gerade der Sinn der Sache. Olaf
olaf schrieb: > Ich denke du benutzt einen ST-Link > den du auf Segger J-Link umgeflasht hast. Nein, ich hatte einen STlink mal mit einem Atmel-ARM (jetzt Microchip, klar) benutzt, später dann aber die STMs eines Kundenprojekts mit AtmelICE. Das alles jedoch ohne irgendwas an den Tools zu ändern, mit OpenOCD auf dem Host. Natürlich geht OpenOCD auch für den Segger. Ich weiß nicht, aber zumindest von Segger wirst du kaum die Firmware bekommen, um irgendein anderes Device damit umzuflashen. Sie verkaufen einem bei Bedarf für teuer Geld embedded J-Link MCUs. Hatten wir bei einem früheren Brötchengeber mal, da kostet einer 10er-Pack wohl mehr als einen Tausender.
:
Bearbeitet durch Moderator
No Y. schrieb: > > RP2040 geht auch nur mit den "neueren" J-Link deswegen (und wegen > Cortex-A) musste auch mein V8 einem neuen J-Link weichen.. Beim RP2040 ist es eine Beschränkung der J-Link PC Software. Auch ältere J-Link Hardware kommt mit dem RP2040 klar wenn man die Beschränkung in der PC Software entfernt (das gilt auch für einige andere Devices). Ich habe Verständnis dafür wenn man neue JTAG Interface Hardware braucht weil die alte Hardware nicht leistungsfähig genug ist (z.B. weil cJTAG Unterstützung nicht mehr in die Firmware passt). Wenn man aber in erster Linie neue Hardware verkaufen will und deshalb bewusst bestimmte Dinge für die alte Hardware sperrt sehe ich das etwas anders.
> Ich weiß nicht, aber zumindest von Segger wirst du kaum die Firmware > bekommen, um irgendein anderes Device damit umzuflashen. Doch doch: https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ Olaf
olaf schrieb: > https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ "The firmware is only to be used with ST target devices. Using it with other devices is prohibited and illegal."
Jörg W. schrieb: > olaf schrieb: > Schwieriger wird es erst dann, wenn du irgendein Firmware-Schnipsel in > die MCU laden musst, damit bspw. ein QSPI-Flash oder dergleichen > beschrieben werden kann; dann wirst du zuweilen halt nur für Segger den > vorgekochten Support finden, wenngleich ich irgendwo gesehen habe, dass > OpenOCD sowas wohl auch kann. Das gibt's dort in verschiedenen Varianten, z. B. https://review.openocd.org/c/openocd/+/4760 für Cortex-M von (fast) beliebigen Herstellern.
Nicht schlecht. Hatte nur bei einem früheren Brötchengeber mal mit dialog-Chips zu tun, die sowas brauchten.
Oh, das mit dem RP2040 und der "Software Beschränkung" wusste ich nicht. Ja sowas sehe ich auch als "Sanktionierungsgrund" gegenüber Segger an. Gerade in Zeiten von Resourcenknappheit. Naja gut wegen Cortex-A war es ja kein ganz unnötiger Neukauf..
Jörg W. schrieb: > "The firmware is only to be used with ST target devices. Using it with > other devices is prohibited and illegal." ja, und die Firmware prüft das auch und verweigert den Dienst mit anderen Targets, das meinte ich mit ' weigern sich mit Fremden zu sprechen.' Der JLink bzw. zum JLink umgebrannte STLink auf den Nucleo Boards hat für mich nur einen Vorteil: er kann besser mit den F7 umgehen. Beim STLink landet man beim Step immer in einem Interrupt, der JLink macht das richtig. Bei OOCD funktionieren die ersten Steps, dann landet man auch damit im Interrupt. Man muss wohl bei jedem Step erst ein Debugregister wieder richtig setzen.
No Y. schrieb: > > Naja gut wegen Cortex-A war es ja kein ganz unnötiger Neukauf.. Welcher Cortex-A denn genau? Ein Cortex-A9 (i.MX6) funktioniert z.B. mit einem J-Link HW 8.0 auch wenn angeblich nur der Cortex-A8 mit HW 8.0 funktionieren soll.
Nachtrag zu Cortex-A: Auch ein Cortex-A7 (i.MX6UL) funktioniert mit einem J-Link HW 8.0.
J. S. schrieb: > Jörg W. schrieb: >> "The firmware is only to be used with ST target devices. Using it with >> other devices is prohibited and illegal." > > ja, und die Firmware prüft das auch und verweigert den Dienst mit > anderen Targets, das meinte ich mit ' weigern sich mit Fremden zu > sprechen.' Das ist wohl auch so gewollt, weil jedes Unternehmen ihre Produkte nicht zum Selbstzweck entwickelt und unterschiedliche Modelle vertreibt. Diese art von Diskussionen liebe ich. Segger ist somit einer der wenigen Anbiter, die kostenlos eine j-Link Firmware als Ersttz für die grauenhafte ST-Link Firmware verschenkt. Einen EDU-Adapter für einen symbolischen Preis von rund 16 Euro vertreibt. Nur mal einen Hinweis - der Debugger von Atmel/Microchip kostet bald 200 Euro. Wem das alles zu teuer ist und nur Flashen will, hat deutlich preiswertere Lösungen verfügbar. OpenOCD mit einem FT2232-Adapter wäre nur eine Lösung und die ist recht brauchbar und kostet nicht viel. > > Der JLink bzw. zum JLink umgebrannte STLink auf den Nucleo Boards hat > für mich nur einen Vorteil: er kann besser mit den F7 umgehen. Beim > STLink landet man beim Step immer in einem Interrupt, der JLink macht > das richtig. Bei OOCD funktionieren die ersten Steps, dann landet man > auch damit im Interrupt. Man muss wohl bei jedem Step erst ein > Debugregister wieder richtig setzen. Die Cortex-M7 funktionieren nicht mit einem J-Link V8. Dazu braucht es minimum Version 10. Die aber ist genauso obsolete wie die Version 11. Ich selber nutze privat einen J-Link Ultra+, weil ich die Lizenz für OZONE Debugger nutzen möchte. Einmal im Jahr ist Weihnachten und man(n) gönnt sich ja sonst nichts. Ich mache es gern komfortabel, da ich es von berufswegen auch so gewohnt bin. Und ja, nicht nur der ST-Link hat ein Problem mit den Chip-Bugs der Cortex-M7 Serie. Da gibt es noch ein Errata dazu. Wichtig ist in diesem Fall, dass auf die Hardware-Version des verwendeten MPU-Kerns achten muss. Der Cortex-M7 r0p1 hat diesen Bug (und ein paar Andere) Segger hat es geschafft, dass Ihre Firmware damit umgehen kann und nicht immer im IRQ-Handler landet. Aber all das kostet eben Zeit und für Segger Geld. Rolf Segger hat mal dazu was im EEV-Blog geschrieben. Ich arbeite nicht für Segger - um dies gleich vorweg zu nehmen. In Summe hat man eben viele Optionen verfügbar. Preiswert, komfortabel oder beides. Dieser Beitrag nur zu Ergänzung, da er schon etwas älter ist. Wie man sieht, wird er dennoch recherchiert.
Gerhard W. schrieb: > Nur mal einen Hinweis - der Debugger von Atmel/Microchip kostet bald 200 > Euro. Die reinen PCBs dafür (ohne Gehäuse, ohne Kabel) kosteten am Anfang übrigens auch nur 38 Euro, inklusive Levelshifter (1,8 … 5,5 V, wie beim "großen" und deutlich teureren alten J-Link EDU). Damit waren sie sogar noch billiger als der seinerzeit recht legendäre AVR Dragon. Erst durch die Übernahme durch Microchip wurden die Dinger so enorm teuer. Das nur am Rande. > OpenOCD mit einem FT2232-Adapter wäre nur eine Lösung und die ist recht > brauchbar und kostet nicht viel. Mit der man übrigens nicht bloß flashen sondern auch debuggen kann. Haben wir daher bei meinem früheren Brötchengeber gleich mit auf die Demoboards integriert, weil das das ganze Kabelgefummel gespart hat.
Wie schon mehrmals erwähnt: Die meisten Beschränkungen bei den älteren J-Link Interfaces mit aktuellen Mikrocontrollern sind willkürlich und haben nichts mit der Hardware oder Firmware zu tun. Es gibt ja auch meistens keinen Grund dafür, an JTAG oder SWD hat sich wenig geändert, den Rest macht die Software auf dem PC und nicht die Firmware. Anders sieht es aus wenn es z.B. um cJTAG geht, das muss die Hardware/Firmware des Interface unterstützen. Und zum Testen schnell mal zum Debuggen einem J-Link HW 8.0 an einen STM32H755 mit Cortex-M7 und Cortex-M4 Core angeschlossen, das funktioniert problemlos nach zwei kleinen Änderungen an der richtigen Stelle der PC Software.
Also, so gut wie jeder JTAG Adapter kann JTAG oder SWD sprechen. Damit kann man schnell übliche ARM Cortex CPUs debuggen. Das Problem fängt dann an, wenn man auch mal sein Target flashen möchte. OpenOCD ist toll, aber es kann diverse CPUs nicht. Z.b. die gesammte NXP LPC15xx Serie sowie die neuen NXP MCX Microcontroller (die übrigens sehr nice sind). Da fehlt schlicht und ergreifend der Code in OpenOCD, der das "Write Program to Flash" implementiert. Das ist leider nicht standardarisiert sondern Chip spezifisch. Die Segger Tools (JLink) haben meist schon Support für solche Chips bevor der Chip auf den Markt kommt. Aber das ist auch kein Wunder. Die werden ja dafür bezahlt Chip Support zu liefern und bekommen dementsprechend auch Geld.
Gerhard W. schrieb: > Einen EDU-Adapter für einen > symbolischen Preis von rund 16 Euro vertreibt. Nur nich an Normalsterbliche. Gerhard W. schrieb: > Nur mal einen Hinweis - > der Debugger von Atmel/Microchip kostet bald 200 Euro. Es gibt einen günstigeren, das ist der Mplab Snap.
:
Bearbeitet durch User
Harald K. schrieb: > Gerhard W. schrieb: >> Nur mal einen Hinweis - >> der Debugger von Atmel/Microchip kostet bald 200 Euro. Ja das ist schon echt der Hammer, ich habe den Atmel ICE noch für ca 120€ gekauft. Als zweiten habe ich noch den SEGGER Atmel SAM-ICE wobei ich den Atmel ICE irgendwie besser finde und ist auch günstiger als die von SEGGER. Also ich sag mal so: Ja, die kosten Geld, aber es läuft einfach und das ist es mir Wert. Aber muss jeder für sich selbst entscheiden, ob er eine "Bastellösung" möchte und evtl. mit Problemen zu kämpfen hat oder es einfach Plug&Play haben will. Oder nur die Platine kaufen und Gehäuse selbst drucken, gibts schon fertig modeliert im Internet. Dann sind nur ca. 102€ https://de.farnell.com/microchip/atatmel-ice-pcba/debugger-atmel-arm-avr-pcba-kit/dp/2407171?&CMP=KNC-GDE-GEN-Shopping-Genie-Dual-Presence-Test1248&gad_source=1&gclid=Cj0KCQiA2oW-BhC2ARIsADSIAWqRYOj6maeVhpwm8tolZC-l0vMAKSGd9CyTEyTSzmoqC4NXzBtSC1saArE7EALw_wcB Schönes WE allen zusammen.
:
Bearbeitet durch User
> Wie schon mehrmals erwähnt: Die meisten Beschränkungen bei den älteren
Klingt wie Beweis durch Behauptung!
Ich denke naemlich schon das es da ein paar Unterschiede gibt.
Und bestimmt wird man auch ein paar Sachen ausbuegeln koennen wenn man
nochmal extra was in eine alte Plattform zurueck implementiert. Aber
warum sollte ein Hersteller das fuer eine >10Jahre alte Plattform tun an
der er sowieso nichts verdient hat? Eigentlich bettelst du gerade darum
einen monatliche Gebuehr fuer einen J-Link zu bezahlen damit der
Hersteller den immer auf aktuellen Softwarestand haelt.
Vanye
Vanye R. schrieb: > > Klingt wie Beweis durch Behauptung! Wenn Du lesen würdest findest Du mehrere Beweise dafür ("Beweis" in der Art dass die alte Interface Hardware mit aktuellen Mikrocontrollern ohne Probleme funktioniert, auch wenn sie es angeblich nicht kann). > Ich denke naemlich schon das es da ein paar Unterschiede gibt. Ließ halt die Spezifikationen von JTAG und SWD (also das Transport-Layer) und schau was sich geändert hat. Abgesehen davon: OpenOCD kann ohne Probleme mit den alten J-Links aktuelle Mikrocontroller per JTAG oder SWD debuggen, weil sich halt die PC-Software darum kümmert und nicht die Firmware/Hardware des Interface.
Dieter S. schrieb: > nach zwei kleinen Änderungen an der richtigen Stelle der PC Software. Magst du die mal beschreiben bitte?
900ss schrieb: > > Magst du die mal beschreiben bitte? Ich habe nicht vor hier eine Anleitung zum Umgehen der "Kauf neue Hardware" Funktionalität zu geben. Aber das Ganze ist nicht sonderlich kompliziert und man kann die richtigen Stellen mit ein wenig Erfahrung im Debuggen von PC Assembler Code (x86 und/oder x64) ziemlich schnell finden.
Dieter S. schrieb: > Debuggen von PC Assembler Code (x86 und/oder x64) ziemlich schnell > finden. Ach so, ich dachte es wären "geheime" Konfigurationsparameter o.â. Ich habe noch einen J-Link V8 den ich damals günstig von Segger direkt kaufen durfte als "None Profit" Gerät. Quasi die Vorläufer der EDU Version, nur etwas besser ausgestattet wenn ich nicht irre. Zugegeben, J-Link ist "geschmeidiger", aber dann nehme ich weiter den BMP. Der tut es sehr gut für meine Belange und beherrscht alles was ich brauche. Ist nur langsamer beim flashen. 🤷 Und OOCD fasse ich nicht wieder an. Ist das Grauen schlechthin. Dieser Wust an Konfigurationsdateien und Parameter. Boah nee, das soll doch Spaß machen. Ich find das Zeug furchtbar. Ja ja.... ich hab's gesagt, Jehova ;) Kostet nichts, ja. Mein BMP hat ca. 5€ gekostet, da ist das Preis/Leistungsverhältnis deutlich besser :)
900ss schrieb: > Und OOCD fasse ich nicht wieder an. Ist das Grauen schlechthin. Tja, siehste mal, so unterscheiden sich die Leute. ;-) Ich benutze es grundsätzlich für alles außer AVR, weil es dann eben völlig schnuppe ist, was man als eigentliche Hardware benutzt. Ob J-Link, FTDI, AtmelICE, STlink – alle können damit arbeiten, und die können dann auch herstellerübergreifend arbeiten, d.h. ich kann mit einem AtmelICE problemlos einen STM32 flashen und debuggen oder mit einem STlink einen Atmel-ARM. :) (Das Einzige, wo ich den J-Link¹ dann immer benutzt habe war dienstlich, für eine MCU, die einen speziellen Flashloader benötigt, aber die sowieso so proprietär und nur unter NDA zu benutzen ist, sodass es sich nicht gelohnt hätte, für OOCD auch noch einen Flashloader dafür zu basteln.) ¹Natürlich den non-EDU, aber die Hardware ist ja die gleiche
:
Bearbeitet durch Moderator
Ich kenne mich nicht besonders mit den Feinheiten des ARM-Debuggen aus; welchen Vorzug bietet ein J-Link gegenüber einen CMSIS-DAP-Adapter?
Jörg W. schrieb: > Ich benutze es grundsätzlich für alles außer AVR, Weiß ich doch ;) Jörg W. schrieb: > weil es dann eben völlig schnuppe ist, was man als eigentliche Hardware > benutzt. Ich will die Flexibilität dieses "Werkzeuges" garnicht in Frage stellen. Und ich mag auch flexible ("generische") Werkzeuge. Aber ich finde es einfach unterirdisch damit umzugehen. Da war es Ende der 80-er besser mit dem Z80. Es ist für mich völlig aus der Zeit gefallen so wie es ist und ein Beispiel so wie man es nicht machen sollte. Ich habe mich anfangs (als es entstand) so über das Zeug geärgert, bis es dann lief.... Danach hab ich es in die Ecke geworfen. Und dann haben ich es mir vor ein paar Jahren nochmal angesehen und feststellten müssen, dass es genauso unübersichtlich ist, wie anfangs. Ich finds furchtbar. Einfach zusammengestöpseltes Zeug. Nie "erwachsen" geworden. Ich erwarte in 2025 etwas mehr. OK, ich gehe zu, ich habe einen gewissen Anspruch an Werkzeuge. Ich suche mir gerne die kleinsten Übel. OOCD zählt für mich mit zu den größten Übeln
:
Bearbeitet durch User
Harald K. schrieb: > welchen Vorzug bietet ein J-Link gegenüber einen CMSIS-DAP-Adapter? Was sie genau alles in der Hardware haben, müsste dir jemand von Segger erklären. Es gibt dann von denen auch noch eine ganze Reihe an Software letztlich bis hin zu einer kompletten IDE mit dazu. Was sie natürlich vor allem haben (wurde ja schon genannt) ist Unterstützung von sehr vielen verschiedenen MCUs, auch eben solchen, die diverse Flash-Loader brauchen, weil sie selbst keine eingebaute Prozedur zum Beschreiben des Flashs besitzen. Insbesondere sind das MCUs, bei denen der Flash extern dran ist (heutzutage meistens als QSPI). Da wird dann im RAM der MCU ein Hilfsprogramm gestartet, welches den Flash bedient und mit dem das J-Link redet. OpenOCD kann prinzipiell auch solche Flashloader bedienen, aber die gibt es natürlich dort immer nur dann, wenn sowas schon mal jemand benötigt hat und es dann auch als Opensource freigegeben.
:
Bearbeitet durch Moderator
Danke für die ausführliche Antwort. Wenn man also eine IDE mit Debugunterstützung für CMSIS-DAP und den auf dem Tisch liegenden ARM hat, ist man versorgt, aber es gibt potentielle Spezialfälle, für die man dann mit J-Link was ausführlicher unterstütztes braucht, verstehe ich das so richtig?
Jörg W. schrieb: > Da wird dann im RAM der MCU ein Hilfsprogramm gestartet, welches den > Flash bedient und mit dem das J-Link redet. Deshalb ist er dann auch so pfeilschnell beim flashen. Der BMP macht das zu Fuß per Bit banging an den QSPI Pins und das ist schon spürbar langsamer. Und der J-Link bietet auch sonst ein paar nette hilfreich Features. Und er funktioniert in der Regel einfach. Und man braucht kein OOCD ;) Der hat eigene gute SW und Werkzeuge. Aber ich finde den BMP auch sehr gelungen und der läuft auch stabil. Ich hab ihn schon ein paarmal eingesetzt. Auch in der FA als die Bestellung für den J-Link noch nicht erledigt war. Man kann sich ein 5€Board nehmen, BMP drauf flashen und loslegen. Welche Boards geeignet sind, steht auf der Homepage. Und er unterstützt inzwischen auch sehr viele Targets. Gut, soo flexibel wie OOCD ist er nicht. ;)
Harald K. schrieb: > ist man versorgt Na ja, einen CMSIS-DAP HW-Adapter brauchst du schon noch für die Verbindung Target und Host. Aber im Prinzip stimmt es schon. Und der J-Link ist auch sonst echt fix. Es flutscht einfach besser. Weniger Wartezeit. Selbst beim Singlestep ist er bei gewissen Konfigurationen schneller. Das Zusammenspiel von J-Link zum Target wie auch zum Host und da die J-Link SW scheint einfach ausgeklügelt. Und er unterstützt HW wie SW Breakpoints, da weiß ich nicht wie das mit einem einfachen CMSIS-DAP-Adapter ist
:
Bearbeitet durch User
Gerade gesehen, die Liste der unterstützten Targets beim BMP wächst ständig: https://black-magic.org/supported-targets.html
900ss schrieb: > Na ja, einen CMSIS-DAP HW-Adapter brauchst du schon noch für die > Verbindung Target und Host. Das ist klar, aber den kann man, wenn ich das richtig verstanden habe, sich z.B. mit einem RP2040 leicht selbst stricken - für den gibt's passende Firmware, dann kann man mit dem via SWD einen anderen RP2040 bearbeiten. Man kann das auch als Fertiggerät kaufen: https://www.elektor.de/products/raspberry-pi-debug-probe
Wenn man wirklich alles ausreizen will/muß verwendet man TRACE32 von Lauterbach, dagegen ist J-Link "Debugging for Dummies". Die Menge der unterstützten CPUs/Mikrocontroller ist riessig, allerdings braucht man dafür jeweils die passende Lizenz. Und für die meisten der unterstützten CPUs bekommte man auch gleich noch einen passenden Simulator.
Harald K. schrieb: > leicht selbst stricken Ja das ist richtig. Das gibt es verschiedene günstige Möglichkeiten. Was mir auch nicht klar ist, ob man mit den "einfachen" CMSIS-DAP Adaptern auch RTT Support hat. Sollte möglich sein, sind dieselben Pins. Ich habe das mal mit J-Link und auch BMP getestet. Da sind Debugausgaben auch pfeilschnell, ich hab die Datenrate vergessen aber ein UART ist ne Dampflok dagegen. RTT ist eine super Erfindung.
:
Bearbeitet durch User
900ss schrieb: > Der BMP macht das zu Fuß per Bit banging an den QSPI Pins und das ist > schon spürbar langsamer. Gut, dass das langsam ist, ist nun nicht weiter verwunderlich. 900ss schrieb: > Und er unterstützt HW wie SW Breakpoints, da weiß ich nicht wie das mit > einem einfachen CMSIS-DAP-Adapter ist Weiß ich nicht, die simplen FTDI-Teile werden das auch nicht können, und ich kann dir nichtmal sagen, wo / wie OpenOCD das unterstützt. Aber da wir in der vorigen Firma den FTDI später gleich mit auf die Boards gebaut haben – in irgendwelche ernsthaften Limitierungen bin ich damit dort auch nicht rein gelaufen (Target waren ATSAME70). Wir hatten auch embedded J-Link in Erwägung gezogen, aber Segger wollte da meiner Erinnerung nach pro Stück irgendwas um einen Hunderter haben, das war uns dann schlicht zu teuer. Die Boards waren ob der geringen Losgrößen auch so schon teuer genug, und sie waren ja nur Mittel zum Zweck, um unsere Softwarelösungen unter die Kunden bringen zu können.
Dieter S. schrieb: > TRACE32 von Lauterbach Jörg wo bist du? ;) Ja, die Lauterbach Teile waren schon zu Z80-Zeiten Spitze. Aber die kosten auch gleich deutlich mehr. Für den Basteltisch ist das nichts mehr. Edit: ah Jörg ist schon da ;) Ach, aber keinen Kommentar zum Lauterbach?
:
Bearbeitet durch User
Jörg W. schrieb: > Wir hatten auch embedded J-Link in Erwägung gezogen, aber Segger wollte > da meiner Erinnerung nach pro Stück irgendwas um einen Hunderter haben, > das war uns dann schlicht zu teuer. Ich erinnere mich, du hattest das schon irgendwann erwähnt. So warst du quasi gezwungen mit OOCD zu arbeiten. ;)
:
Bearbeitet durch User
Harald K. schrieb: > Das ist klar, aber den kann man, wenn ich das richtig verstanden habe, > sich z.B. mit einem RP2040 leicht selbst stricken Das ist übrigens beim BMP auch so. Nur auf einen RP2040 läuft er gerade nicht. Aber auf den Black Pills z.B.
900ss schrieb: > Ach, aber keinen Kommentar zum Lauterbach? Hatte ich noch nicht gesehen. Wir hatten die Dinger auch mal in der Firma, wo ich jetzt bin. Nun, ja, hmm, der Preis ist eindeutig jenseits von Gut und Böse, die Hardware ist gut¹. Bei deren UI aber ist irgendwie die Zeit um einige Jahrzehnte stehen geblieben. Wenn du OpenOCD umständlich findest – TRACE32 fand ich absolut grottig zu bedienen, auch wenn ich mich inzwischen nicht mehr an alle Details erinnern kann. Ich weiß nur noch, dass man irgendwie beim ersten Starten den Staub vom UI abzuschütteln geneigt war. ;-) (Disclaimer: ich glaube, sie wollten ein neues GUI bauen. Weiß nicht, ob das inzwischen da ist.) ¹ Ziemlich unkaputtbar aufgebaut. Ich hatte mal im Homeoffice das originale Netzteil vergessen und eins aus der Kiste genommen. Das funktionierte nur dann, wenn man das Netzteil vorher angesteckt hat und danach in die Steckdose, anders herum nicht. Die Wandwarze war eine ungeregelte und hatte eine ziemlich hohe Leerlaufspannung – und die Eingangsschaltung im Lauterbach macht schnapp-app schon bei wenig mehr als der Nominalspannung dicht. Wenn man die Reihenfolge anders herum gemacht hat, dann lief natürlich die Spannung der Wandwarze langsam genug hoch und diei hatte dann den Debugger als Last, sodass sie nicht mehr über der Triggerschwelle lag.
Für Hobbyanwendungen hat sich ja STM32 sehr breit gemacht, und da ist der STLink ja völlig ausreichend. Auf neueren Boards ist der V3 schon drauf, sonst kostet das einfache Modul V3MOD etwa 10€. Und das ist besser als jeder Clone und durch HS USB auch viel schneller als die V2. Mit dem CubeProgrammer geht alles bequem per GUI, es gibt auch jede Menge Loader für ext Flash und eine CLI Version gibt es auch. Segger ist sicherlich besser für non STM32, aber auch hier gibt es ja kaum NXP oder sonstige Nutzer. Und wenn man nicht die EDU bekommt sind die verhältnismäßig teuer, auch wenn tolle Tools dabei sind. CMSIS-DAP gibt es billig bei AliExpress, das ist die gleiche low cost HW wie die STLinkV2 Clone, mit STM32F10x und ungepuffertem SWD. Habe jetzt auch damit gespielt, die mochten nicht alle Targets. NXP hat jetzt auch noch einen GDBServer für die LPCLink rausgebracht, damit kann man sogar noch die alten LPCLink 1.3 für die LPC nutzen.
Jörg W. schrieb: > Ich weiß nur noch, dass man irgendwie beim ersten Starten den Staub vom > UI abzuschütteln geneigt war. ;-) Solang es nur die Optik ist macht das nichts für mich. Stimmt, optisch wirkt es etwas angestaubt. Aber OOCD hat nichtmal ein GUI ;)
:
Bearbeitet durch User
900ss schrieb: > Aber OOCD hat nichtmal ein GUI ;) Emacs :-) Bei der vorigen Firma haben wir am Ende PlatformIO benutzt. Für jeden Controller und jeden Debugger eine eigene GUI mit eigenen Macken, an die man sich gewöhnen muss, fand ich irgendwie nie wirklich toll.
Jörg W. schrieb: > Emacs :-) LOL :) Jörg W. schrieb: > Für jeden Controller und jeden Debugger eine eigene GUI mit eigenen > Macken, an die man sich gewöhnen muss, fand ich irgendwie nie wirklich > toll. Das stimmt schon. Begeistert mich auch nicht.
Noch mal kurz zum TRACE32 von Lauterbach: damit kann man z.B. so Dinge machen wie unterschiedliche CPUs in einer JTAG-Chain debuggen (etwa Hexagon und ARM bei einigen Mobilfunk SoCs von Qualcomm). Es gibt Unterstützung für "Exoten", etwa die Meta CPU (z.B. verbaut in einigen der DAB oder Internet Radio SoCs von Frontier Silicon). Boundary Scan geht ebenfalls, darüber kann man bei Bedarf auch externen Flash programmieren. Ja, das sind vermutlich relativ seltene Spezialfälle, aber dafür gibt es dann wenig Alternativen.
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.