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
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?
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.
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.
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.
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!