LPC1751 USB Device zum Funktionieren bewegen

[Lars R. (larsr)]

Hallo,

Ich habe Schwierigkeiten mit dem Betrieb eines NXP LPC1751 ARM Cortex-M3 
als USB-Device.

PLL usw. ist alles kein Problem, der Controller hat einen 12 MHz Quarz, 
die USB-Peripherie bekommt die 48 MHz als Takt. D+ und D- sind mit 
jeweils 33 Ohm mit dem Controller verbunden, zusätzlich hängt an D- ein 
Pullup mit 1,5 kOhm.

Ich habe das Codebeispiel "Secondary USB Bootloader" ebenso wie die 
Beispiele des "LPC1700 Code Bundle" versucht. In allen Fällen meldet 
sich der Controller mit der Vendor ID und Product ID 0x0000 am PC an.

Damit funktioniert natürlich nichts.

Am Code habe ich sonst nichts verändert, außer das ich in den 
Projekteinstellungen jeweils den LPC1751 als Controller ausgewählt habe.

Welchen Tipp könnt ihr mir geben?


Viele Grüße,

Lars

[Lars R. (larsr)]

Mittlerweile habe ich herausgefunden, dass der Pullup statt an D- an D+ 
gehört. Dies habe ich entsprechend korrigiert, dennoch habe ich leider 
weiterhin keinen Erfolg mit der USB-Verbindung.

Was könnte es sonst noch sein?

[Gerd E. (robberknight)]

Ich kenne das Code Bundle und den von Dir verwendeten Code nicht. Aber 
schau doch mal ob da wirklich eine Vendor und Product ID drinstehen.

Für ne Vendorid mußt Du normalerweise zahlen. Ich könnte mir vorstellen 
daß die jetzt da extra keine mit in das Codebeispiel geschrieben haben, 
damit die Leute diese Vendorid/Productid nicht einfach per Copy&Paste in 
ihre eigenen Projekte übernehmen.

Mein nächster Vorschlag wäre mich mal noch nach anderem Beispielcode 
umzusehen. Ich glaube bei freertos gibt es ein paar Beispiele zu USB. 
Leider sind die LPC17xx in den anderen freien RTOS noch nicht so 
verbreitet und haben daher nur Basis-Support ohne die ganzen 
Hardware-Abstractions für USB, Ethernet etc.

[Gerd E. (robberknight)]

Ach so, noch ein Tipp: Wenn Du ne Vendor/Productid 0 siehst, scheint der 
ja durchaus schon ein Device zu sehen. Schau also mal was da USB-mäßig 
tatsächlich über die Leitung geht.

Entweder nimmst Du dafür nen guten Logic-Analyzer mit USB-Decoder und 
Tool, was Dir nen roten Kringel um die Stelle mit dem Fehler malt 
(träum) - oder Du nimmst den usbmon unter Linux und schaust Dir die 
USB-Spec mal etwas genauer an.

[Lars R. (larsr)]

Gerd E. schrieb:
> Für ne Vendorid mußt Du normalerweise zahlen. Ich könnte mir vorstellen
> daß die jetzt da extra keine mit in das Codebeispiel geschrieben haben,
> damit die Leute diese Vendorid/Productid nicht einfach per Copy&Paste in
> ihre eigenen Projekte übernehmen.

Im Quellcode des Beispiels ist die Vendor-ID von Keil eingetragen und 
eine Product-ID, welche zum mitgelieferten Treiber passt.

Weil ich im Internet direkt von NXP auch ein PDF fand, welches sich 
explizit auf dieses Code Bundle bezieht, gehe ich einfach davon aus, 
dass dieser Code funktionstüchtig ist.

Ich glaube daher eher an ein Problem mit der Hardware, denn diese 
Geschichte mit Vendor-ID und Product-ID gleich 0x0000 wird auch auf dem 
PC angezeigt, wenn ich D+ und D- vertausche (habe diese einfachen Fälle 
schon ausgeschlossen).

Gerätschaften, welche mir so komplexe Dinge wie USB grafisch aufbereiten 
könnten, stehen mir leider nicht zur Verfügung.

[Lars R. (larsr)]

So, ich glaube, ich habe den Fehler gefunden.

Der Beispielcode hat, obwohl es sich um ein USB-Device handelt, sowohl 
den Takt für das USB-Device als auch den USB-Host aktiviert. Auf dem 
Demoboard, für welches der Beispielcode geschrieben ist, befindet sich 
ein LPC1758, der hat auch einen USB-Host deshalb ist es dort scheinbar 
kein Problem.

Da ich allerdings einen LPC1751 einsetze, der keinen USB-Host besitzt, 
führt die Aktivierung der nicht vorhandenen Hostfunktionalität dazu, 
dass der ganze USB-Block nicht mehr korrekt funktioniert.

Nachdem ich die USB-Initialisierung so abgeändert habe, dass nur noch 
die Devicefunktionalität aktiviert wird, meldete sofort der PC ein neu 
gefundenes USB-Gerät und installierte sodann selbsttätig den richtigen 
Treiber.

Seit dem funktionierte die USB-Kommunikation in beide Richtungen...

Im Datenblatt steht auch extra "you should not write to this bit" oder 
so ähnlich, wie wichtig diese Aussage doch ist!