Hi Leute, kann jemand einen Programmer empfehlen, der schnell ist, wen STLink-V2 angeblich 4Mhz kann, dauert es bei einer 32K FW ~ eine halbe Minute. Da ist mein eigener Bootlooader mit 10 Sekunden schneller, obwohl ich über I2C mit 100Kbps update. Wichtig ist mir aber auch, dass sich die FW via CMD flashen läßt und HardRST Pin funktioniert, was man in der Produktion verwenden kann... Wäre für eine Empfehlung dankbar.
A. F. schrieb: > Da ist mein eigener Bootlooader mit 10 Sekunden schneller Wie lange dauert es, den Bootloader über SWD drauf zu pusten? Danach kannst du mit einem eigenen Tool per i2c die Applikation flashen. mfg mf
Das wäre ein Workaround, aber keine Lösung. BL wird nur als eine Art Not-Lösung vorgehalten, die eigentliche Initialprogrammierung muss via SWD geschehen.
Hört sich für mich so an, als würde dein ST-Link nicht auf der richtigen Taktrate laufen. Habe grade mal einen F103 mit dem China-ST-LinkV2 ausgelesen: Das dauert 0.4 Sekunden den kompletten Speicher von 64kB auszulesen. Schreiben ist ähnlich schnell: Fürs Flashen brauche ich normalerweise wenige Sekunden inklusive der Zeit, die er zum Starten und Verbinden braucht. Du machst definitiv was falsch: Check mal deine Config/Software. Vl. mal die ST-Link-Firmware updaten wenn sie nicht aktuell ist. Wie sieht überhaupt dein Setup aus? MCU? Betriebssystem? Toolchain? SWD-Kabellänge?
:
Bearbeitet durch User
A. F. schrieb: > Hi Leute, > kann jemand einen Programmer empfehlen, der schnell ist, wen STLink-V2 > angeblich 4Mhz kann, dauert es bei einer 32K FW ~ eine halbe Minute. 30 Sekunden für 32kByte klingt extrem langsam. Das hat dann wahrscheinlich auch nichts mit der SWD Clock zu tun. Mit meinem BJPA komme ich im Moment beim flashen eines nRF52 auf ~20kByte / sec. Die SWD Clock ist dabei 1MHz. Meine Empfehlung: BJPA: https://www.torrox.de/#wirelessdebugger ;-)
:
Bearbeitet durch User
A. F. schrieb: > angeblich 4Mhz kann, dauert es bei einer 32K FW ~ eine halbe Minute. Da STLink-V2-1 auf einem Nucleo-G0B1RE mit 32 kByte Datei in nicht einmal 2s: date;openocd -f ./nucleo-g071rb.cfg -c init -c "program test.srec verify reset" -c exit; date 2021-03-29 16:14:49+02:00 Open On-Chip Debugger 0.11.0+dev-01612-gf87337cc7-dirty (2021-03-13-18:34) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : clock speed 2000 kHz Info : STLINK V2J37M27 (API v2) VID:PID 0483:374B Info : Target voltage: 3.241967 Info : stm32g0x.cpu: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for stm32g0x.cpu on 3333 Info : Listening on port 3333 for gdb connections Info : Unable to match requested speed 2000 kHz, using 1800 kHz Info : Unable to match requested speed 2000 kHz, using 1800 kHz target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0xfffffffe msp: 0xfffffffc ** Programming Started ** Info : device idcode = 0x10006467 (STM32G0B/G0Cxx - Rev A : 0x1000) Info : flash size = 512kbytes Info : flash mode : single-bank ** Programming Finished ** ** Verify Started ** ** Verified OK ** ** Resetting Target ** Info : Unable to match requested speed 2000 kHz, using 1800 kHz Info : Unable to match requested speed 2000 kHz, using 1800 kHz 2021-03-29 16:14:50+02:00 Nix von einer halben Minute ...
> Das hat dann wahrscheinlich auch nichts mit der SWD Clock zu tun.
Würde ich nicht ausschließen, die lässt sich bis auf 5kHz drücken, dann
dauern 32kByte ca. ne Minute ;)
Mit 10kHz dann entsprechend die halbe Minute die OP hier bemängelt.
Florian S. schrieb: > Würde ich nicht ausschließen, die lässt sich bis auf 5kHz drücken, dann > dauern 32kByte ca. ne Minute ;) Stimmt. Oder aber an Übertragungsfehlern, die ein immer wieder aufsetzen der Kommunikation / Flashen zur Folge hat.
Schon mal blackmagic fuer den PC versucht ? "make PROBE_HOST=hosted". Und dann "blackmagic <file.bin>"? Mehr Optionen "blackmagic -h"
Uwe B. schrieb: > Und dann "blackmagic <file.bin>"? Hätte man das nicht mit "BM <file> ..." abkürzen können? So geht weitere wertvolle Lebenszeit beim Eintippen des Programmnamen verloren.
A. F. schrieb: > Hi Leute, > kann jemand einen Programmer empfehlen, der schnell ist, wen STLink-V2 > angeblich 4Mhz kann, dauert es bei einer 32K FW ~ eine halbe Minute. Da > ist mein eigener Bootlooader mit 10 Sekunden schneller, obwohl ich über > I2C mit 100Kbps update. Wichtig ist mir aber auch, dass sich die FW via > CMD flashen läßt und HardRST Pin funktioniert, was man in der Produktion > verwenden kann... > > Wäre für eine Empfehlung dankbar. Der übliche China V2-Clone mit st-link braucht für 64kB keine zwei Sekunden auf einem STM32F411.
1 | st-flash --freq=4m write <filename> 0x8000000 |
Angehängte Dateien:
-
swd_settings.png
6,6 KB
> Du machst definitiv was falsch: Check mal deine Config/Software. Vl. mal > die ST-Link-Firmware updaten wenn sie nicht aktuell ist. Was soll man da falsch machen können? Kabellänge = Original ST Kabel, die STLink FW ist aktuell. Torsten R. schrieb: > 30 Sekunden für 32kByte klingt extrem langsam. Das hat dann > wahrscheinlich auch nichts mit der SWD Clock zu tun. Natürlich nicht, das sollte bei 4Mhz super flott gehen, was aber nicht der Fall ist. Habe die Sekunden mitgezählt. Die FW ist nicht mal 32KB groß, dauert aber 20 sek zu flaschen.... ST Link V2 ist original. Ingo Less schrieb: > ST-Link V3 kann 24MHz Konte davon CMD nicht nutzen...
Was meinst du mit CMD? Meinst du ein Kommandozeile-Programm? Ich nutze unter Linux oft dieses: https://github.com/stlink-org/stlink Da müsste auch unter Windows laufen, laut Beschreibung.
A. F. schrieb: > Natürlich nicht, das sollte bei 4Mhz super flott gehen, was aber nicht > der Fall ist. > Habe die Sekunden mitgezählt. Die FW ist nicht mal 32KB groß, dauert > aber 20 sek zu flaschen.... ^ Freudscher Verschreiber ;-) Aber im Ernst: 20s sind schon mal nicht eine halbe Minute. Das "Connect under Reset" kann vielleicht 1 oder 2 Sekunden Verzögerung bewirken. Außerdem wäre noch die Frage, ob vielleicht alle Sektoren vorher einzeln gelöscht werden, oder nur die benutzten oder gar keine. Das kann weitere 1 bis 2 Sekunden ausmachen. Ansonsten ist's wohl das GUI, das sich da vieeeeeel Zeit lässt. Ging es nicht gerade um Kommandozeilen-Tool??? > ST Link V2 ist original. > > Ingo Less schrieb: >> ST-Link V3 kann 24MHz > Konte davon CMD nicht nutzen...
mit welchem Programm tust du flashen? Mal mit STM32CubeProgrammer probiert? Eventuell siehst du dort, wo es hängt.
> Ansonsten ist's wohl das GUI, das sich da > vieeeeeel Zeit lässt. Ging es nicht gerade um Kommandozeilen-Tool??? Es geht hauptsächlich um CMD, der Test mit der GUI ergibt die gleichen Flashzeiten....
Was zum Henker ist CMD? Drücke dich mal bitte klar aus!
dummschwaetzer schrieb: > Mal mit STM32CubeProgrammer probiert? Danke, installiert, mit GUI ausprobiert und tatsache, hat nur 2 Sekunden gedauert! Wie connecte ich mihc richtig via CMD, wenn ich in meiner .bat -c port=SWD benutze, kommt eine Fehlermeldung, dass die erbindung nicht besteht.... STM32_Programmer_CLI.exe -HardRst>NUL STM32_Programmer_CLI.exe c- port=SWD -d %destination_file%
Stefan ⛄ F. schrieb: > Was zum Henker ist CMD? Drücke dich mal bitte klar aus! Sorry, bin windowsbelastet. CMD = Commando-Eingabe bei Windows. Die nicht GUI basierte Version von STM32 programmer. CLI von STLink...
A. F. schrieb: > CMD = Commando-Eingabe bei Windows Dann schreibe demnächst bitte "Eingabeaufforderung" oder cmd.exe. Das ist dann klarer. probiere mal das Kommandozeilentool aus, dass ich dir weiter oben empfohlen habe.
>Es geht hauptsächlich um CMD, der Test mit der GUI ergibt die gleichen >Flashzeiten.... die GUI hat doch für jede Aktion (Connect, Erase, ....) Zeitstempel Welcher Teilschritt braucht so lange?
Ich muss die comman line version benutzen. GUI nur zum ausprobieren! STM32_Programmer_CLI.exe -c port=SWD mode=UR reset=hwRst -d %destination_file% ST-LINK SN : 49FF6B066767564949410767 ST-LINK FW : V2J37S7 Board : -- Voltage : 3.17V SWD freq : 4000 KHz Connect mode: Under Reset Reset mode : Hardware reset Error: Unable to list supported devices Error: Cannot identify the device Press any key to continue . . . Weiß jemand welche Files die EXE braucht, um den uC zu identifizieren?
eventuell alles aus den Unterordnern in BIN. kannst du in der GUI eventuell schauen, mit welchen Optionen die GUI dann die STM32_Programmer_CLI aufruft?
Unter Linux kann man mit dem Befehl strace herausfinden, auf welche Dateien ein Programm zugreift. Vielleicht gibt es etwas ähnliches für Windows. Dies hier scheint in die Richtung zu gehen: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/wt--trace-and-watch-data-
Da ist doch ein Setup für das Programm? Nur ein exe rausfischen funktioniert nie. War das überhaupt so gemeint oder hat die CLI Version generell ein Verbindungsproblem?
Johannes S. schrieb: > Da ist doch ein Setup für das Programm? Nur ein exe rausfischen > funktioniert nie. > War das überhaupt so gemeint oder hat die CLI Version generell ein > Verbindungsproblem? Ich hab es! Wenn man die STM32_Programmer_CLI.exe als Kopie irgendwo anders Ordner benutzen möchte, muss der Ordner Data_Base (eine ebene höher) mitkopiert werden. Und in dem gleichen Verzeichnis wie die EXE Ordner Flashloader Ordner liegen.
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.