USB 18F4550 enumerering misslyckas [Löst]Lita inte på usbmon

[Marta]

Jag har ett magiskt problem med en PIC 18F4550 revisions-ID 02 12. PC har kernel 3.2.0-4-686-pae.

Försöker få den att enumerera med CDC-class och har provat med färdiga exempel på descriptors men det vill sig inte. Den fysiska kommunikationen tycks fungera, men den kräker över configdescriptorn redan när den bara läst in själva configdescriptorn, de första 9 bytes av denna klump.

Någon som har en ide vad som kan vara fel och/eller descriptors som *verifierat* fungerar på nämnda MCU?

Här är utskrifterna från usbmon (packets till hub bortredigerade) såväl som dmesg.

Kod: Markera allt

f7711e40 2408122174 S Ci:2:000:0 s 80 06 0100 0000 0040 64 <
f7711e40 2408125356 C Ci:2:000:0 0 18 = 12010002 00000040 addeefbe 00000102 0301
f7711e40 2408233889 S Co:2:000:0 s 00 05 000b 0000 0000 0
f7711e40 2408236345 C Co:2:000:0 0 0
f77110c0 2408253876 S Ci:2:011:0 s 80 06 0100 0000 0012 18 <
f77110c0 2408257352 C Ci:2:011:0 0 18 = 12010002 00000040 addeefbe 00000102 0301
f77110c0 2408257400 S Ci:2:011:0 s 80 06 0600 0000 000a 10 <
f77110c0 2408259353 C Ci:2:011:0 -32 0
f77110c0 2408259394 S Ci:2:011:0 s 80 06 0600 0000 000a 10 <
f77110c0 2408261346 C Ci:2:011:0 -32 0
f77110c0 2408261388 S Ci:2:011:0 s 80 06 0600 0000 000a 10 <
f77110c0 2408263346 C Ci:2:011:0 -32 0
f77110c0 2408263400 S Ci:2:011:0 s 80 06 0200 0000 0009 9 <
f77110c0 2408266356 C Ci:2:011:0 -75 9 = 09023000 02010080 19
f77110c0 2408266398 S Ci:2:011:0 s 80 06 0200 0000 0009 9 <
f77110c0 2408269346 C Ci:2:011:0 -75 9 = 09023000 02010080 19
f77110c0 2408269390 S Ci:2:011:0 s 80 06 0200 0000 0009 9 <
f77110c0 2408271351 C Ci:2:011:0 -75 9 = 09023000 02010080 19
f77110c0 2408271790 S Ci:2:011:0 s 80 06 0300 0000 00ff 255 <
f77110c0 2408276344 C Ci:2:011:0 0 4 = 04030904
f77110c0 2408276383 S Ci:2:011:0 s 80 06 0302 0409 00ff 255 <
f77110c0 2408281350 C Ci:2:011:0 0 56 = 38035100 75006100 63006b00 20005300 74006100 
f77110c0 2408281394 S Ci:2:011:0 s 80 06 0301 0409 00ff 255 <
f77110c0 2408286350 C Ci:2:011:0 0 44 = 2c035500 70007000 65007200 20004400 75006300 
f77110c0 2408286397 S Ci:2:011:0 s 80 06 0303 0409 00ff 255 <
f77110c0 2408291350 C Ci:2:011:0 0 22 = 16033100 32003300 34003500 36003700 38003900 3000

[ 6657.112113] usb 2-1: new full-speed USB device number 11 using uhci_hcd
[ 6657.261594] usb 2-1: unable to read config index 0 descriptor/start: -75
[ 6657.261838] usb 2-1: chopping to 0 config(s)
[ 6657.281595] usb 2-1: New USB device found, idVendor=dead, idProduct=beef
[ 6657.281838] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6657.282063] usb 2-1: Product: Quack State USB Test Device
[ 6657.282234] usb 2-1: Manufacturer: Upper Duckwater Group
[ 6657.282403] usb 2-1: SerialNumber: 1234567890
[ 6657.282912] usb 2-1: no configuration chosen from 0 choices
[ 6662.692224] usb 2-1: USB disconnect, device number 11

[XorXaX]

Jag brukar köra det exempel som följer med när man laddar ner Microchip Application Libraries (MAL), och det fungerar utmärkt när man tar hex-filen rakt upp och ner utan att kompilera om. Är det vad du har testat, eller har du kompilerat om först?

Med XC8-kompilator finns inte bra stöd för USB ännu, så man måste hacka lite i kälkoden för USB-libbarna för att få USB-minnet på rätt ställe i PICen. I varje fall är det så på PIC18F27J53 (har inte testat med 4550 i XC8).

[Marta]

Descriptors är tagna från något krafs jag hittade på nätet, sedan har jag provat att ändra subclass och protocol i device descriptor och provat lite olika om det kunde vara där felet är. Jag skall prova senare att försöka extrahera descriptors från den koden Du nämnde. En annan möljighet är att installera något annat än usbmon som klipper data efter 32 bytes och få ut descriptors från en fungerande enhet. Det blir alternativet i andra hand och om ingen kan se något problem med de descriptors som listats.

Vad betyder "unable to read config index 0 descriptor/start: -75"? Config index 0? Den har ju inte försökt läsa annat än descriptorn via USB och fått begärda 9 bytes, så var kommer detta ifrån? Är det något som läses från strukturer inom Linux och dess moduler till följd av trasig data i descriptorn ?

Koden är inte från Microchip. Den är skriven från scratch i assembler med datablad på kretsen och USB-specifikationen och lite blandade artiklar om USB som underlag. Ingen programkod i någon form så den kan vara helt ren från lånade delar. Skall vara 100% fri från copyright, GPL och allt vad det nu kan vara för restriktioner.

[XorXaX]

Jag har bara använt Microchips libbar för USB, och de fungerar fint (när man fixat de för XC8). Även under Linux.
usbmon har jag aldrig använt och ditt fel tyder ju på att det är något med descriptorn, så du är ju på rätt väg i alla fall.

Ligger descriptorn där den borde i minnet, så att PICen skickar rätt data? Fungerar koden med orginaldescriptorn? Har du kopplat D+ och D- rätt?

[Micke_s]

Rapporterar descriptors rätt längd, har för mig att det finns några define för detta?

[Marta]

Då var problemet hittat, en sk*tbug som hade hittats direkt om usbmon hade gjort det som förväntas av ett debugprogram: Rapporterat vad som verkligen kommer in utan att förändra detta på något sätt.

Jag gjorde själv ett procedurfel som förvärrade detta. Inte göra två ändringar samtidigt. Speciellt inte så stora som att byta både descriptor set och samtidigt rensa upp i rutinen som sänder dessa. Följden blev att oavsett begärd längd 9 för att endast få själva config descriptor så fick den hela klumpen med interfaces och endpoints.

Trots detta visade usbmon att 9 bytes hade mottagits och det kräktes upp ett vilseledande felmeddelande som riktade uppmärksamheten ännu mera mot descriptorns innehåll och bort från längden på sänd packet. Oväntad reaktion, den hade ju fått begärd data och lite till. Undrar vad som egentligen hände. Buffer overflow?

Nu har jag i varje fall lärt mig att inte lita på vad usbmon visar. Vid lusläsning av koden så hittades felet. Hade usbmon visat verklig mottagen packet length hade det sannolikt hittats direkt efter första försöket...

Tack till Er som svarat på min fråga. Micke_s inlägg hjälpte med att rikta uppmärksamheten mot längderna.