STM32L476 USB Code geht nur auf NUCLEO-Board

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 :(

Und Low ist schön bei 0V