Hi ich versuche gerade meinen jlink ebu mit einem stm32h743 zu verbinden. Habe mir die aktuelle Version 7.60c installiert. Über das config Programm wollte ich nun die Firmware aktualisieren lassen, die soll aber aktuell sein. Nur wenn ich den Prozessor jetzt Debuggen will kommt die Meldung das die Firmware nicht passt. Was mache ich falsch? Was kann ich machen? Hätte ich lieber einen China clone kaufen sollen? Segger wird sagen auf keinen Fall, einige hier werden wohl sagen hättest du besser mal gemacht. So das dumme ist nur das ich jetzt und nicht in ein paar Tagen Debuggen muss. Also wie bekomme ich das Teil zum Laufen? Viele Grüße Uli
Bevor du hier jammerst solltest du erst mal mehr preisgeben. jlink edu welche HW Version? Bei der Version 8 gab's die letzte neue Firmware Ende 2014. Damit wird die deinen µC noch nicht kennen. https://wiki.segger.com/Software_and_Hardware_Features_Overview Falls der jlink edu jetzt übrig ist, ich würde ihn dir für 30€ abnehmnen.
Ja es ist ein v8 Modell. Verkaufen werde ich den aber nicht! Dafür habe ich zu viele Projekte. Also kann ich jetzt erstmal auf die schnelle ein stlink v2 dran hängen und mir beim freundlichen China Mann ein v9, v10 oder v11 Modell kaufen. Weil so wie ich hier gelesen habe ist der edu gerade nicht kaufbar.
> Was mache ich falsch? Du bist zu dumm um zu merken das es klug die die ganzen Fehlermeldungen zu zeigen die ein Jlink von sich gibt wenn er connected. Ansonsten solltest du pruefen ob deine Hardware diesen Controller auch kann. Einige neuere ARMs haben ein anderes Protokoll fuer die man eine neuere JLink-Hardware braucht. Softwareupdate reicht da nicht. Olaf
Olaf schrieb: >> Was mache ich falsch? > > Du bist zu dumm um zu merken das es klug die die ganzen Fehlermeldungen > zu zeigen die ein Jlink von sich gibt wenn er connected. > > Ansonsten solltest du pruefen ob deine Hardware diesen Controller auch > kann. Einige neuere ARMs haben ein anderes Protokoll fuer die man eine > neuere JLink-Hardware braucht. Softwareupdate reicht da nicht. > > Olaf Du solltest mal aufhören andere Leute hier so zu beleidigen. Was stimmt mit dir nicht?
> Du solltest mal aufhören andere Leute hier so zu beleidigen. Was stimmt > mit dir nicht? Wie kann man erwarten bei einem Fehler hilfe zu bekommen wenn man die Fehlermeldung nicht zeigt? Warum machen sich Programmierer ueberhaubt die Muehe sowas anzuzeigen? Olaf
Olaf schrieb: >> Du solltest mal aufhören andere Leute hier so zu beleidigen. Was > stimmt >> mit dir nicht? > > Wie kann man erwarten bei einem Fehler hilfe zu bekommen wenn man > die Fehlermeldung nicht zeigt? Warum machen sich Programmierer > ueberhaubt > die Muehe sowas anzuzeigen? > > Olaf Und genau das kann man auch vernünftig sagen, ohne jemand gleich als "zu dumm" zu betiteln. Arbeite mal ein wenig an dir, anderen Menschen mit dem minimal notwendigen Respekt zu begegnen.
Besonders hier herum meckern wenn schon alles geklärt ist, ist schon peinlich. Was hätte dir persönlich denn geholfen? Die Meldung beim Update das die Firmware aktuell ist oder beim Starten das sie nicht passt. Das hatte ich gleich als erstes geschrieben! Das hier ist simpel gehalten und nicht mit verwirrenden gcc Meldung zu vergleichen. Gut mir kann man vorwerfen das ich die Seite bei segger nicht gefunden habe und das mir einfach entgangen ist das der edu von gestern nicht mehr viel mit dem aktuellen edu zu tun hat. Aber er hat bis heute halt perfekt funktioniert. Jetzt ist ein auch recht alter st-link v2 dran und arbeitet, wenn auch langsamer.
> Was hätte dir persönlich denn geholfen?
Nun, das mit der Firmware ist schon interessant. Ich hatte z.B mit
Segger in den letzen 15Jahren keine Probleme, bis auf letzte Woche als
ich die Firmware aktualisiert habe. Seitdem vergisst meiner manchmal,
aber nicht bewusst reproduzierbar, das er eine Firmware hat. Dann
oeffnet sich das Fenster fuer den Firmwareupdate und er updated den
JLink nochmal. Soll heissen die haben aktuell anscheinend eine Firmware
die sie manchmal selber zerstoert.
Olaf
Ich denke dass die V 8 Hardware des J-Link auch die meisten neueren ARM Cores unterstützen könnte aber man braucht halt auch einen Anreiz um die aktuelle Hardware zu verkaufen. "Proof of concept": Ein J-Link EDU V8.00 unterstützt keinen Cortex-M7, es kommt die Fehlermeldung "The firmware of the connected debug probe [S/N: xxxxxx] does not support the connected core: Cortex-M7. Please make sure that a current debug probe model is used and it is running the latest firmware.". Wenn man die Prüfung auf den Core in der J-Link Windows Software umgeht dann klappt es, zumindest die elementaren Dinge wie Register- und Speicherzugriff oder Single-Step (getestet mit dem J-Link Commander). Es kann natürlich sein dass bestimmte Dinge wie Trace tatsächlich nur mit der aktuellen J-Link Hardware funktionieren aber beim Grundprinzip des JTAG/SWD Zugriff auf eine ARM CPU hat sich wenig geändert, deswegen gibt es eigentlich keinen Grund warum ein älterer J-Link das nicht können sollte, zumindest wenn er bereits SWD kann. Siehe z.B. auch bei OpenOCD, dort gibt es solche Einschränkungen bezüglich der unterstützten Interface-Hardware eher nicht.
Dieter schrieb: > deswegen > gibt es eigentlich keinen Grund warum ein älterer J-Link das nicht > können sollte, zumindest wenn er bereits SWD kann. Die J-Links enthalten in ihrem Controller die Algorithmen zum Flashen der Ziel-Hardware, was dadurch deutlich beschleunigt wird gegenüber dem klassischen Ansatz, das immer via USB den PC machen zu lassen. Aber der Flash des Controllers im J-Link bei Version 8 ist halt voll, es passen keine neuen Algorithmen für die neueren Controller wie STM32H7 mehr hinein. Segger könnte hier per Fallback das über den PC machen lassen, aber dann verliert man auch den größten Vorteil gegenüber ST-Link & Co - das ist aus Marketinggründen vermutlich nicht sehr attraktiv.
Niklas G. schrieb: > > Die J-Links enthalten in ihrem Controller die Algorithmen zum Flashen > der Ziel-Hardware, was dadurch deutlich beschleunigt wird gegenüber dem > klassischen Ansatz, das immer via USB den PC machen zu lassen. Aber der > Flash des Controllers im J-Link bei Version 8 ist halt voll, es passen > keine neuen Algorithmen für die neueren Controller wie STM32H7 mehr > hinein. Bei allen ARM CPUs, die ich bisher mit einem J-Link programmiert habe wurde der Code für das Flashen in den RAM des Mikrocontroller geladen. In der Firmware des J-Link steht nur der Code für den Low-Level Zugriff per JTAG bzw. SWD. Siehe auch OpenOCD, J-link wird von OpenOCD unterstützt, im OpenOCD Code sieht man ganz gut was das jeweilige Debug Interface macht. Es gibt von Segger auch die "Flasher" Hardware, die teilweise "standalone" betrieben werden kann. In diersem Fall steht der Code zum Flashen in der Interface Hardware.
> Ich denke dass die V 8 Hardware des J-Link auch die meisten neueren > ARM Cores unterstützen könnte Als Aussenstehender kann man sowas kaum realistisch beurteilen. Es ist aber sicher so das jede Firmware immer mehr Controller kennen muss. Also ihren Namen, ihre ID und wohlmoeglich aus ein Stueckfirmware ins Ram laden. Von daher ist es Grundsaetzlich nachzuvollziehen das irgendwann mal Schluss ist. Und ich meine auch das ARM selbst irgendwas an der Hardware geaendert hat weshalb man z.B Dualcores wie den RP2040 nicht mit alter Hardware flashen kann. Und dann gibt es noch Hersteller die unbedingt ihren eigenen Kram machen muessen, wie z.B der Icepick von TI. Auch das geht nicht einfach so. Olaf
Olaf schrieb: > > Als Aussenstehender kann man sowas kaum realistisch beurteilen. Dann schau halt mal in den Code von OpenOCD. Das kann im Prinzip das gleiche wie die Segger J-Link Software, nur vielleicht nicht so komfortabel. Das J-Link Interface wird von OpenOCD unterstützt, neben vielen anderen Debug Probes. Anhand von OpenOCD kann man sich alle Details zum Debuggen von ARM Cores anschauen. Unh wie ich oben schon geschrieben habe, ein J-Link EDU V8.00 kann z.B. auf einen Cortex-M7 zugreifen wenn man die Prüfung auf den Core wegläßt.
wenn es um Speed geht ist der STLink V3 auch gut, mit USB HS und 24 MHz SWD ist der auch sehr fix.
Wie kann man den die Prüfung abschalten? Ich nutze eigentlich unter emMBlitz den Segger-GDB-Server und der meldet das er den Chip nicht kennt und bricht ab. Ich brauche kein Trace oder so was, der muss nur laden, Breakpoints und Variblen auslesen können. Halt das normale Debugging.
Uli schrieb: > Wie kann man den die Prüfung abschalten? Man könnte z.B. die entsprechende DLL patchen. Details werde ich hier aber nicht veröffentlichen, Segger will ja auch was verdienen indem es seine Hardware verkauft. > Ich nutze eigentlich unter emMBlitz den Segger-GDB-Server und der meldet > das er den Chip nicht kennt und bricht ab. Ich bekomme im J-Link Commander die obige Fehlermeldungen in einer Windows MessageBox wenn ich mit einem J-Link EDU V8.00 auf einen Cortex-M7 zugreifen will. Ob das die selbe Ursache hat wie bei dem GDB Server kann ich nicht sagen, ich würde erwarten dass in diesem Fall der selbe Fehler kommen sollte. Wie schon geschrieben, wenn man dann die Prüfung umgeht klappt der Zugriff. > Ich brauche kein Trace oder so was, der muss nur laden, Breakpoints und > Variblen auslesen können. Halt das normale Debugging. Was spicht in diesem Fall gegen OpenOCD? Das läuft ja im Prinzip auf das selbe hinaus (imBezug auf den GDB). Windows Software von OpenOCD gibt es, der J-Link wird unterstützt. Es ist nur etwas mühsam sich in OpenOCD einzuarbeiten.
> Anhand von OpenOCD kann man sich > alle Details zum Debuggen von ARM Cores anschauen. Da hab ich so meine Zweifel weil das ein oder andere nur gegen NDA weitergereicht wird. > Wie kann man den die Prüfung abschalten? Ich weiss es jetzt nicht auswendig. Schau mal in die Doku, es gab Kommandos um mit generischen Cores zu connecten. Eventuell musst du dir dann dein eigenes .jlink File schreiben. Ob das aber immer und mit allen Funktionen funktioniert, keine Ahnung. Zum Beispiel weiss der Jlink dann ja nicht wie gross Ram und Flash sind und wo sie liegen. > Es ist nur etwas > mühsam sich in OpenOCD einzuarbeiten. Hihi, da haben wir es doch. Der Grund warum Segger so gross geworden ist, ist ja gerade das es so schoen einfach und idiotensicher funktioniert. Wer noch ein Dutzend Flasher aus der Vor-ARM-Zeit rumliegen hat weiss sicher was ich meine. Und der Grund warum viele Leute immer mit den Zaehnen knirschen scheint darin zu bestehen das Segger einfach fuer ihre Arbeit bezahlt werden will. :-) Olaf
Der Server gibt die selbe Fehlermeldung. Die DLL finden und das was ich ändern muss finden ist dann nicht so mein Ding. Da gibt es dann Spezialisten wie dich. OpenOCD habe ich mir gerade geladen, werde ich später testen.
Olaf schrieb: > > Da hab ich so meine Zweifel weil das ein oder andere nur gegen > NDA weitergereicht wird. Bei ARM muss man nur die veröffentliche Dokumentation lesen, u.a. die Technical Reference Manuals der jeweiligen Cores. Anstelle zu spekulieren also einfach mal Doku lesen oder in den Code von OpenOCD schauen.
Uli schrieb: > Ich nutze eigentlich unter emMBlitz den Segger-GDB-Server und der meldet > das er den Chip nicht kennt und bricht ab. Dann ist aber u.U. nur die installierte JLink Software zu alt.
meine Erfahrung ist, das die STM32H7 / F7 etwas zickig sind beim debuggen. Da muss das Debugregister in der CPU ständig gesetzt werden und Segger hat das am Besten im Griff, wobei das mit dem STLinkV3 jetzt auch gut funktioniert hat. Auf die Nucleo Boards kann man ja auch eine JLink Version flashen, damit geht das auch gut. Die älteren Nucleos haben doch auch nur eine STLinkV2 Hardware drauf, in dem Edu steckt doch sicher auch nichts anderes, da müsste der doch auch mit den H7 umgehen können?
OpenOCD will nicht laufen, XP ist dann dafür wohl zu alt. Die api-ms-win.... fehlt, davon habe ich zwar gut 5 Versionen aber keine davon geht. Vielleicht gibt es noch eine Version die geht. Ich werde auch mal versuchen eine altere OpenOCD version zu bekommen in der hoffnung das die besser läuft. Ansonsten läuft das Debuggen ja mit dem st-link V2, auch wenn nicht so schön wie mit dem Segger Teil. Habe mir mal so einige Produktbeschreibungen zu j_Link Clone angesehen. Komischerweise steht da V9 aber nicht das der einen Cortex M7 kann. Der Original V9 kann das aber laut Liste. So Kaufen oder lassen, das muss ich jetzt entscheiden. Ein Black-Magic-Probe oder ein ST-Link V3 wären auch noch eine Alternative! Am besten wäre es kann einfach einen neuen (V10 oder V11) J-Link EDU kaufen. Der wäre auch schneller hier.
Fakt ist, die letzte Firmware V8 ist von 2014. Bei den jlink-ob Geschichten die auf einem STM32F103 oder STMF32F072 laufen ist die Firmware von 2021 bzw. 2019. Damit würde ich ehr eine Chance sehen dass der H7 geht.
Uli schrieb: > Am besten wäre es kann einfach einen neuen (V10 oder V11) J-Link EDU > kaufen. Der wäre auch schneller hier. Na, dann nenn mal eine Quelle...
> Bei ARM muss man nur die veröffentliche Dokumentation lesen, > u.a. die Technical Reference Manuals der jeweiligen Cores. Ach, dann bin ich wohl doof. Zeig mir doch mal wo da drin steht wie der Routecontroller von TI funktioniert: https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_icepick.html In den MCUs ist nicht nur der Core drin. Mancher Hersteller bastelt da auch noch was eigenes. Olaf
Uli schrieb: > OpenOCD will nicht laufen, XP ist dann dafür wohl zu alt. > Die api-ms-win.... fehlt, davon habe ich zwar gut 5 Versionen aber keine > davon geht. Vielleicht gibt es noch eine Version die geht. > Ich werde auch mal versuchen eine altere OpenOCD version zu bekommen in > der hoffnung das die besser läuft. In diesem Buch wird auf eine OpenOCD Version verlinkt, die auf Windows XP laufen soll und den Cortex-M7 unterstützt: https://onlineacademiccommunity.uvic.ca/ihaz/wp-content/uploads/sites/1888/2017/01/mastering-stm32-sample.pdf Im Prinzip ist es diese Datei von OpenOCD: gnuarmeclipse-openocd-win32-0.10.0-201610281609-dev-setup.exe Ausserdem ist in dem Buch eine Einführung in OpenOCD, ob die was taugt weiss ich nicht.
Olaf schrieb: > > Ach, dann bin ich wohl doof. Zeig mir doch mal wo da drin steht > wie der Routecontroller von TI funktioniert: Was hat die Dokumentation von ARM mit einer spezifischen Erweiterung von TI zu tun? Der ARM Core funktioniert immer noch so wie von ARM dokumentiert. Der ICEPick ist im Prinzip nur dazu dass dass man bei einem einzigen JTAG Interface auswählen kann welches Target man bei einem Multi-Prozessor Chip ansprechen will. Für den ICEPick gibt es je nach Variante die Doku von TI. Und Segger zeigt in seinen eigenen Script-Beispielen wie man den ICEPick im OMAP des BeagleBoard anspricht.
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.