STM32 USB Conf

[Mark W. (mark_wer)]

Hallo,

ich nutze eine abgewandelte Lib von ST um den STM32 als CDC Device zu 
nutzen. Ich messe über VCOM Perioden (Interrupt) am PC. Funktioniert 
eigentlich alles. Aber wenn ich einen Frequenzsweep mache, wobei die 
erste Messung immer berücksichtigter Müll ist. Teilweise kommt wird bei 
einem Sweep allerdings noch 64 vorherige Werte mitgemessen und dann ist 
die 64*x Messung Müll, was sich nicht mehr so gut rausfiltern lässt. Ich 
habe herausgefunden, dass es evtl. durch die usb config zustande kommt. 
Wenn ich den Wert von CDC_DATA_MAX_PACKET_SIZE nämlich auf 32 ändere, 
kommt die fehlerhafte Messung an 32ter Stelle. Jetzt würde mich 
interessieren, was genau die defines in der usb config bedeuten, um das 
Problem vielleich lösen zu können.

//--------------------------------------------------------------
// Includes
//--------------------------------------------------------------



#define USBD_CFG_MAX_NUM                1
#define USBD_ITF_MAX_NUM                1
#define USB_MAX_STR_DESC_SIZ            50 


#define CDC_IN_EP                       0x81  /* EP1 for data IN */
#define CDC_OUT_EP                      0x01  /* EP1 for data OUT */
#define CDC_CMD_EP                      0x82  /* EP2 for CDC commands */

/* CDC Endpoints parameters: you can fine tune these values depending on the needed baudrates and performance. */

 #define CDC_DATA_MAX_PACKET_SIZE       64   /* Endpoint IN & OUT Packet size */
 #define CDC_CMD_PACKET_SZE             8    /* Control Endpoint Packet size */

 #define CDC_IN_FRAME_INTERVAL          5    /* Number of frames between IN transfers */
 #define APP_RX_DATA_SIZE               2048 /* Total size of IN buffer:
                                                APP_RX_DATA_SIZE*8/MAX_BAUDARATE*1000 should be > CDC_IN_FRAME_INTERVAL */

[Stromverdichter (Gast)]

Hallo Marc,
der USB nutzt ja selbst wieder Interrupts. Wenn dieser während deiner 
Messung auftritt, wird wohl deine Messung wohl falsch. Also könntest du 
doch sicherstellen, dass nicht beide gleichzeitig aktiv sind. Das sollte 
doch helfen.
Ansonsten könntest du dir den Debugger so einstellen, dass er direkt 
hält, wenn fehlerhafte Werte auftreten. Du musst halt noch ein paar 
Flags in deinem Code verteilen, um den zeitlichen Verlauf der 
Interrupt-Routinen zu verfolgen. Dann solltest du dem eigentlichen 
Problem näher kommen.

[Mark W. (mark_wer)]

Die Interrupts sind schon so berücksichtigt, das alles passt. Und die 
falschen Messwerte sind nicht wirklich falsch, da der Signalgenerator 
beim Umschalten zwischen zwei Frequenzen bisschen braucht und diese Zeit 
dazwischen ist eben nicht gewollt und wird rausgefiltert. Vielleicht 
liegt das Problem auch PC seitig und ich muss mir das Programm da noch 
anschauen...
Über eine kurze Erklärung, v.a. zu den letzten vier defines in der usb 
config würde ich mich trotzdem freuen, wollte die eh schon länger mal 
nachvollziehen können.

[STM32 (Gast)]

Das Problrm kommt mir bekannt vor, allerdings damals mit der USB-Lib vom 
'L152

Mark W. schrieb:
> ich nutze eine abgewandelte Lib von ST um den STM32 als CDC Device zu
> nutzen.

Schau mal in dieser Lib nach, ob nicht irgendwo der Systemclock 
zurückgesetzt wird. Soviel ich noch weiß, war da irgendwo was in 
hwconfig.c, da wurde der Takt das AD-Wandlers überschrieben.

[Marcus H. (Firma: www.harerod.de) (lungfish)]

Wenn Dir die USB-Spec zu staubig ist, dann suchst Du:
"usb in a nutshell"

[Jim M. (turboj)]

Mark W. schrieb:
> Teilweise kommt wird bei
> einem Sweep allerdings noch 64 vorherige Werte mitgemessen und dann ist
> die 64*x Messung Müll, was sich nicht mehr so gut rausfiltern lässt.

Ist die Fifo Implementation korrekt..? Über-/Unterlauf?

Könnte auch das bekannte Problem mit USB sein, dass Pakete mit 
MAX_PACKET_SIZE nicht sofort an die Applikation übergeben sondern 
erstmal gepuffert werden, bis ein Paket < MAX_PACKET_SIZE übertragen 
wurde [1].

Am Ende einer Übertragung eines ganzzahligen Vielfachen von 
MAX_PACKET_SIZE muss daher ein Zero-Packet gesendet werden.

Das macht AFAIK so gut wie keine CDC Implementation von sich aus, ich 
musste das nachträglich reinhacken. In realen UART<->USB_CDC 
Implementationen taucht das Problem nicht auf, da der UART die 
MAX_PACKET_SIZE Bytes nicht schnell genug voll bekommt.

Debugger klingt erstmal gut, könnte Dir hier aber ebenfalls das Timing 
versauen.

[1] Vorgabe der USB Spezifikation für Bulk Transfers