A. B. schrieb: > Das [Black Magic Probe] ist ganz nett für "ältere" Chips. Ansonsten > hat man ständig das Problem, den Firmware-Updates hinterher zu laufen. > Mal schnell die Unterstützung der neuesten Varianten (z. B. 32h7) > einzubauen, geht auf dem Host doch etwas bequemer. Das ist ein Problem, aber das habe ich doch bei Segger genau so und mit dem ST-Link erst recht? Das Teil kann laut Werbetext genauso viel wie die anderen, braucht aber kein Adapterkabel und braucht vor allem keine Spezial-Software auf dem PC. Dank eingebautem gdb-Server mit virtuellem COM-Port braucht man nur den gdb und sonst nichts. Weil es so viel simpler ist als kommerzielle Lösungen sollte viel problemloser und überall funktionieren. Schade ist, dass man keine Potentialtrennung spendiert hat, obwohl die Steuersignale für Pegelwandler vorhanden sind, die man auch für Optokoppler nutzen könnte. Schade ist, dass man die ursprüngliche Mini-USB durch eine Micro-USB ersetzt hat. Aber sonst? Der/die/das BMP kostet genauso viel wie ein J-Link EDU darf aber frei verwendet werden. Also, warum liest man in diesem Forum so wenig darüber? Was übersehe ich?
Bauform B. schrieb: > Schade ist, dass man die ursprüngliche Mini-USB durch eine Micro-USB > ersetzt hat Warum findest du das schade? Micro USB ist viel robuster und zuverlässiger. Mini USB ist tatsächlich die schlechteste von allen Steckervarianten. Von der Black Magic Probe hab ich bislang noch nie gehört. Ich nutze den Atmel-ICE für 8-Bit AVRs und für 32-Bit SAMs. Für STM32 Comtroller auf eigenen Boards hab ich 'nen ST-Link V2 und dann hab ich noch ein paar Nucleo- und Discovery- Boards mit integriertem ST-Link Debugger. Da das soweit alles prima funktioniert, hatte ich bislang weder Bedarf, noch großartig Interesse an anderen Debug-Adaptern. Das einzige, was mich noch mal reizen würde, wäre eine erschwingliche Lösung für HW-Trace in STM32 Controllern.
Bauform B. schrieb: > A. B. schrieb: >> Das [Black Magic Probe] ist ganz nett für "ältere" Chips. Ansonsten >> hat man ständig das Problem, den Firmware-Updates hinterher zu laufen. >> Mal schnell die Unterstützung der neuesten Varianten (z. B. 32h7) >> einzubauen, geht auf dem Host doch etwas bequemer. > > Das ist ein Problem, aber das habe ich doch bei Segger genau so und > mit dem ST-Link erst recht? Ja, beim Segger auch, weil bei einer älteren Version eventuell der Flash knapp wird. Beim BMP kann man sich natürlich selber leicht aus der Affäre ziehen: Man kompiliert die FW halt selbst, nachdem man die ggf. nicht benötigten Teile (Targets) entfernt hat. Aber wenn sich die "Wunschliste" mal ändert, macht man das wieder von vorn. Bem ST-Link (V2!) gibt's das Problem nicht so, weil der sich nicht drum kümmert, was für ein Target dran hängt. Der kann auch SWD mit Targets, die nicht von ST sind. Analog mit einem "dummen" JTAG-Adapter. > Der/die/das BMP kostet genauso viel wie ein J-Link EDU darf aber frei > verwendet werden. Also, warum liest man in diesem Forum so wenig > darüber? Was übersehe ich? Ausprobieren?! Da wir doch die Freiheit der Wahl haben ... Paradiesisch halt.
Bauform B. schrieb: > A. B. schrieb: (Vor 18 Monaten) > Das Teil kann laut Werbetext ... [weitere Zitate aus dem "Werbetext" - schnipp] > Schade ist, dass man keine Potentialtrennung spendiert hat, obwohl die > Steuersignale für Pegelwandler vorhanden sind, die man auch für > Optokoppler nutzen könnte. Das ist ein open source Projekt. Du darfst dich da gerne austoben. Allerdings ist es im Zweifel wesentlich einfacher, die Potentialtrennung auf der USB-Seite vorzunehmen. USB-Isolatoren gibt es fix und fertig. Warum sollte man da selber noch dran rumschrauben? > Schade ist, dass man die ursprüngliche > Mini-USB durch eine Micro-USB ersetzt hat. Micro-USB ist der bessere Steckverbinder, da leiert nämlich nicht die Buchse aus, sondern nur das (leicht ersetzbare) Kabel. > Der/die/das BMP kostet genauso viel wie ein J-Link EDU darf aber frei > verwendet werden. Also, warum liest man in diesem Forum so wenig > darüber? Was übersehe ich? Das BMP hat eine kleine Fangemeinde. Auch hier im Forum. Ich selber habe auch eins gebaut, das ich hin und wieder verwende. Oft aber auch nicht, z.B. wenn ich mit einem Nucleo unterwegs bin und da den ohnehin fertig angeflanschten ST-Link benutzen kann. Das BMP ist ja ursprünglich ein kommerzielles Projekt. Scheint aber nicht sonderlich gut eingeschlagen zu sein. Das heißt aber nicht, daß es schlecht ist. Eher im Gegenteil. Deswegen muß man da auch nicht groß Werbung für machen. Die lauteste Werbung brauchen schlechte Produkte.
Thorsten S. schrieb: > Für STM32 Comtroller auf eigenen Boards hab ich 'nen ST-Link V2 und dann > hab ich noch ein paar Nucleo- und Discovery- Boards mit integriertem > ST-Link Debugger. Für eigene Boards benutze ich den eingebauten Bootloader, das funktioniert. Vor allem verwendet der garantiert den richtigen Flash-Algorithmus. Mehr konnte ich bisher mit meinem L476-Nucleo auch nicht anfangen. Deshalb diese Frage hier. > Das einzige, was mich noch mal reizen würde, wäre eine erschwingliche > Lösung für HW-Trace in STM32 Controllern. Genau darum geht's mir auch. Ein guter Mittelweg wäre doch ein Call- und/oder Branch-Trace per TRACESWO. Aber ich finde absolut keinen Hinweis wie das funktionieren könnte, weder bei ST, noch bei ARM. Ist printf wirklich alles, was man aus TRACESWO raus locken kann? Ein halbes UART mehr, nett, aber das kann's doch nicht sein? Axel S. schrieb: >> Schade ist, dass man keine Potentialtrennung spendiert hat, obwohl die >> Steuersignale für Pegelwandler vorhanden sind, die man auch für >> Optokoppler nutzen könnte. > > Das ist ein open source Projekt. Du darfst dich da gerne austoben. > Allerdings ist es im Zweifel wesentlich einfacher, die Potentialtrennung > auf der USB-Seite vorzunehmen. USB-Isolatoren gibt es fix und fertig. Eine eigene BMP-Platine ist ja keine Raketenwissenschaft, die muss ja nicht so klein sein. Dafür gibt's keine Masseschleifen über PC und Oszi mehr. Ein USB-Isolator kann das natürlich auch, aber dann hängt der ganze Adapter an der Target-Stromversorgung. Das funktioniert nur bei 3.3V und bei Low-Power Anwendungen eher garnicht. Axel S. schrieb: aufmunternde Worte -- danke dafür.
Bauform B. schrieb: > Genau darum geht's mir auch. Ein guter Mittelweg wäre doch ein Call- > und/oder Branch-Trace per TRACESWO. Aber ich finde absolut keinen > Hinweis wie das funktionieren könnte, weder bei ST, noch bei ARM. Ist > printf wirklich alles, was man aus TRACESWO raus locken kann? Ein halbes > UART mehr, nett, aber das kann's doch nicht sein? TRACESWO ist nur die Schnittstelle der TPIU nach außen. Und ist halt ein halbes UART (in einer der möglichen Konfigurationionen). Was in die TPIU hineingeht, ist durchaus konfigurierbar, z. B. Data Watchpoint Trigger, dazu muss man ins RM und die Doku von ARM schauen. Im Prinzip auch manuell konfigurierbar, nur ein paar Register "beackern". Man sucht sich die gewünschten Events heraus und setzt die entprechenden Bits ... Der Haken dabei ist die Geschwindigkeit. Allein die Zeitstempel umfassen 6 Bytes ... Das ergibt ruckzuck einen Überlauf. Deshalb alternativ synchrone Trace-Ausgänge, und zwar bis zu (theoretisch) 32 Bit breit. Real habe ich nur bis zu 4 Bit gesehen. Und irgendjemand muss die Daten eben auch in der Geschwindigkeit verdauen ...
Der SWV in der CubeIDE zeigt vieles das ich zugegeben nicht verstehe. Auch ohne printf. In den SWV Fenstern werden je nach Einstellungen massenhaft Ereignisse und Daten angezeigt.
Bauform B. schrieb: > Axel S. schrieb: >>> Schade ist, dass man keine Potentialtrennung spendiert hat, obwohl die >>> Steuersignale für Pegelwandler vorhanden sind, die man auch für >>> Optokoppler nutzen könnte. >> >> Das ist ein open source Projekt. Du darfst dich da gerne austoben. >> Allerdings ist es im Zweifel wesentlich einfacher, die Potentialtrennung >> auf der USB-Seite vorzunehmen. USB-Isolatoren gibt es fix und fertig. > > Ein USB-Isolator kann das natürlich auch, aber dann hängt der > ganze Adapter an der Target-Stromversorgung Ja, und? > Das funktioniert nur bei 3.3V und bei Low-Power Anwendungen > eher garnicht. Bahnhof. Das BMP hat doch Levelshifter (TXS0108) und kann damit 1.65V bis 5.5V auf der Targetseite. Das Target muß auch nur den Levelshifter versorgen, das BMP selber läuft aus der (isolierten) V_bus. Außerdem brauchen geschätzt 95% der Anwender sowieso nie eine Isolation. Es ist schlicht nicht sinnvoll, das standardmäßig auf den Debug-Adapter zu packen.
Angehängte Dateien:
-
BMP-Baite.jpg
33 KB -
st-link_v2_baite-x4.svg
63 KB
die BMP mag ich auch am gernsten, vor allem weil man nichts konfigurieren muss. In VSCode reichen diese paar Zeilen, es muss praktisch nur der COM Port und das .elf file angegeben werden. Über die Environmentvariablen geht das auch allgemein, damit kann das einfach in andere Projekte kopiert werden. Mit STM32F1/F4 und nRF51 funtioniert das bei mir sehr gut, auch 200 kB Code ist in ein paar Sekunden geladen. Als Hardware benutze ich diese: https://de.aliexpress.com/item/32322884886.html Die haben noch zwei Pins die für einen UART genutzt werden. Hier im Forum ist U. Bonnes aktiv wenn es um BMP geht, er hat da auch einiges weiterentwickelt. Das Original BMP ist jetzt wohl an Adafruit verkauft worden, die Quellen und das Repo gibt es aber noch. aus der launch.json:
1 | {
|
2 | "cwd": "${workspaceRoot}",
|
3 | "name": "debug COM12", |
4 | "BMPGDBSerialPort": "//./COM12", |
5 | "interface": "swd", |
6 | "type": "cortex-debug", |
7 | "request": "launch", |
8 | "servertype": "bmp", |
9 | "device": "STM32F407VE", |
10 | "executable": "../../BUILD/${workspaceFolderBasename}/DEBUG/${workspaceFolderBasename}.elf"
|
11 | }, |
hier ist noch ein älterer Artikel aus dem Forum dazu: https://embdev.net/articles/STM_Discovery_and_Nucleo_as_Black_Magic_Probe Aber auch die SuFu liefert einiges. Edit: Bild und svg für Aufkleber angefügt
Angehängte Dateien:
-
itm_stimulus.png
97 KB
Bauform B. schrieb: > Ist printf wirklich alles, was man aus TRACESWO raus locken kann? Das geht schon einiges mehr. Der entsprechende Dialog in der Cube IDE zeigt es. Rot eingekreist ist das Flag für Log Meldungen, alles andere sind weitere Funktionen die darüber hinaus gehen.
Angehängte Dateien:
-
IMG_0141s.jpg
140 KB -
IMG_0144s.jpg
28 KB
gerade frisch von Mouser geliefert worden, der neue STLink V3. Soll mit BMP allerdings nur mit STM funktionieren wenn ich das richtig in Erinnerung habe, aber für 9,13 € netto konnte ich nicht widerstehen. Da ist kein kleiner F103 mehr drauf sondern ein fetter F723.
A. B. schrieb: > TRACESWO ist nur die Schnittstelle der TPIU nach außen. Und ist halt ein > halbes UART (in einer der möglichen Konfigurationionen). Was in die TPIU > hineingeht, ist durchaus konfigurierbar, z. B. Data Watchpoint Trigger stimmt, die können sehr nützlich sein. Dann gibt es noch diverse Zyklenzähler. Für mehr als Benchmarks scheinen die nicht zu taugen. Das einzige, was in Richtung trace geht, sind die exception trace Päckchen. Für spezielle Fälle mag man die, aber einfach nur zuschauen, was das Programm macht, ist nicht drin. Der entscheidende Unterschied ist doch, ob ich etwas ins Programm einbauen muss. Natürlich kann ich dann ganz gezielt genau die richtigen Daten raus holen. Aber ich hatte mir vom TRACESWO mehr versprochen. Insofern bieten die kleinen Cortex-M kaum mehr als printf über normale UARTs. Der Hardware-Aufwand für (halbwegs) echtes trace ist gleich soviel größer, dass das für mich nicht in Frage kommt. > Der Haken dabei ist die Geschwindigkeit. Das kommt noch dazu. > Allein die Zeitstempel umfassen 6 Bytes Es gibt auch kleinere, eigentlich in jeder Größe. Das ist dann das Delta-t zwischen zwei Päckchen. > Und irgendjemand muss die Daten eben auch in > der Geschwindigkeit verdauen ... Da ist dann gleich USB der Flaschenhals. Aber kein Problem, Segger hat Adapter mit Ethernet ;)
Bauform B. schrieb: > Aber kein Problem, Segger hat Adapter mit Ethernet Immer diese Schleichwerbung... ich find's Ok, wenn es wie hier zur Frage passt.
Johannes S. schrieb: > der neue STLink V3 RS hat seine vermutlich gerade falsch einsortiert und findet sie nicht. :) https://de.rs-online.com/web/p/debugger-programmiergerate-und-in-circuit-emulatoren/1961915/ Ist auch ein Adapter von 1,27mm auf "Normal" dabei?
Axel S. schrieb: >> Das funktioniert nur bei 3.3V und bei Low-Power Anwendungen >> eher garnicht. > > Bahnhof. Das BMP hat doch Levelshifter (TXS0108) und kann damit 1.65V > bis 5.5V auf der Targetseite. Das Target muß auch nur den Levelshifter > versorgen, das BMP selber läuft aus der (isolierten) V_bus. Ja. OK. So geht's natürlich gut. Gibt es solche Isolatoren auch fertig? Der muss doch mehr als ein paar mA liefern? Stefan ⛄ F. schrieb: > Bauform B. schrieb: >> Ist printf wirklich alles, was man aus TRACESWO raus locken kann? > > Das geht schon einiges mehr. Der entsprechende Dialog in der Cube IDE > zeigt es. Rot eingekreist ist das Flag für Log Meldungen, alles andere > sind weitere Funktionen die darüber hinaus gehen. Vielen Dank für das Bild! Trace-Funktionen sind da ja auch nicht dabei. Wenn die Original-Software auch nicht mehr kann, brauche ich wohl nicht weiter zu suchen -- oder gerade? weil es Cube ist ;) Johannes S. schrieb: > ...der neue STLink V3... Der wird auch nicht mehr können, die kleinen Chips sind der Engpass... Und er braucht wohl auch die Software von ST auf dem PC.
pegel schrieb: > Ist auch ein Adapter von 1,27mm auf "Normal" dabei? nein, nur ein Flachbandkabel mit 1,27 mm 14 pol. Buchse auf beiden Seiten.
Johannes S. schrieb: > nein, nur ein Flachbandkabel mit 1,27 mm 14 pol Danke. Dann werde ich doch lieber mal ein Nucleo mit V3 zum spielen nehmen.
Auch den Johannes S. schrieb: > Soll mit > BMP allerdings nur mit STM funktionieren wenn ich das richtig in > Erinnerung habe, Mit der ST Programmern funktioniert er sowieso nur mit ST Bausteinen. BMP als PC Programm fuer native STLinks funtioniert prinzipiell fuer alle Familien, die BMP unterstuetzt. Allerdings verweigert die STLink3 Vararianten aktiv das Zusammenspiel mit anderen Familien.
A. B. schrieb: > Der Haken dabei ist die Geschwindigkeit. Allein die Zeitstempel umfassen > 6 Bytes ... Das ergibt ruckzuck einen Überlauf. Deshalb alternativ > synchrone Trace-Ausgänge, und zwar bis zu (theoretisch) 32 Bit breit. > Real habe ich nur bis zu 4 Bit gesehen. Und irgendjemand muss die Daten > eben auch in der Geschwindigkeit verdauen ... Ich habe schon mit 16 Bit ETM@100Mhz (Der Vorläufer von Serial Wire Trace, Arm 966) und 4 Bit Serial Wire@50Mhz an Cortex M4 gearbeitet. Ist schon eine geniale Sache, aber man braucht auch einen anständigen Debugger damit man damit was anfangen kann. So sehr ich selbst Opensource mag, da muss man Geld in die Hand nehmen. Die Debugger die wir verwenden haben 512MB onboard RAM, weder USB2.0 noch 1GB/s Ethernet wäre schnell genug die Daten wegzuschaffen. Ich glaube die neuen Modelle haben USB3.0/3.1 damit sollte es dann gehen. Die Software kommt altbacken daher ist aber sehr mächtig und nach einiger Zeit wünscht man sich so eine Umgebung auch für den GDB. (Wobei, deren Software kann auch mit GDB Debug Servern sprechen). Man kann im Trace-Modus auch rückwärts steppen. Ich kenne bsiher kein OSS die das auch kann.
Andreas M. schrieb: > Die Debugger die wir verwenden haben 512MB onboard RAM Wofür brauchen/benutzen Debugger viel RAM?
Stefan ⛄ F. schrieb: > Andreas M. schrieb: >> Die Debugger die wir verwenden haben 512MB onboard RAM > > Wofür brauchen/benutzen Debugger viel RAM? Mindestens für die Adressen. 32 Bit mal 100MHz sind 400MB pro Sekunde, oder nicht? Früher konnte ich noch 16 andere Signale mit aufzeichnen. Aber früher war ja alles viel besser.
> Wofür brauchen/benutzen Debugger viel RAM? Bauform B. schrieb: > Mindestens für die Adressen. 32 Bit mal 100MHz sind 400MB pro Sekunde, > oder nicht? Früher konnte ich noch 16 andere Signale mit aufzeichnen. > Aber früher war ja alles viel besser. Ich kann Dir leider nicht folgen, vermutlich weil ich keine Ahnung habe. Nach meinem Verständnis kann ich mit einem Debugger in die CPU und den Speicher des laufenden Target hinein gucken. Und ich kann ein paar Konfigurationen vornehmen, wie SWO aktivieren und Haltepunkte setzen. Dafür braucht der Debugger quasi keinen Speicher, denke ich. Was meinst du denn mit "Mindestens für die Adressen"? Was stellt ein solcher Debugger damit an?
Hier im Thread sollte etwas mehr zwischen Debugger und Tracer unterschieden werden ;) In den Cortex-M gibts ja nicht nur das Debuginterface, sondern Trace Makrozellen. Diese lassen sich durch SWO anzapfen (langsam) oder mit dem 4Bit Sync Trace Interface mit vielen MHz. Mit dem SWO lässt sich aber auch schon recht nett tracen, siehe Segger Systemview. Den J-Trace musste ich auf Arbeit schonmal auspacken um einen Fehler in einem WLAN Stack zu finden. Eine Logausgabe per UART war selbst auf 4MBaud zu langsam. Debuggen veränderte auch das Zeitverhalten zu sehr. Erst tracen per J-Trace und Ozone brachte das Übel zu tage.
Stefan ⛄ F. schrieb: > Dafür braucht der Debugger quasi keinen Speicher, denke ich. Was meinst > du denn mit "Mindestens für die Adressen"? Was stellt ein solcher > Debugger damit an? Hier geht es um Hardware Trace. Damit gehen dann so schöne Dinge wie Code Coverage Analysen oder Post-Mortem Debugging. Damit sowas geht, muß natürlich der Debugger den Programmverlauf in Echtzeit mitloggen (also mindestens die Adressen der ausgeführten Befehle).
Beitrag #6131088 wurde von einem Moderator gelöscht.
Thorsten S. schrieb: > den Programmverlauf in > Echtzeit mitloggen (also mindestens die Adressen der ausgeführten > Befehle). Danke, darunter kann ich mir etwas vorstellen.
Got a black magic Probe Got a black magic Probe. I got a black magic Probe Got me so blind I can't see That she's a black magic Probe She's tryin' to make a devil out of me. Don't turn your back on me baby Don't turn your back on me baby. Yes, don't turn your back on me baby Stop messin' 'round with your tricks Don't turn your back on me baby You just might pick up my magic sticks. Got your spell on me baby Got your spell on me baby. Yes you got your spell on me baby Turning my heart into stone I need you so bad - magic Probe I can't leave you alone.
Stefan ⛄ F. schrieb: >> Wofür brauchen/benutzen Debugger viel RAM? > > Bauform B. schrieb: >> Mindestens für die Adressen. 32 Bit mal 100MHz sind 400MB pro Sekunde, >> oder nicht? Früher konnte ich noch 16 andere Signale mit aufzeichnen. >> Aber früher war ja alles viel besser. > > Ich kann Dir leider nicht folgen, vermutlich weil ich keine Ahnung habe. > > Nach meinem Verständnis kann ich mit einem Debugger in die CPU und den > Speicher des laufenden Target hinein gucken. Und ich kann ein paar > Konfigurationen vornehmen, wie SWO aktivieren und Haltepunkte setzen. Das würde ich als Grundfunktionalität bezeichnen. Es gibt aber auch Debugger die mehr können. Z.b. das oben erwähnte Tracing. In unserem Fall hier, zeichnet der Debugger wirklich jeden einzelnen Takt der CPU auf und zwar inklusive Speicherzugriffe, Programcounter, Exceptions. Die Debuggersoftware hat dann eine Menge Intelligenz und kann im Prinzip den Systemzustand zu jedem zurückliegenden Zeitpunkt (fast) komplett bestimmen und anzeigen, indem sie den aktuellen Zustand nimmt und den Trace rückwärts rechnet. (Periphieregister mal ausgenommen) D.h. wenn ich z.B. einen Data Abort oder Undefined Instruction im Ram habe, dann kann ich selbst in einem Multitask-OS mit vielen Kontextwechseln relativ einfach den Verursacher bestimmen, da man sehr einfach zu verschiedenen Zeiten im Programmablauf springen kann ohne das System nochmal laufen zu lassen und ohne einen zeitlichen Einfluss durch das Debugging haben. Mit den 512MB kommt man bei einer Cortex M4 mit 100 Mhz auf etwa 2,5 Sekunden Laufzeit, hängt davon ab wieviel man davon im "WFE" verbringt.
Stefan ⛄ F. schrieb: > Nach meinem Verständnis kann ich mit einem Debugger in die CPU und den > Speicher des laufenden Target hinein gucken. Und ich kann ein paar > Konfigurationen vornehmen, wie SWO aktivieren und Haltepunkte setzen. Womit du Eindrucksvoll zeigst, dass du weder vom Debuggen noch vom Tracen Ahnung hast. Aber trotzdem ne stramme Meinung zu deren Notwendigkeit. Das passt ja gut!
Stefan ⛄ F. schrieb: > Ich kann Dir leider nicht folgen, vermutlich weil ich keine Ahnung habe. Cyblord -. schrieb: > Womit du Eindrucksvoll zeigst, dass ... vom Tracen Ahnung hast. Sag ich doch! > Aber trotzdem ne stramme Meinung zu deren Notwendigkeit. Zum Tracen habe ich mich nicht geäußert. Möglicherweise beziehst du dich darauf, dass ich in diesem Forum ab und zu schreibe, dass ich Debugger ich Logmeldungen häufiger benutze. Das bedeutet aber keinesfalls, dass ich Debugger für Unsinn halte. Meine Präferenz für Logmeldungen ist halt einfach meinen Anwendungsfällen und Gewohnheiten geschuldet. Für andere mag der Debugger hilfreicher sein. Auch das habe ich bereits hervor gehoben. Was also soll dieses Nachtreten? Fühlst du dich jetzt erleichtert, oder hast du noch mehr Unrat loszuwerden? Jetzt verrate du mal, wovon du keine Ahnung hast, dann kann ich zurück treten. Das wäre doch nur gerecht, oder?
Wenn ich kurz unterbrechen darf... Ich hab' endlich etwas gefunden was wohl nicht funktionieren wird. Die STM32L4 starten mit dem 4MHz-RC, BMP toggelt SWCLK "as fast as possible; adding frequency control would slow that down" (sinngemäß; natürlich finde ich die Quelle dafür nicht mehr). Irgendwo hab' ich auch 4.5MHz SW Bitrate gelesen. Das geht also nicht so einfach, unmöglich ist es aber auch nicht. Weiß man genaueres bzw. was ist denn aus der Frage geworden? https://community.st.com/s/question/0D50X00009XkaQdSAJ/swd-clock-restrictions Und noch was. Mal angenommen, ich will mein Programm nur ins RAM laden, nicht ins Flash. Dann sollte es doch ausreichen, nur den neuen IDCODE zu ergänzen?
Stefan ⛄ F. schrieb: > > Das bedeutet aber keinesfalls, dass ich Debugger für Unsinn halte. Meine > Präferenz für Logmeldungen ist halt einfach meinen Anwendungsfällen und > Gewohnheiten geschuldet. Für andere mag der Debugger hilfreicher sein. > Auch das habe ich bereits hervor gehoben. Doch du hast dich da ganz klar gegen Debugger positioniert und mit 20 Jahren Erfahrung geprotzt. Wenn man das mit Null Ahnung von der Materie tut, dann muss man Kritik schon aushalten. > Jetzt verrate du mal, wovon du keine Ahnung hast, dann kann ich zurück > treten. Das wäre doch nur gerecht, oder? Sobald ich dazu eine Meinung lautstark vertrete, gerne. Ist aber bis jetzt noch nicht passiert.
:
Bearbeitet durch User
Cyblord -. schrieb: > Doch du hast dich da ganz klar gegen Debugger positioniert Worauf konkret beziehst du dich?
Bauform B. schrieb: > Wenn ich kurz unterbrechen darf... Ich hab' endlich etwas gefunden was > wohl nicht funktionieren wird. Die STM32L4 starten mit dem 4MHz-RC, BMP > toggelt SWCLK "as fast as possible; adding frequency control would slow > that down" (sinngemäß; natürlich finde ich die Quelle dafür nicht mehr). > Irgendwo hab' ich auch 4.5MHz SW Bitrate gelesen. Das geht also nicht so > einfach, unmöglich ist es aber auch nicht. Weiß man genaueres bzw. was > ist denn aus der Frage geworden? > https://community.st.com/s/question/0D50X00009XkaQdSAJ/swd-clock-restrictions Warum fabulierst Du und testet nicht? Zumindestens beim Cortex-M habe ich noch nirgends Grenzen der SWD Frequenz bezueglich der Core Frequenz beobachtet. Natuerlich hat die JTAG/SWD Schnittstelle selbst Grenzen. ST hat aber nur fuer den H7 Spezifikationen veroeffentlicht, z.B. DS12923, Rev.1 Seite 227 "JTAG/SWD interface characteristics". Und gerade habe ich getestet: - Native BMP mit relativ aktueller Firmware - ~ 20 cm 0.635 mm Kabel - Adapter 10-pin, 1.27 mm auf 7-pin 2.54 mm einreihig - ~ 20 cm 4-pin 1.27 mm auf Targetboard mit STM32L412KB Probe und Attach auf programmiertes Board funktioniert. Also Mass Erase und Reset gemacht. Und fuer die Unglaeubigen auch noch einen Power Cycle. Jetzt laeuft das Teil nur mit dem internen Oszilator. Probing laueft immernoch: > blackmagic_hosted -s /dev/ttyACM0 -t Black Magic Probe (v1.6.1-404-gc3a3f77-dirty) Copyright (C) 2019 Black Sphere Technologies Ltd. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>; Remote is Black Magic Probe v1.6.1-374-gd9d323f-dirty Running in Test Mode RESET_SEQ succeeded AP 0: IDR=24770011 CFG=00000000 BASE=e00ff003 CSW=23000040 ROM: Table BASE=0xe00ff000 SYSMEM=0x1 0 0xe000e000: Generic IP component - Cortex-M4 SCS (System Control Space) (PIDR = 0x4000bb00c)-> cortexm_probe 1 0xe0001000: 0x00000000 <- does not match preamble (0xB105000D) 2 0xe0002000: Generic IP component - Cortex-M3 FBP (Flash Patch and Breakpoint) (PIDR = 0x4002bb003) 3 0xe0000000: 0xb1b1b1b1 <- does not match preamble (0xB105000D) 4 0xe0040000: 0x00000000 <- does not match preamble (0xB105000D) 5 0xe0041000: Debug component - Cortex-M4 ETM (Embedded Trace) (PIDR = 0x4000bb925) Programmieren geht: > blackmagic_hosted -s /dev/ttyACM0 e_16arrayj_be.bin ... Erase 37516 bytes at 0x08000000 Flashing 37516 bytes at 0x08000000 Success! Und Verify auch: > blackmagic_hosted -s /dev/ttyACM0 -V e_16arrayj_be.bin ... ROM: Table END Read/Verifed succeeded for 37516 bytes Statt der Kommandozeilenbefehle haette ich natuerlich auch in Arm GDB /dev/ttyACM0 oeffnen koennen. > Und noch was. Mal angenommen, ich will mein Programm nur ins RAM laden, > nicht ins Flash. Dann sollte es doch ausreichen, nur den neuen IDCODE zu > ergänzen? Wenn das ein weiteres Mitglied einer Familie ist, langt das (fast). GDB bracuht auch noch eine Memorymap, um zu wissen, wo GDB wie schreiben kann. Welches Device fehlt Dir denn?
:
Bearbeitet durch User
Uwe B. schrieb: > Warum fabulierst Du und testet nicht? Weil ich noch keine BMP habe. > Read/Verifed succeeded for 37516 bytes OK, überzeugt! > Welches Device fehlt Dir denn? Ob eins fehlt weiß ich doch auch noch nicht, siehe oben. Aktuell liegen hier der STM32L451 und der L412. Der nächste wird wohl ein L496. Vielen Dank!
Fuer die STM32L4 Familie enthaelt BMP:
ID_STM32L41 = 0x464u, /* RM0394, Rev.4 */
ID_STM32L43 = 0x435u, /* RM0394, Rev.4 */
ID_STM32L45 = 0x462u, /* RM0394, Rev.4 */
ID_STM32L47 = 0x415u, /* RM0351, Rev.5 */
ID_STM32L49 = 0x461u, /* RM0351, Rev.5 */
ID_STM32L4R = 0x470u, /* RM0432, Rev.5 */
ID_STM32G03 = 0x466u, /* RM0444/454, Rev.2 */
ID_STM32G07 = 0x460u, /* RM0444/454, Rev.2 */
ID_STM32G43 = 0x468u, /* RM0440, Rev.1 */
ID_STM32G47 = 0x469u, /* RM0440, Rev.1 */
BMP kannst Du PC-Hosted auch auf aktuellen STLinks oder FT2232H laufen
lassen.
Uwe B. schrieb: > Fuer die STM32L4 Familie enthaelt BMP: ALLE STM32L4 bis auf die allerneuesten L4P und L4Q (die bei digikey noch nicht einmal gelistet sind). Fantastisch, ich bin begeistert! > BMP kannst Du PC-Hosted auch auf aktuellen STLinks oder FT2232H laufen > lassen. Sicher äußerst praktisch für die BMP-Entwicklung selbst. Aber da ist ja garnichts mehr zu tun ;) Ich mag erstmal ein rund-um-sorglos-Paket mit der originalen Hardware. Und dann träume ich von einer Hardware mit Potentialtrennung...
Bauform B. schrieb: > Ich mag erstmal ein rund-um-sorglos-Paket mit > der originalen Hardware. Und dann träume ich von einer Hardware mit > Potentialtrennung... Dann verfolge http://www.sidprice.com/ Allerdings hat ein STM32F4 zu wenig USB Endpoints um ACM-GDB, ACM-UART und TraceSWO richtig zu implementieren. Da wird Sid noch gute Ideen brauchen. Du kannst auch ein Eagle Design mit dem FT2232 und Potentialtrennung bekommen. Die verwendeten Silab Bausteine kommen allerdings nur bis 2.5 Volt herunter.
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.