STM32 + VCP + Debugger = Problem

[Debugger (Gast)]

Hallo ans Forum,

ich habe hier einen STM32F303 liegen. Der sendet mir per VirtualComPort 
Daten an den PC. Das klappt auch schon so weit. Aktuell habe ich 
Probleme mit dem Empfang von Daten, weshalb ich mir meinen 
Eingangspuffer ansehen möchte.

Mein Problem:
Wenn man den STM32 neu programmiert, hängt sich der VCP auf.
Mein Debugger läuft dann zwar, aber ich kann HTERM nicht mit dem VCP 
verbinden. Ziehe ich kurz den Stecker und stecke ihn wieder ein, dann 
kann ich mich ganz normal mit der VCP verbinden, allerdings bin ich da 
schon aus der Debug Session geflogen....

Gibt es einen Workaround dafür?
Oder kann ich den Debugger auch irgendwie zur Laufzeit aufschalten, ohne 
den Prozessor neu zu starten?

Viele Grüße

[W.S. (Gast)]

Debugger schrieb:
> Ziehe ich kurz den Stecker und stecke ihn wieder ein, dann
> kann ich mich ganz normal mit der VCP verbinden, allerdings bin ich da
> schon aus der Debug Session geflogen....

Dir ist aber klar, daß ein VCP (Virtueller Com Port) ein Konstrukt ist, 
das als Übertragungsweg den USB beinhaltet. Und nun willst du deinen 
Controller mit einem neuen Programm versehen und erwartest dabei, daß 
sowohl die Treiber auf beiden Seiten des USB (Host und dein Chip) als 
auch der Debugger davon völlig unberührt weiter arbeiten?

Kopfschüttel...

W.S.

[Debugger (Gast)]

W.S. schrieb:
> Kopfschüttel...

Danke für die technische Erläuterung des Problems.
Ja, dass war schon meine Erwartung. Aber das es so nicht geht habe ich 
ja nun mittlerweile rausgefunden.

Gesucht ist nach wie vor die Lösung/Workaround für das Problem.

Beste Grüße

[Niklas G. (erlkoenig)]

Mache den Pullup-Widerstand auf der D+ Leitung schaltbar. Beim 
Initialisieren des USB schaltest du den Widerstand aus und wieder an. 
Dadurch erkennt und enumeriert der PC das Gerät neu. Wenn das beim 
Programmstart passiert, geschieht es also nach dem Start der 
Debug-Session, sodass du dann debuggen kannst. Du darfst nur nicht 
während des Enumerationsprozesses das Programm unterbrechen, danach geht 
es. Du musst natürlich das Hterm neu verbinden. Am besten trennst du das 
Hterm vor dem Neustart/Flashen des Controllers, denn sonst hast du einen 
nicht-existenten COM-Port herumlungern.

[Jim M. (turboj)]

Man muss den D+ Pullup nicht unbedingt schaltbar machen - es reicht D+ 
hart auf Masse zu legen.

Das kann man entweder als Port Pin (wenn USB Pins als GPIO verfügbar) 
oder über das USB Peripherial machen.

Windows reagiert allergisch wenn offene COM Ports abgesteckt werden.

[W.S. (Gast)]

Debugger schrieb:
> Gesucht ist nach wie vor die Lösung/Workaround für das Problem.

Da gibt es nix zu suchen. Das Problem ist deine Erwartun, daß es 
irgendwie ginge.
Geht aber nicht, was auch logisch ist.
Denn die zugrundeliegende USB-Verbindung funktioniert nur dann, wenn 
auch der Treiber in deinem Chip seinen Dienst tut. Das kann er aber 
nicht, wenn du die bisherige Firmware löschst und eine neue 
draufbrennst.

Obendrein steht der Debugger dann in der Prärie, denn das, was er als 
den momentanen Stand angesehen hat, hat mit der neuen Firmware nix zu 
tun, da liegt alles auseinander: der RAM, der Stack und die 
Maschinenbefehle an der aktuellen Stelle.

W.S.

[dbg (Gast)]

für den Fall ist es einfacher die Kommunikation über einen UART und 
externem USB Adapter laufen zu lassen, das ist dann einfacher zu 
debuggen. Wenn es läuft wieder zurück auf den VCP.

[Debugger (Gast)]

W.S. schrieb:
> Da gibt es nix zu suchen. Das Problem ist deine Erwartun, daß es
> irgendwie ginge.
> Geht aber nicht, was auch logisch ist.

Hört dir in der realen Welt auch keiner mehr zu? Du hast keine Lösung, 
aber viel zu erzählen wie es nicht geht. Wenn du in der realen Welt 
genauso unterwegs bist, dann kann ich dir auch sagen warum dich keiner 
mehr ernst nimmt....ich hab mittlerweile eine Lösung gefunden, aber 
behaupte du ruhig weiter das es nicht geht :). Nur weil deine Know How 
begrenzt ist, muss das ja nicht für uns alle gelten. Das sind nur deine 
Grenzen, nicht unsere.


@Alle anderen:
Danke für die Ansätze mit dem schaltbaren Widerstand, die Hardware ist 
leider schon fertig. Ich werde es aber beim nächsten Design mal mit 
vorsehen :).

Die aktuelle Lösung ist einfach, man schaltet einfach in der CubeIDE den 
Download und den Reset beim Verbinden des Degubbers aus, dann kann man 
sich live aufschalten ohne was zu ändern und die Verbidnung bleibt 
bestehen. Praktischerweise kann man mehrere Debug-Configs anlegen, so 
dass man schnell wechseln kann.

Viele Grüße

[W.S. (Gast)]

Debugger schrieb:
> Die aktuelle Lösung ist einfach, man schaltet einfach in der CubeIDE den
> Download und den Reset beim Verbinden des Degubbers aus, dann kann man
> sich live aufschalten ohne was zu ändern und die Verbidnung bleibt
> bestehen.

Das klingt aber etwas anders als eingangs:

Debugger schrieb:
> Mein Problem:
> Wenn man den STM32 neu programmiert, hängt sich der VCP auf.

Tja, der USB geht eben etwas anders als eine klassische Serielle. Aber 
vielleicht lernst du den Unterschied irgendwann noch.

W.S.