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
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.
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
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.
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.
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.
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.
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
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.
