Frage an W.S. wegen USB CDC Implementierung STM32F103

[Stefan F. (Gast)]

Hallo W.S.
Ich habe eine Frage zu deiner USB CDC Implementierung, die du hier schon 
ein paar mal veröffentlicht hast.

Und zwar habe ich den µC mit einem Netzteil versorgt. Der Pull-Up 
Widerstand an D+ ist fest mit 3,3V verbunden (Blue-Pill Board).

Das Programm sende jede Sekunde "Hello World" an den PC. Dann trenne ich 
das USB kabel im laufenden Betrieb. Nach einer gewissen Zeit hängt das 
Programm bei UsbCharOut() weil der Sendepuffer voll ist und voll bleibt.

Wenn ich dann das USB Kabel wieder mit dem PC verbinde kommt aber keine 
Neue Kommunikation mehr zustande. Der virtuelle COM Port wird nicht 
sichtbar, entsprechend kann ich ihn mit dem Terminalprogramm auch nicht 
wieder öffnen.

Hast du einen heissen Tip, wie ich es hinbekommen kann, dass ich das USB 
kabel später erneut verbinden kann ohne den µC resetten zu müssen?

[Patrick C. (pcrom)]

Fuer deinen uP weisz ich nicht, aber bei mir (Cypress PSOC5LP) hatte ich 
genau dieses problem. Der DTR MUSZ von PC aus gesetzt werden musz bei 
die oefnung der Virtual Serial Port (CDC).
Also im PC programm (bei mir C#)

[Patrick C. (pcrom)]

Sorry fuer den link zu ein anderes Forum in English aber ich denke 
dieser link beschreibt genau das gleiche problem :
http://www.avrfreaks.net/forum/how-detect-virtual-com-port-open

[Stefan F. (Gast)]

> Der DTR MUSZ von PC aus gesetzt werden

Mein Problem ist, dass der Reconnect gar nicht funktioniert. Also gibt 
es auch keinen DTR. Die Sache mit dem DTR kenne ich bereits von der CDC 
Implementierung in Arduino.

[Stefan F. (Gast)]

> dieser link beschreibt genau das gleiche problem

Nein, da geht es auch um die DTR Leitung. Mein Problem ist, das der USB 
Reconnect nicht funktioniert.

[Stefan F. (Gast)]

Offensichtlich besteht hier ein Missverständnis.

Nach dem ersten Anstecken des USB Kabels funktioniert die Kommunikation 
zum PC.

Aber wenn ich das Kabel abstecke und dann nach längerer Zeit (5min) erst 
wieder anstecke, dann kommt keine neue Verbindung mehr zustande. Der 
virtuelle COM Port wird nicht angelegt.

Wenn ich das Kabel jedoch nur für kurze Zeit abstecke oder keine "Hello 
World" texte sende während es unterbrochen ist, funktioniert der 
Reconnect ohne Probleme.

[Stefan F. (Gast)]

Ich habe das Experiment nochmal wiederholt und muss meine 
Fehlerbeschreibung ergänzen.

Wenn ich den virtuellen COM Port im Terminalprogramm schließe, bevor ich 
das USB kabel abziehe, wird er beim Reconnect wieder neu bereit gestellt 
und funktioniert dann auch.

Wenn ich es so lange abgesteckt lasse, dass der Sendepuffer voll läuft, 
funktioniert der Reconnect aus Windows Sicht auch (das hatte ich oben 
falsch geschrieben). Aber das Programm auf dem µC bleibt weiterhin 
hängen. Die LED blinkt nicht und das Terminalprogramm empfängt keine 
Daten.

[Stefan F. (Gast)]

Ich habe inzwischen mal den Debugger eingesetzt, um zu prüfen, dass der 
µC wirklich in UsbCharOut() hängt. jetzt kommt der Witz: Mit der 
Optimierung -O0 tritt der Fehler nicht mehr auf!

Dafür meldet Windows jetzt bei -O1 und -O2 grundsätzlich bei jedem 
Anstecken, dass das Gerät nicht ordnungsgemäß funktioniert.

Mein eigentliches Problem mit dem Reconnect ist so gar nicht mehr 
nachvollziehbar. Dafür habe ich neues größeres Problem bekommen. Grmpf!

Einen Hardwaredefekt habe ich ausgeschlossen, mit Arduino und Cube HAL 
läuft es zuverlässig.

[Stefan F. (Gast)]

Ich habe die Lösung für beide Probleme gefunden. Bin total Happy!

1) Wegen dem Reconnect: Die Variablen vom Puffer müssen volatile sein.

/* die Transfer-Puffer für zeichenweises In und Out über den USB */
#define txLen  256
volatile char UsbTxBuf[txLen];
volatile int  txr, txw;

#define rxLen  256
volatile char UsbRxBuf[rxLen];
volatile int  rxr, rxw;

2) Die Verzögerungsschleife mit dem NOP war zu klein:

void Nop (dword count)
{
    while (count)
    {
        asm volatile ("nop");
        asm volatile ("nop");
        asm volatile ("nop");
        asm volatile ("nop");
        asm volatile ("nop");
        asm volatile ("nop");
        asm volatile ("nop");
        asm volatile ("nop");
        asm volatile ("nop");
        asm volatile ("nop");
        asm volatile ("nop");
        asm volatile ("nop");
        --count;
    }
}

Bei 48Mhz Systemtakt habe ich herausgefunden, dass ich mindestens 9 nops 
brauche. Sicherhaltshalber habe ich paar mehr genommen. Klappt auch mit 
72Mhz.

[evtl (Gast)]

Dieses Konstrukt soll laut des anderen Threads helfen:

void __attribute__((optimize("O0"))) Nop (dword count)
{ while (count) --count; }

[Stefan F. (Gast)]

Meine Variante mit den 12 Nops:

 380                  .section  .text.Nop,"ax",%progbits
 381                  .align  1
 382                  .p2align 2,,3
 383                  .global  Nop
 384                  .syntax unified
 385                  .thumb
 386                  .thumb_func
 387                  .fpu softvfp
 389                Nop:
 390                  @ args = 0, pretend = 0, frame = 0
 391                  @ frame_needed = 0, uses_anonymous_args = 0
 392                  @ link register save eliminated.
 393 0000 68B1         cbz  r0, .L32
 394                .L34:
 395                  .syntax unified
 396                @ 610 "../src/USB.c" 1
 397 0002 00BF         nop
 398                @ 0 "" 2
 399                @ 611 "../src/USB.c" 1
 400 0004 00BF         nop
 401                @ 0 "" 2
 402                @ 612 "../src/USB.c" 1
 403 0006 00BF         nop
 404                @ 0 "" 2
 405                @ 613 "../src/USB.c" 1
 406 0008 00BF         nop
 407                @ 0 "" 2
 408                @ 614 "../src/USB.c" 1
 409 000a 00BF         nop
 410                @ 0 "" 2
 411                @ 615 "../src/USB.c" 1
 412 000c 00BF         nop
 413                @ 0 "" 2
 414                @ 616 "../src/USB.c" 1
 415 000e 00BF         nop
 416                @ 0 "" 2
 417                @ 617 "../src/USB.c" 1
 418 0010 00BF         nop
 419                @ 0 "" 2
 420                @ 618 "../src/USB.c" 1
 421 0012 00BF         nop
 422                @ 0 "" 2
 423                @ 619 "../src/USB.c" 1
 424 0014 00BF         nop
 425                @ 0 "" 2
 426                @ 620 "../src/USB.c" 1
 427 0016 00BF         nop
 428                @ 0 "" 2
 429                @ 621 "../src/USB.c" 1
 430 0018 00BF         nop
 431                @ 0 "" 2
 432                  .thumb
 433                  .syntax unified
 434 001a 0138         subs  r0, r0, #1
 435 001c F1D1         bne  .L34
 436                .L32:
 437 001e 7047         bx  lr

Und die Variante mit der Leeren Schleife ohne Optimierung:

 396                  .section  .text.Nop,"ax",%progbits
 397                  .align  1
 398                  .p2align 2
 399                  .global  Nop
 400                  .syntax unified
 401                  .thumb
 402                  .thumb_func
 403                  .fpu softvfp
 405                Nop:
 406                  @ args = 0, pretend = 0, frame = 8
 407                  @ frame_needed = 1, uses_anonymous_args = 0
 408                  @ link register save eliminated.
 409 0000 80B4         push  {r7}
 410 0002 83B0         sub  sp, sp, #12
 411 0004 00AF         add  r7, sp, #0
 412 0006 7860         str  r0, [r7, #4]
 413 0008 02E0         b  .L33
 414                .L34:
 415 000a 7B68         ldr  r3, [r7, #4]
 416 000c 013B         subs  r3, r3, #1
 417 000e 7B60         str  r3, [r7, #4]
 418                .L33:
 419 0010 7B68         ldr  r3, [r7, #4]
 420 0012 002B         cmp  r3, #0
 421 0014 F9D1         bne  .L34
 422 0016 00BF         nop
 423 0018 0C37         adds  r7, r7, #12
 424 001a BD46         mov  sp, r7
 425                  @ sp needed
 426 001c 80BC         pop  {r7}
 427 001e 7047         bx  lr

Sieht irgendwie unnötig kompliziert aus, erfüllt aber sicher auch seinen 
Zweck.

[temp (Gast)]

Tja, das gleiche Problem mit der wackligen delay-Implementierung hatte 
ich hier auch schon paar mal berichtet. Alle Versuche W.S. zu einem 
Statement zu überreden endeten ohne Antwort. Es wird so sein wie ich 
schon vermutet habe, hier freut sich einer wenn andere Leiden.

[temp (Gast)]

Kannst es ja auch mal so probieren:

void Nop (dword count)
{ 
  count<<4; // anpassen
  while (count) 
    {  
    --count; 
    __NOP();
    }
}

[temp (Gast)]

Korrektur war zu schnell:

count<<=4; // anpassen

[Stefan F. (Gast)]

> Kannst es ja auch mal so probieren

Das wären 16 Nops pro Durchlauf + 16 mal so oft dekrementieren. Das ist 
viel mehr als meine bereits großzügig gewählten 12 Nops.

[Stefan F. (Gast)]

Ich hatte irgendwo mal gelesen, dass nur ein volatiles NOP in die 
Schleife rein muss weil sie sonst weg optimiert wird. Nun stellt sich 
heraus, dass das viel zu wenig war.

Egal, es läuft jetzt stabil. Ich denke, alle hier vorgeschlagenen Lösung 
funktionieren.

[Mampf F. (mampf)]

Stefan U. schrieb:
> Egal, es läuft jetzt stabil. Ich denke, alle hier vorgeschlagenen Lösung
> funktionieren.

Eine schlanke Alternative zu STs USB-Code hört sich interessant an :)

[temp (Gast)]

Stefan U. schrieb:
> Das wären 16 Nops pro Durchlauf + 16 mal so oft dekrementieren. Das ist
> viel mehr als meine bereits großzügig gewählten 12 Nops.

Darum stand ja auch "anpassen" im Kommentar. Das __NOP() aus core_cm3.h 
hat den Vorteil, dass es je nach Compiler die richtige Implementierung 
macht. Beim gcc ist das dann:

static __INLINE void __NOP()                      { __ASM volatile ("nop"); }

Damit ist der Code dann auch unter Keil übersetzbar, der mit der gcc 
Syntax "asm volatile" nichts anfangen kann.

[Stefan F. (Gast)]

Allerdings, diese Lösung ist ziemlich schlank.

Deswegen interessiere ich mich dafür. Liegt vielleicht auch daran, dass 
mein Einstieg in µC Programmierung mit 1kB Flash und 64 Bytes RAM 
begann.

[Mampf F. (mampf)]

Stefan U. schrieb:
> mit 1kB Flash und 64 Bytes RAM
> begann.

Mmhmm, da hatte mein damaliger 8032 schon mehr Speicher^^

[Nico W. (nico_w)]

Das delay sieht irgendwie eher wie nen Hack aus. Das sind da später im 
Code 25us Pause bei 48MHz(12*100/48).


Gibt es da eventuell irgendwo nen Ready-bit was man Abfragen kann?

[Stefan F. (Gast)]

Ich glaube nicht. Delays findet man auch im Cube HAL Code und in in dem 
STM32 USB Tutorial. Scheint nicht anders zu gehen.