Forum: Markt [S] SEGGER J-Link EDU


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jonas (bird_person)


Lesenswert?

Hi zusammen,

leider sind die normalen EDU's nicht mehr bei den deutschen 
Distributoren gelistet.
Hat noch jemand einen abzugeben? Im besten Fall eine der neueren 
Hardwareversionen.

Viele Grüße

von N. M. (mani)


Lesenswert?

Jonas schrieb:
> Hat noch jemand einen abzugeben?

Theoretisch ja.

Jonas schrieb:
> m besten Fall eine der neueren Hardwareversionen.

Was wären die?

von Jonas (bird_person)


Lesenswert?

N. M. schrieb:
> Jonas schrieb:
>> Hat noch jemand einen abzugeben?
>
> Theoretisch ja.

Super :)

> Jonas schrieb:
>> m besten Fall eine der neueren Hardwareversionen.
>
> Was wären die?

z.B. V10 oder V11 mit RISC-V Unterstützung

von 900ss (900ss)


Lesenswert?

Jonas schrieb:
> z.B. V10 oder V11 mit RISC-V Unterstützung

Ich sehe zwar dass du explizit nach einen J-Link gefragt hast aber 
vielleicht hast du Lust dir den Black Magic Probe anzusehen. Der scheint 
inzwischen auch RISC-V support zu haben wenn auch noch nicht offiziell 
gelistet.
Hier im Forum wird es bestätigt:
https://github.com/blackmagic-debug/blackmagic/discussions/1751

Hier ist die Liste der offiziell unterstützen Targets:
https://black-magic.org/supported-targets.html

Ist schon umfangreich.

Ich habe mir den BMP auf ein STM32 Black Pill geflasht und es mit 
Raspberry Pi Pico und einem NRF52 gut benutzen können. Hat sauber 
funktioniert.
Solch ein Board:
https://stm32world.com/wiki/Black_Pill

Man kann auch BMP HW kaufen, die ist aber teurer als der J-Link EDU :)
Hier auf der Seite das abgebildete Board ist es.
https://black-magic.org/index.html

Bei dem EDU Mini hat Segger ja ordentlich abgespeckt gegenüber dem 
"alten" EDU, der ja auch ein Gehäuse hatte. Der Preis für den Mini 
entspricht aber dem alten EDU. Schade.

: Bearbeitet durch User
von Marc X. (marc_x)


Lesenswert?

Jonas schrieb:
> Hi zusammen,
>
> leider sind die normalen EDU's nicht mehr bei den deutschen
> Distributoren gelistet.
> Hat noch jemand einen abzugeben? Im besten Fall eine der neueren
> Hardwareversionen.
>
> Viele Grüße

Ja der alte EDU wurde komplett eingestellt, es gibt nur noch den Mini. 
Was vor kurzen noch erhältlich war waren nur noch Restbestände.

Beitrag "Re: Welchen SEGGER J-Link kaufen?"

von Jonas (bird_person)


Lesenswert?

Das BMP und BMP HW habe ich mir auch schon angesehen.

Praktisch daran, ist, dass die offizielle Probe auch mit Targets von 
1.7V bis 5V verbunden werden kann.
Wäre mit einem J-Link EDU auch kein Problem, aber die noch erhältliche 
mini-Variante kann das leider nicht.

Des Weiteren kann das BMP auch RTT was beim Debuggen eines nRF52 mit 
einem J-Link OB mich auch schon überzeugt hat, da möchte ich bei manchen 
Targets nicht mehr drauf verzichten.

EDIT: Ich war auch schon mit AK MODUL-BUS in Kontakt und habe den 
letzten EDU um eine Woche verpasst. Da war wohl nicht nur ich am 
Restbestand interessiert :)

: Bearbeitet durch User
von 900ss (900ss)


Lesenswert?

Jonas schrieb:
> Ich war auch schon mit AK MODUL-BUS in Kontakt

Bei Segger gibt es evtl. auch noch Reste?

von Marc X. (marc_x)


Lesenswert?

Jonas schrieb:
> EDIT: Ich war auch schon mit AK MODUL-BUS in Kontakt und habe den
> letzten EDU um eine Woche verpasst. Da war wohl nicht nur ich am
> Restbestand interessiert :)

Ich habe im November noch einen bekommen, aber ist schon ziemlich schade 
ich wollte mir auch noch einen zweiten großen holen damit ich nicht 
dauernd umstecken muss wenn ich zwischen meinen Projekten wechsel.

von Zero V. (Firma: Freelancer) (gnd)


Angehängte Dateien:

Lesenswert?

Ich hätte ein abzugeben. Ist der eine neuere Version?

: Bearbeitet durch User
von Jonas (bird_person)


Lesenswert?

Das sollte ein EDU der Version 11 aus 2020 KW 12.
Den nehme ich :) Was möchtest du dafür?

von N. M. (mani)


Lesenswert?

Zero V. schrieb:
> Ich hätte ein abzugeben. Ist der eine neuere Version?

Meiner ist deutlich älter 😅
08.2015 Version 9.3

von Mi N. (msx)


Lesenswert?


von 900ss (900ss)


Lesenswert?

Mi N. schrieb:
> https://www.antratek.de/j-link-edu-mini

Genau der war nicht gefragt. Der alte EDU ist einfach besser, nicht nur 
weil er ein Gehäuse hat. Der Mini kann z.B. nur 3.3V Pegel.

von Mi N. (msx)


Lesenswert?

900ss schrieb:
> Genau der war nicht gefragt. Der alte EDU ist einfach besser, nicht nur
> weil er ein Gehäuse hat. Der Mini kann z.B. nur 3.3V Pegel.

Gut, das hatte ich überlesen. Allerdings sind mir 5 V Pegel bei neueren 
µCs nicht mehr begegnet.
Alternativ hätte ich auch noch einen jLink-EDU mit Gehäuse abzugeben. 
Ein älteres Modell V 9.2, was ich kaum gebraucht hatte. Der eignet sich 
leider nicht für RP2040, aber man könnte ja das Gehäuse für einen 
EDU-mini verwenden ;-)

von Luca E. (derlucae98)


Lesenswert?

900ss schrieb:
> Der Mini kann z.B. nur 3.3V Pegel.

Das ist gut zu wissen. Nutze ihn regelmäßig an einem 5V Controller. 
Bisher ohne Probleme. Scheint also ziemlich robust zu sein das Teil.

von Harald K. (kirnbichler)


Lesenswert?

Luca E. schrieb:
> Das ist gut zu wissen.


"EDU"
Target interface voltage: 1.2V ... 5V

(https://www.segger.com/products/debug-probes/j-link/models/j-link-edu/)

"EDU mini"
Target interface voltage: 3.3V

(https://www.segger.com/products/debug-probes/j-link/models/j-link-edu-mini/)

Siehe auch Vergleichstabelle

https://www.segger.com/products/debug-probes/j-link/#c216543

von Vanye R. (vanye_rijan)


Lesenswert?

> Allerdings sind mir 5 V Pegel bei neueren µCs nicht mehr begegnet.

5V sind vollkommen irrelevant. Aber was ist wenn der naechste
Controller in 3Jahren mit 1.8V daher kommt?

Ausserdem gibt es ja auch Leute die stromsparendes Zeug entwickeln
und dann laeuft der Controller vielleicht mit irgendeiner Spannung
in seinem weiten Arbeitsbereich. Wobei Debuggen in so einem Fall
eh kritisch ist weil die Stromaufnahme der Controller erheblich
ansteigt sobald der Debugger einmal die Macrozelle dafuer in
der MCU angeschaltet hat.

Andererseits koennte man ja den Pegelwandler vermutlich recht einfach
nachruesten wenn man den wirklich braucht.

Wobei das ganze aber auch einen Nachteil hat. Die EDUs brauchen
von dem Arbeitsboard noch eine weitere Leitung mit der dortigen
Betriebsspannung. ICh denke mal das man sich die bei den kleinen
Teilen sparen kann.

Ich sehe den Vorteil der EDUs aktuell hauptsaechlich darin das man eine
robuste Plastikkiste im allgemeinen Chaos auf dem Schreibtisch hat.
Aber dem koennte man bei den kleinen Teilen mit einem 3D-Druck
natuerlich abhelfen. .-)

Vanye

von 900ss (900ss)


Lesenswert?

Vanye R. schrieb:
> ICh denke mal das man sich die bei den kleinen
> Teilen sparen kann.

Leider falsch. Vtarget wird gebraucht. Wenngleich sie fix mit 3.3V 
angegeben wird.

: Bearbeitet durch User
von Mi N. (msx)


Lesenswert?

Vanye R. schrieb:
>> Allerdings sind mir 5 V Pegel bei neueren µCs nicht mehr begegnet.
>
> 5V sind vollkommen irrelevant. Aber was ist wenn der naechste
> Controller in 3Jahren mit 1.8V daher kommt?

Wird heute wieder der Weltuntergang simuliert?
Den RP2040 hatte ich schon genannt. Dessen Kerne laufen mit typisch 1,2 
V. Erbarmen, zu spät, mit in 3 Jahren und 1,8 V ist also nichts mehr.

"Vielleicht, könnte, vermutlich, ..."
Deine Probleme sind voll konstruiert.
Obwohl mein EDU ein Gehäuse hat und mit 1,8 - 5 V Pegeln umgehen kann, 
ist er heute teilweise nicht mehr brauchbar. Auf Verdacht zu kaufen ist 
unsinnig.
Sollte sich in 10 Jahren tatsächlich der Bedarf geändert haben, kaufe 
ich mir ein anderes Teil: 100mal schneller und per Glasfaserverbindung 
auch gleich galvanisch getrennt ;-)

von Bauform B. (bauformb)


Lesenswert?

Vanye R. schrieb:
> Ausserdem gibt es ja auch Leute die stromsparendes Zeug entwickeln
> und dann laeuft der Controller vielleicht mit irgendeiner Spannung
> in seinem weiten Arbeitsbereich.

Das passiert auf jeder Platine, die eine eigene Stromversorgung hat. Die 
wird ja unabhängig vom Debugger ein- und ausgeschaltet und dadurch 
ergibt sich irgendeine Spannung, zumindest kurzzeitig. Eigentlich kann 
es ohne Pegelwandler garnicht funktionieren.

> Die EDUs brauchen von dem Arbeitsboard noch eine weitere Leitung
> mit der dortigen Betriebsspannung. ICh denke mal das man sich die
> bei den kleinen Teilen sparen kann.

Die Leitung ist für die Pegelwandler, die brauchen die Betriebsspannung, 
da kann man nicht sparen. Die BMP braucht diese Spannung auch, aber die 
hat sowieso den kleinen 10-poligen Stecker (ARM Cortex-M). Der kostet 
auf dem Target zwar 10 Bohrungen, aber eher weniger Fläche als jeder 
andere Stecker. Und man kann ein Flachkabel mit vernünftigen Steckern 
verwenden.

Ohne Pegelwandler könnte man die Debug-Hardware vom Target aus 
versorgen. Aber das kostet auch eine Leitung und die Stromaufnahme ist 
ziemlich hoch.

> Andererseits koennte man ja den Pegelwandler vermutlich recht
> einfach nachruesten wenn man den wirklich braucht.

Vielleicht. Der Pegelwandler für SWD braucht ein Direction-Signal. Und 
es kostet eine Platine. Wenn ich die Hardware selber bauen wollte, würde 
ich nicht nur Pegelwandler, sondern auch noch Potentialtrennung 
spendieren. Der Mehraufwand ist minimal. Mit der BMP-Firmware wäre das 
ein überaus attraktives Teil. Und vermutlich zukunftssicherer als 
kommerzielle Teile.

> Ich sehe den Vorteil der EDUs aktuell hauptsaechlich darin das man
> eine robuste Plastikkiste im allgemeinen Chaos auf dem Schreibtisch
> hat. Aber dem koennte man bei den kleinen Teilen mit einem 3D-Druck
> natuerlich abhelfen. .-)

Oder mit einem fertigen Gehäuse von Reichelt. Die aktuelle BMP-Hardware 
passt z.B. da rein:

https://www.reichelt.de/kunststoffgehaeuse-67-x-32-x-20-mm-5-stueck-rx2kl07-s-5-p292746.html?&nbc=1

von 900ss (900ss)


Lesenswert?

Mi N. schrieb:
> Den RP2040 hatte ich schon genannt. Dessen Kerne laufen mit typisch 1,2
> V. Erbarmen, zu spät, mit in 3 Jahren und 1,8 V ist also nichts mehr.

Die Spannung der Kerne hat hier aber nichts mit den Pegeln der SWD Pins 
zu tun. Die sind an der IOVdd Power Domain angeschlossen und die geht 
bis max. 3.6V.
Das bedeutet das du den EDU Mini wie auch den "reiner" Mini verwenden 
kannst für den RP2040 wenn IOVdd an 3.3V liegen.
Siehe Datenblatt 5.5.2.2 und 5.5.3.1.

: Bearbeitet durch User
von Mi N. (msx)


Lesenswert?

900ss schrieb:
> Die Spannung der Kerne hat hier aber nichts mit den Pegeln der SWD Pins
> zu tun. Die sind an der IOVdd Power Domain angeschlossen und die geht
> bis max. 3.6V.

Mir mußt Du das nicht erklären.

von 900ss (900ss)


Lesenswert?

Mi N. schrieb:
> Mir mußt Du das nicht erklären.

Das lass sich hier anders.

Mi N. schrieb:
> Vanye R. schrieb:
>>> Allerdings sind mir 5 V Pegel bei neueren µCs nicht mehr begegnet.
>>
>> 5V sind vollkommen irrelevant. Aber was ist wenn der naechste
>> Controller in 3Jahren mit 1.8V daher kommt?
>
> Wird heute wieder der Weltuntergang simuliert?
> Den RP2040 hatte ich schon genannt. Dessen Kerne laufen mit typisch 1,2
> V. Erbarmen, zu spät, mit in 3 Jahren und 1,8 V ist also nichts mehr.

Und sonst lies es zur Klarstellung für andere :)

: Bearbeitet durch User
von Vanye R. (vanye_rijan)


Lesenswert?

> Das bedeutet das du den EDU Mini wie auch den "reiner" Mini verwenden
> kannst für den RP2040 wenn IOVdd an 3.3V liegen.

Vielleicht noch was zur Klarstellung! Ich hatte einen der ersten
EDUs als die damals rauskamen. Keine Ahnung wie lange das her ist,
aber sicher mehr wie 10Jahre. Der funktioniert auch heute noch
mit allem was man so begegnet bis auf den RP2040. Das war der
erste Controller der von der alten Hardware nicht mehr unterstuetzt
wurde und fuer mich ein Grund wieso ich mir letztes Jahr einen
neuen EDU gekauft habe.
Aber man kann natuerlich davon ausgehen das es in Zukunft mehr
werden fuer denen man die neue Version braucht.

Vanye

von 900ss (900ss)


Lesenswert?

Nachtrag:
Der JLink EDU hat noch einen großen Vorteil gegenüber dem Black Magic 
Probe. Er ist deutlich schneller als der BMP (auf einem Black Pill) z.B. 
beim Flashen per SWD. Gerade hab ich es bei einem Rapsberry Pi Pico als 
Target probiert.
Siehe am Ende die Transfer rate. Und selbst bei diesem "kleinen" 
Programm macht das einen Unterschied von knapp 20 Sekunden. Das war mit 
der aktuellen BMP Firmware.
1
Black Magic Probe:
2
3
(gdb) load picoTest.elf
4
Loading section .boot2, size 0x100 lma 0x10000000
5
Loading section .text, size 0x4688 lma 0x10000100
6
Loading section .rodata, size 0xf44 lma 0x10004788
7
Loading section .binary_info, size 0x28 lma 0x100056cc
8
Loading section .data, size 0x9754 lma 0x100056f4
9
Start address 0x100001e8, load size 61000
10
Transfer rate: 4 KB/sec, 938 bytes/write.
11
12
Segger JLink EDU:
13
14
(gdb) load picoTest.elf
15
Loading section .boot2, size 0x100 lma 0x10000000
16
Loading section .text, size 0x4688 lma 0x10000100
17
Loading section .rodata, size 0xf44 lma 0x10004788
18
Loading section .binary_info, size 0x28 lma 0x100056cc
19
Loading section .data, size 0x9754 lma 0x100056f4
20
Start address 0x100001e8, load size 61000
21
Transfer rate: 4582 KB/sec, 7625 bytes/write.

Dafür kann man sich unter Umständen "schnell" einen BMP bauen mit Teilen 
aus der Schublade wenn man keinen Jlink hat :)

von Mi N. (msx)


Lesenswert?

900ss schrieb:
> Transfer rate: 4 KB/sec, 938 bytes/write.

Da wird bestimmt jedes Bit in veganes Geschenkpapier verpackt und CO2 
neutral übertragen.
Aber Faktor 1000 ist schon heftig!

Mich hat am EDU immer der tagtägliche Hinweis genervt. ST-Link war genau 
so schnell und in der Handhabung völlig unauffällig.

von Vanye R. (vanye_rijan)


Lesenswert?

> ST-Link war genau so schnell und in der Handhabung völlig unauffällig.

Es gibt ja auch noch andere Hersteller von ARM basierten Controllern. 
ICh hab auch schon Nordic und NXP genutzt. Ausserdem ist Segger nicht 
nur unaufaellig sondern die bieten auch viel Zusatzkram. Ich hab mir 
damit z.B vollkommen problemlos ein Tool (unter Linux) geschrieben das 
aus dem laufenden Controller mich interessierende Variablenwerte 
ausliesst. Und auch der virtuelle serielle Port ist doch ganz nett.
Die Anschaffung lohnt sich IMHO auch als privater Bastler und vor allem 
auch unter Linux. Alles entspannt funktionsfaehig. Und es ist in 
Extremfaellen
auch schoen einfach direkt ein gdb-Fenster aufmachen zu koennen und dann 
wirklich das alle Befehle des gdb nutzen koennen. Vermutlich gibt es 
hier manche die garnicht wissen was damit alles geht. Schaut mal rein! 
Wenn ihr denkt das was Eclipse bietet sei bereits der Debugger, nein das 
sind 5% der Moeglichkeiten die gdb direkt kann.

Wer unbedingt auf Geldsparen aus ist und nur ST verwendet kann auch ein 
Entwicklungskit von ST nehmen, dort den Debugger absaegen und das Teil 
auf Jlink umprogrammieren. Segger bietet dazu auf ihrer Homepage extra 
ein Tool an.

Aber ehrlich gesagt bei den Moeglichkeiten eines EDUs schieb ich die 
Kohle mit Freude ueber den Tisch!

Vanye

von 900ss (900ss)


Lesenswert?

Mi N. schrieb:
> Mich hat am EDU immer der tagtägliche Hinweis genervt.

Na ja....

Mi N. schrieb:
> ST-Link war genau so schnell und in der Handhabung völlig unauffällig.

Mit welcher Firmware? Da kann man JLink draufspielen und auch Black 
Magic Probe. Aber ich glaube beim JLink kann man dann nur ST-Chips 
nutzen. Weiß es aber nicht genau.

von 900ss (900ss)


Lesenswert?

Mi N. schrieb:
> Aber Faktor 1000 ist schon heftig!

Mit kommt das auch etwas arg wenig vor. Allerdings machen sie alles per 
Bit Banging.
Vielleicht Frage ich mal nach ob das so sein muss bei einem Black Pill 
als BMP HW.

von Mi N. (msx)


Lesenswert?

Vanye R. schrieb:
> Vermutlich gibt es
> hier manche die garnicht wissen was damit alles geht. Schaut mal rein!

Da gehöre ich sicherlich dazu. Die Programmierteile benutze ich wie 
einen Lötkolben: einschalten und loslegen - ein Werkzeug eben.

> Und auch der virtuelle serielle Port ist doch ganz nett.

Ist bei ST-Link und bei den aktuellen ST-Entwicklungsboards doch auch 
dabei. Für mich als Bastler reicht das völlig aus.

Ich hoffe, der TO hat mittlerweile etwas Passendes gefunden.

von Bauform B. (bauformb)


Lesenswert?

Probier mal, das Programm ins RAM zu laden statt ins Flash. Das geht bei 
mir sehr viel schneller.

Eigentlich müsste doch zuerst ein kleines Hilfsprogramm ins RAM geladen 
werden. Das weiß, wie der spezielle Chip geflasht wird. Das eigentliche 
Programm wird dann auch erst ins RAM geladen, ggf. blockweise.

von 900ss (900ss)


Lesenswert?

Bauform B. schrieb:
> Probier mal, das Programm ins RAM zu laden statt ins Flash. Das geht bei
> mir sehr viel schneller.

Es geht auch ins Flash schnell wie der JLink zeigt.
Mir gefällt der BMP aber trotzdem gut. Er bietet auch RTT, ein sehr 
hilfreiches Feature.

: Bearbeitet durch User
von Vanye R. (vanye_rijan)


Lesenswert?

> Probier mal, das Programm ins RAM zu laden statt ins Flash. Das geht bei
> mir sehr viel schneller.

Das ist in der Regel nicht sinnvoll weil du dann ein Programm
anders uebersetzen musst und auch ein anderes Zeitverhalten hast.

> Eigentlich müsste doch zuerst ein kleines Hilfsprogramm ins RAM geladen
> werden. Das weiß, wie der spezielle Chip geflasht wird.

Ueberraschung. So macht der J-Link das. Und der flasht wohl auch nur 
Teile die sich wirklich geaendert haben neu. Das duerfte mit zu seiner 
hohen Geschwindigkeit beitragen und nebenbei die Lebensdauer der MCU 
erhoehen.

Vanye

von J. S. (jojos)


Lesenswert?

Das mit den 4 kB/s kann nicht sein, da wäre ich schon lange an Koffein 
Überdosierung gestorben. Habe BMP auch lange Zeit benutzt, sogar auf dem 
F103 war der ordentlich schnell. Für meine modifizierte Variante mit 
F407 und Ethernet habe ich so an die 20 MB/s in Erinnerung.
Da muss irgendwas faul sein.

von Mi N. (msx)


Lesenswert?

Vanye R. schrieb:
> Ueberraschung. So macht der J-Link das. Und der flasht wohl auch nur
> Teile die sich wirklich geaendert haben neu. Das duerfte mit zu seiner
> hohen Geschwindigkeit beitragen und nebenbei die Lebensdauer der MCU
> erhoehen.

Jetzt wird es wohl esoterisch ;-)
Dem Controller ist das völlig schnuppe und der FLASH-Speicher läßt sich 
nur (mindestens) sektorweise löschen, was richtig Zeit (typ. 45 ms / 4KB 
Sektor) braucht, und neu beschreiben.
Vielleicht schreibt BMP in zu kleinen Häppchen?

von 900ss (900ss)


Lesenswert?

J. S. schrieb:
> Da muss irgendwas faul sein.

Den Verdacht habe ich auch. Aber ich habe gerade keine Idee, was ich 
falsch mache. Übersetzt wird nach deren Anweisung. Habe die letzte 
Version, also aktuell.
Muss ich nochmal schauen.

von J. S. (jojos)


Lesenswert?

hast du einen STM32 zum flashen da? Ob es beim RP2040 langsamer ist? 
Obwohl ich mir das auch nicht recht vorstellen kann.

von Bauform B. (bauformb)


Lesenswert?

Vanye R. schrieb:
>> Probier mal, das Programm ins RAM zu laden statt ins Flash. Das geht bei
>> mir sehr viel schneller.
>
> Das ist in der Regel nicht sinnvoll weil du dann ein Programm
> anders uebersetzen musst und auch ein anderes Zeitverhalten hast.

Ja, in der Regel, hier hast du die berühmte Ausnahme ;) Im Extremfall 
wurde die BMP durch eine zu niedrige Baudrate ausgebremst und die würde 
ins RAM genauso bremsen. Oder der SWC Takt ist zu langsam. Oder sowas.

von 900ss (900ss)


Lesenswert?

J. S. schrieb:
> hast du einen STM32 zum flashen da?

Ja, ich könnte einen Black Pill mit einem Black Pill flashen ;)

NRF52842 müsste hier auch noch rumdiffundieren :) ESP32 hat kein SWD 
wenn ich mich nicht irre.

Ich glaube ich weiß zumindest weshalb der JLink soooo schnell war. Ich 
habe die gleiche SW geflasht die schon drin war %-) Ich hatte nicht mehr 
auf den Schirm dass der JLink das intelligent macht wie oben schon 
beschrieben. Er scheint nur für Blöcke zu schreiben die sich auch 
geändert haben. Das war mir vor 10+- Jahren schonmal aufgefallen aber 
die Gehirnzelle mit dem Wissen scheint tot.
Ich probiere das wenn ich wieder an meiner Werkbank sitze.

: Bearbeitet durch User
von 900ss (900ss)


Lesenswert?

900ss schrieb:
> Ja, ich könnte einen Black Pill mit einem Black Pill flashen

Das hab ich jetzt gemacht. Sieht dann schon deutlich besser aus.
1
(gdb) load project.elf 
2
Loading section .text, size 0x2708 lma 0x8000000
3
Loading section .rodata, size 0x70a30 lma 0x8002708
4
Loading section .data, size 0x858 lma 0x8073138
5
Start address 0x08000600, load size 473488
6
Transfer rate: 54 KB/sec, 980 bytes/write.

Aber an den JLink kommt er auch hier nicht ran. Den JLink hab ich 
nochmal laufen lassen und vorher das Flash gelöscht. Er bleibt so 
schnell.

Wenn der Black Magic Probe den Rpi Pico flasht, muss er ja auch noch 
durch das QSPI Interface um an das Flash zu kommen. Wenn die das alles 
"zu Fuss" machen, dann dauert das natürlich. Ist zumindest meine 
Erklärung.

Das Debuggen auf dem Pico mit BMP geht allerdings nicht langsam. Und das 
RTT beim BMP geht auch deutlich schneller als einen UART zu bemühen.

Den NRF52 noch zu testen hab ich jetzt keine Lust ;)

Nachtrag: Es gibt für den BMP noch den Befehl "mon frequency xxxk/M". 
Mit dem konnte ich die Rate noch etwas erhöhen (wiederholbar).
1
Start address 0x08000600, load size 473488
2
Transfer rate: 65 KB/sec, 980 bytes/write.

: Bearbeitet durch User
Bitte 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
Noch kein Account? Hier anmelden.