Hallo liebes Forum, ich versuche jetzt schon seit einigen Tagen erfolglos die USB-Schnittstelle eines STM32L476 zum Laufen zu bekommen. Ziel ist es am Ende einen einfachen Virtual COM Port zu haben. Sowohl software- als auch hardwareseitig ist nicht wirklich ein Fehler zu finden. Zur Software: Zum Testen habe ich einfach mal mit dem CubeMX den Code für USB generieren lassen. Diesen habe ich dann auf ein NUCLEO Board, das den STM32L476 als Controller enthält, aufgespielt und die Pins PA12 (D+), PA11 (D-) mit einer USB Buchse verbunden. Das hat dann einwandfrei funktioniert, Windows erkennt den Virtual COM Port. Dann habe ich das ganze 1:1 auf meine eigentliche Hardware geflasht und da erkennt Windows gar nichts. Zur Hardware: Nach dem Software-Test ist nun ein Hardware-Fehler naheliegend. Zuerst habe ich die Anschlüsse auf Richtigkeit überprüft. Alles ok. Dann habe ich die USB-Schnittstelle direkt mit Fädeldrähtchen an die Controllerpins geführt. Aber auch in der Konstellation rührt sich rein gar nichts. Hab dann mal die Pegel der Datenleitungen nach dem Einstecken gemessen. Beim NUCLEO waren beim D+ 3,3V und bei meiner Hardware nur um die 0,8V. Hab da jetzt die Befürchtung, dass mit dem Controller selber was nicht stimmt. Wisst ihr vielleicht was da los sein könnte? Ich wäre für jede Anregung dankbar. VG Joe
Joe schrieb: > Dann habe ich das > ganze 1:1 auf meine eigentliche Hardware geflasht und da erkennt Windows > gar nichts. Wenn Windows auch nach Minuten kein (!)(Ausrufezeichen, unerkanntes Gerät) im Gerätemanager hat, fehlt der Pullup 1,5k nach 3,3V auf der D+ Leitung.
Joe schrieb: > Nach dem Software-Test ist nun ein Hardware-Fehler naheliegend. Wenn man haarscharf nach Nucleo-Schaltplan kopiert sollte eigentlich nichts schiefgehen. Ansonsten schon.
Erst mal danke an euch beide für eure schnellen Antworten.
@Jim M. (turboj)
Auch nach mehreren Minuten passiert leider nichts. An den Pullup hatte
ich auch schon gedacht, aber (korrigier mich, wenn ich falsch liege) der
ist doch intern schon vorhanden und wird bei der Init aktiviert. Das
müsste durch die Funktion USB_DevConnect passieren.
/**
* @brief USB_DevConnect : Connect the USB device by enabling the
pull-up/pull-down
* @param USBx Selected device
* @retval HAL status
*/
HAL_StatusTypeDef USB_DevConnect(USB_OTG_GlobalTypeDef *USBx)
{
uint32_t USBx_BASE = (uint32_t)USBx;
USBx_DEVICE->DCTL &= ~USB_OTG_DCTL_SDIS;
HAL_Delay(3U);
return HAL_OK;
}
@Rath Geba (Gast)
Der Schaltplan ist nicht das Problem. Die Pins sind beim Nucleo ja nur
rausgeführt und Schutzdiode und Reihenwiderstände sind da ja noch gar
nicht verbaut (so wär das auf jeden Fall Pfusch). Die Schutzbeschaltung
an sich ist auch ok, die hatte ich schon mal erfolgreich auf einer
anderen Hardware verwendet.
Sicher das der USB Widerstand im Chip verbaut ist? Suche die Stelle im data sheet wo das explizit angegeben ist. Kenne den Prozessor nicht aber BluePill und STM32F407VE Black haben den extern. Und mit CubeMX habe ich die Tage erst VCP gebaut und löpt 1a, sogar mit dem zu großen 10K Widerstand.
Also der STM32F7 hat jedenfalls einen internen Pull-up. Hast Du eventuell irgendwo eine kalte Lötstelle oder einen Kurzschluss? Lade doch mal einen Ausschnitt des Schaltplans und vielleicht ein Foto hoch.
Achso, benutzt Du vbus sensing? Passt der Pegel da?
Joe schrieb: > Der Schaltplan ist nicht das Problem. Doch, der Schaltplan und dessen Ausführung (das Layout) ist das Problem. Denke mal an Spannungsversorgung und Abblockung, auch die Abblockung intern erzeugter Spannungen. Denke mal an die übrigen kleinen Feinheiten ... Joe schrieb: > Dann habe > ich die USB-Schnittstelle direkt mit Fädeldrähtchen an die > Controllerpins geführt. Gehören da nicht auf jeden Fall zwei Trennkondensatoren für DC dazu?
Joe schrieb: > Der Schaltplan ist nicht das Problem. Die Pins sind beim Nucleo ja nur > rausgeführt und Schutzdiode und Reihenwiderstände sind da ja noch gar > nicht verbaut (so wär das auf jeden Fall Pfusch). Die Schutzbeschaltung > an sich ist auch ok, die hatte ich schon mal erfolgreich auf einer > anderen Hardware verwendet. Wenn die Hardware tatsächlich i. O. ist, fallen mir noch ein: - Option Bytes, zwar sehe ich auf Anhieb da nichts, was unmittelbar mit USB zu tun hat, aber ... - Takt: Auf den meisten Nucleos (welches ist es übrigens, es gibt mit L476 nämlich mindestens 3 Typen) sind keine Quarze, statt dessen speist der STLink über den MCO-Ausgang den Target-MCU. Deshalb wär's wichtig zu wissen, ob NUR USB nicht geht, oder ob die Firmware insgesamt nichts tut ... Außerdem könnte man doch mal mit 'nem Debugger in denRCC- und USB-Registern etwas herumstochern, ob da auch alles wie beabsichtigt initialisiert ist.
A. B. schrieb: > - Takt: Auf den meisten Nucleos (welches ist es übrigens, es gibt mit > L476 nämlich mindestens 3 Typen) sind keine Quarze, statt dessen speist > der STLink über den MCO-Ausgang den Target-MCU. Bin ich auch schon reingefallen. Wenn man den Controller so konfiguriert wie auf dem Original Nucleo Board dann braucht man eben einen Quarz an OSC_in und OSC_out oder einen (extern generierten) 8 MHz Takt an OSC_in. Hat man das nicht dann läuft der Prozessor zwar, aber nicht mit richtigem Takt und der USB hat dann auch den falschen.
A. B. schrieb: > - Takt: Auf den meisten Nucleos (welches ist es übrigens, es gibt mit > L476 nämlich mindestens 3 Typen) sind keine Quarze Und wenn man das mit internem Takt laufen läßt, geht zwar alles, aber nicht USB, weil der HSI nicht genau genug ist [1]. So jedenfalls beim M4, und das wird hier kaum besser sein. [1] HSI hat +/- 1% (und das auch nur bei 25°C), während USB an der relevanten Stelle des Clockpfades 48 MHz +/- 0.25% braucht.
Danke für die vielen Hinweise. NichtWichtig schrieb: > Sicher das der USB Widerstand im Chip verbaut ist? Ja, da bin ich mir zu 100% sicher. Zum einen habe ich das im Reference Manual gelesen und zum anderen allein schon deshalb, weil man es mit dem Cube einstellen kann. gt schrieb: > Achso, benutzt Du vbus sensing? Passt der Pegel da? Nein, vbus sensing wird nicht verwendet. Aber der Hinweis ist gut, da war in früheren CubeMX Versionen mal ein Bug drinnen. Rath Geba schrieb: > Doch, der Schaltplan und dessen Ausführung (das Layout) > ist das Problem. > Gehören da nicht auf jeden Fall zwei Trennkondensatoren für DC > dazu? Die Schaltung ist folgendermaßen aufgebaut: Jeweils ein Widerstand (22 Ohm) bei den Datenleitungen in Reihe und noch parallel dazu eine ESD-Schutzdiode. Einen DC-Block braucht man da nicht. Und genauso (sogar die Bauteile sind gleich) hat es auch schon mal auf einer anderen Platine (gleicher Controller) funktioniert. Einzig die Leitungsführung ist natürlich anders. Aber die hab ich durch den Fädeldrahtversuch ausgeschlossen (das war dann exakt die gleiche Verdrahtung wie beim NUCLEO, wo es funktioniert hat). A. B. schrieb: > - Option Bytes, zwar sehe ich auf Anhieb da nichts, was unmittelbar mit > USB zu tun hat, aber ... > Deshalb wär's wichtig zu wissen, ob NUR USB nicht geht, oder ob die > Firmware insgesamt nichts tut ... Option Bytes ist eine super Idee, die können viel durcheinander bringen. Werd ich auf jeden Fall mal durchgehen, auch wenn mir spontan keines einfällt, das mit USB zu tun hat. Hier ist der Link zum Nucleo Board: https://www.digikey.de/product-detail/de/stmicroelectronics/NUCLEO-L476RG/497-15881-ND/5347711 > - Takt: Auf den meisten Nucleos (welches ist es übrigens, es gibt mit > L476 nämlich mindestens 3 Typen) sind keine Quarze, statt dessen speist > der STLink über den MCO-Ausgang den Target-MCU. > > Deshalb wär's wichtig zu wissen, ob NUR USB nicht geht, oder ob die > Firmware insgesamt nichts tut ... Rath Geba schrieb: > Wenn man den Controller so konfiguriert wie auf dem Original > Nucleo Board dann braucht man eben einen Quarz an OSC_in und > OSC_out oder einen (extern generierten) 8 MHz Takt an OSC_in. > > Hat man das nicht dann läuft der Prozessor zwar, aber nicht mit > richtigem Takt und der USB hat dann auch den falschen. Nop schrieb: > Und wenn man das mit internem Takt laufen läßt, geht zwar alles, aber > nicht USB, weil der HSI nicht genau genug ist [1]. So jedenfalls beim > M4, und das wird hier kaum besser sein. > > [1] HSI hat +/- 1% (und das auch nur bei 25°C), während USB an der > relevanten Stelle des Clockpfades 48 MHz +/- 0.25% braucht. Die Clockgeschichte könnte tatsächlich die Lösung sein. Für das Testprogramm hatte ich den internen Takt verwendet. Um es möglichst wenig zu verfälschen hab ich beim Testprogramm die selben Clockeinstellungen wie bei der richtigen Firmware verwendet. Bis auf USB geht da alles. Ich werde mich dann am Wochenende mal hinsetzen und einmal die Option Bytes und anschließend die Clockeinstellungen überprüfen. Ich werde dann berichten...
Aber wie ist das nochmal mit dem Nucleo Board, wenn ich da die interne Clock verwende (so hatte ich es konfiguriert), ist die dann genauer als auf meiner Platine wegen der Speisung vom STLink? Sonst würde es nicht gehen oder?
Vielleicht passt der genauer? Hast Du einen Frequenzzähler? Dann gib den internen Takt bei beiden an MCO aus und miss nach.
Das wär die Erklärung, wenn der genauer ist. Nachmessen wird schwierig, weil mir privat dafür die Messgeräte fehlen :( Ich probiers jedenfalls noch mit dem externen Quarz, vielleicht gehts dann.
Joe schrieb: > Aber wie ist das nochmal mit dem Nucleo Board, wenn ich da die > interne > Clock verwende (so hatte ich es konfiguriert), ist die dann genauer als > auf meiner Platine wegen der Speisung vom STLink? Sonst würde es nicht > gehen oder? Der F103 für den STLink hat immer einen 8 MHz Quarz (s. UM1724, Fig. 29), die MCO-Ausgangsfrequenz sollte also mehr als ausreichend genau sein. Der STLink braucht ja intern einen hinreichend genauen Takt für sein eigenes USB-Interface. Und Clock-Recovery vom USB-Host gabs bei F1 noch nicht.
Joe schrieb: > Ich probiers jedenfalls noch mit dem externen Quarz, vielleicht gehts > dann. Das wird - mit der exakt gleichen Firmware wie beim Nucleo - nicht funktionieren, denn dort müsste eigentlich HSE-Bypass eingestellt sein (es sei denn, man übersteuert den internen Oszillator brutal mit dem externen Takt, das wär' aber etwas unfein). Das einfachste ist doch, sich vom Nucleo-Board probeweise den MCO vom STLink zu "leihen", sprich zwei Strippen ... Der Ausgang vom F103 sollte keine Schwierigkeiten mit zwei Eingängen und ein paar cm Kabel haben - 8 MHz ist's noch recht gemächlich.
A. B. schrieb: > Das wird - mit der exakt gleichen Firmware wie beim Nucleo - nicht > funktionieren Mit der exakt gleichen Firmware wirds nicht gehn, da geb ich dir recht. Eine Änderung wird notwendig sein. Aber den Takt "ausleihen" ist auch eine gute Idee. Werd ich dann auch machen, wenns mit dem externen Quarz immer noch nicht hinhaut. Werd jetzt aber erstmal meine HSE aktivieren, da hatte ich früher eh schon einen 8 MHz Quarz vorgesehen, aber bisher nicht verwendet, weils bei der Umstellung von HAL auf LL Probleme gab und ich erst mal mit HSI bzw MSI gearbeitet hab (und irgendwann keine Lust mehr hatte HSE einzubauen, als ich die Lösung später bei einem anderen Projekt hatte).
Hi, Ich bin jetzt mal der Clocksache nachgegangen. Leider erfolglos :( Ich habe es mit einem externen Quarz versucht und auch mit dem vom Nucleo Board. Habe dann auch mal den Code, der die interne Clock verwendet, mal auf der anderen Hardware laufen lassen, die ich in einem anderen Projekt entwickelt habe (gleicher Controller) und da hat es geklappt. Also bei dem STM32L476 scheint es keine Probleme mit Taktungenauigkeiten zu geben. Hab dann aus Verzweiflung mal einen 1,5kOhm Pullup bei D+ eingelötet. Da hat sich der Pegel an D+ nur minimal auf 0,85V erhöht. Macht da dann nicht der Controller irgendeinen Blödsinn oder wie kann man sich diesen Pegel erklären? Oder habt ihr noch eine Anregung wo ich suchen könnte? Gruß Joe
Hm, da bleibt wohl nur: Lötstelle oder uC kaputt ... PA11 und P12 als normale PP-Ausgänge konfigurieren, togglen und Oszilloskop oder Logikanalysator dran.
PA12 gibt nur 2,2V aus, wenn man den auf High setzt. PA11 dagegen 3,3V. Fürchte da gibts keine andere Möglichkeit mehr als Controller kaputt :(
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.