Serielles Flash Programm - Demonstrator GUI funktioniert nicht

[Christoph K. (chriskuku)]

Demonstrator GUI von ST verhält sich unzuverlässig. Im Moment bekomme 
ich nichts heraus aus dem Demonstrator GUI (unter einer Parallels 
Windows 10 VM). Man könnte sagen "laß die Finger davon, sowie veraltet 
usw.", aber es ärgert mich, wenn ein Aufbau nicht so funktioniert, wie 
man es erwarten sollte.

Kurz und gut: ich habe einen Aufbau wie in der beigefügten Skizze.
Ich habe mit meiner DLA-Probe (Pulseview) die UART-Leitungen angezapft.
Wenn ich sie statt an das DI-Board anzuschließen, gegeneinander 
kurzschließe und auf der Windows Seite OC-Console (COM1) mit 115200 Bd 
(8N1) aufrufe und etwas in die Tastatur tippe, so kommt es an.

Starte ich das Demonstrator GUI mit 115200, COM1, 8E1 (default), so 
kommt kein Zeichen auf die Leitung. Unabhängig davon, ob auf dem Target 
der BOOT-Mode richtig eingestellt ist, sollte das GUI doch erst mal ein 
Zeichen schicken (0x7f), oder?

Was für einen seriellen Programmer gibt es noch, den man probieren 
könnte?

[W.S. (Gast)]

Christoph K. schrieb:
> Demonstrator GUI von ST verhält sich unzuverlässig.

Das ist seit Jahren bekannt. Dieses Programm von ST kaut eine Weile auf 
der Hardware herum und dann heißt es "geht nicht". Keine weitere 
Erläuterung dazu.

Ich hatte vor Jahren schon mal ein Programm zum Programmieren der STM32 
per Bootlader geschrieben und hier gepostet. Das hat wenigstens noch ein 
paar Testmöglichkeiten dabei, also ob Reset und Boot richtig am µC 
ankommen.

W.S.

[Christoph K. (chriskuku)]

W.S. schrieb:
> Christoph K. schrieb:
>> Demonstrator GUI von ST verhält sich unzuverlässig.
>
> Das ist seit Jahren bekannt. Dieses Programm von ST kaut eine Weile auf
> der Hardware herum und dann heißt es "geht nicht". Keine weitere
> Erläuterung dazu.
>
> Ich hatte vor Jahren schon mal ein Programm zum Programmieren der STM32
> per Bootlader geschrieben und hier gepostet. Das hat wenigstens noch ein
> paar Testmöglichkeiten dabei, also ob Reset und Boot richtig am µC
> ankommen.
>
> W.S.

Stimmt, war es STM32Prog.exe? Habe es gerade mal hervorgeholt.

[J. S. (jojos)]

Stm32CubeProgrammer funktioniert bestens, der bringt auch eine 
Kommandozeilenversion mit.
Ich würde aber das Bluepill zur BMP umflashen und dann über SWD 
programmieren.
Aber an der Baustelle warst du doch auch schon.
Und wenn es bei STM32 bleibt, dann ist der STLink V3 mittlerweile die 
beste Wahl. 15€ bei Reichelt.

[Christoph K. (chriskuku)]

J. S. schrieb:
...
> Und wenn es bei STM32 bleibt, dann ist der STLink V3 mittlerweile die
> beste Wahl. 15€ bei Reichelt.

Leider nicht mehr verfügbar bei Reichelt. Andere Quellen mehr als das 
doppelte.

[J. S. (jojos)]

ich meinte diesen hier:
https://secure.reichelt.de/in-circuit-debugger-programmierer-fuer-stm32-stlink-v3mini-p274817.html

Das SET ist bequemer weil es mehr Anschlussmöglichkeiten hat, da ist 
aber der gleiche Mini drin. Für den Mini braucht man dann Adapter für 
den 50 mil Stecker, oder solche Breakout Boards:
https://github.com/tw1chao/STLinkV3_Adapter
https://github.com/TMSL/STLINK-V3MINI-Cable-Adapter-Board

[W.S. (Gast)]

J. S. schrieb:
> Und wenn es bei STM32 bleibt, dann ist der STLink V3 mittlerweile die
> beste Wahl.

Ich frage mich seit langem, warum die Leute hier mit Fleiß immerzu einen 
großen Bogen um den eingebauten Bootlader machen wollen. Der kommt mit 
dem Chip daher, kostet nix und sollte eigentlich die genau für den Chip 
passenden Programmiermethoden haben. Und die Ansteuerung ist leicht, man 
braucht keine zusätzlichen JTAG/SWD Adapter usw.

W.S.

[Christoph K. (chriskuku)]

W.S. schrieb:
> J. S. schrieb:
>> Und wenn es bei STM32 bleibt, dann ist der STLink V3 mittlerweile die
>> beste Wahl.
>
> Ich frage mich seit langem, warum die Leute hier mit Fleiß immerzu einen
> großen Bogen um den eingebauten Bootlader machen wollen. Der kommt mit
> dem Chip daher, kostet nix und sollte eigentlich die genau für den Chip
> passenden Programmiermethoden haben. Und die Ansteuerung ist leicht, man
> braucht keine zusätzlichen JTAG/SWD Adapter usw.
>
> W.S.

Ich betreibe ja das Target normalerweise über die SWD Schnittstelle, 
STM32CubeIDE samt umfangreicher Debugtracemeldungen über die SWV/ITM 
Schnittstelle. Wollte jetzt nur mal speziell den seriellen über UART 
testen (Demonstrator GUI).

Was meinst Du jetzt mit "eingebautem Bootloader"? Auf welchen Satz 
bezieht sich Deine Kritik? Auf: "dann ist der STLink V3 mittlerweile die 
beste Wahl." ?

Der STM32 hat ja viele Bootloader, seriell über UART, I2C, SPI, Can, was 
nicht alles noch. Aber damit kann man ja nur up/download. Richtig 
Debuggen doch eher nicht?

[J. S. (jojos)]

Christoph K. schrieb:
> Der STM32 hat ja viele Bootloader, seriell über UART, I2C, SPI, Can, was
> nicht alles noch. Aber damit kann man ja nur up/download. Richtig
> Debuggen doch eher nicht?

richtig. Wenn man ein Gerät hat auf dem eine der genannten 
Schnittstellen herausgeführt ist, dann kann es Sinn machen die auch für 
ein Firmware Update zu verwenden.
Der STLinkV3 + STM32CubeProgrammer unterstützen alle diese 
Schnittstellen, hat Fullspeed USB und ist damit sehr schnell, was sich 
durchaus positiv beim Debuggen bemerkbar macht. Der F407 hat 512/1024 kB 
Flash, auch große Programme sind damit blitzschnell geflasht. Vor der 
großen Krise hat der V3 Mini <8€ netto bei den Distris gekostet.
Und um den noch universeller zu machen hat STM eine Bridge Library 
kostenlos im Angebot, damit lassen sich die Schnittstellen von PC 
Software aus nutzen. Und auf Github gibt es weitere Unterstützung für 
verschiedene Programmiersprachen.
Für mich sind das genug Gründe das Teil zu 'meinem Lieblingswerkzeug' 
werden zu lassen.
Den Test mit DIY Board und seriellem Bootloader kann ich morgen auch 
machen, habe diverse F407 Boards. Aber nur mit der STM32CubeProgrammer 
Software, das W.S. Zeug kommt mir nicht auf den Rechner.

[Klaus S. (kseege)]

W.S. schrieb:
> Ich frage mich seit langem, warum die Leute hier mit Fleiß immerzu einen
> großen Bogen um den eingebauten Bootlader machen wollen. Der kommt mit
> dem Chip daher, kostet nix und sollte eigentlich die genau für den Chip
> passenden Programmiermethoden haben. Und die Ansteuerung ist leicht, man
> braucht keine zusätzlichen JTAG/SWD Adapter usw.

Dafür gibt es (ernsthafte) technische und (vergnügliche) psychologische 
Gründe.
1.Technische
In der Großserie wird Hardware und Software parallel entwickelt. Der 
Programmierer bekommt also sehr spät erst die richtige Hardware zum 
Test.
Da ist dann das Debugging mit Breakpoints oder Einzelschritt die 
schnellste  (dem begrenzten Hirn des Menschen) mögliche 
Fehlersuchmethode und da braucht man den JTag-Link ohnehin.

Wer schon zur Programmierzeit die echte Hardware zur Verfügung hat, kann 
inkrementell programmieren. Die interpretierenden Sprachen (egal ob die 
Neueren wie Python und Lua oder die Alten wie Forth und Basic) sind 
genau dafür gut und die Programmierschnittstelle ist gleichzeitig 
Debugschnittstelle. Dafür reicht dann der eingebaute Bootloader. Aber 
nur, wenn man fit ist, kann man damit C-Progamme debuggen, aber wer ist 
schon fit?

2.Psychologische
Minimalismus macht einfach wenig her. Wenn man den Aufwand ordentlich 
aufbläst, sieht alles gleich viel eindrucksvoller und professioneller 
aus!

Gruß Klaus (der soundsovielte)