Sziasztok!

Van egy kis gondom a fent említett MAX3420E USB vezérlővel kapcsolatban. Letöltöttem a gyártó oldaláról az "USB Enumeration Code (and More) for the MAX3420E" nevű példaprogit, aminek elvileg egy HID szabványnak megfelelő billentyűzetet kéne emulálnia. Én PIC24HJ128GP502-t használok, át is írtam a megfelelő regiszter író és olvasó függvényeket, amik hibátlanul működnek is, de a Windows mégis azt mondja, hogy nem tudja felismerni az USB eszközt.

Próbálkozott már valaki ezzel az IC-vel? Esetleg valami ötlet?

Köszi: Dávid

Még annyi infó, hogy az USB rész is működik mert megjönnek a SETUP csomagok, csak nem tudom ellenőrizni hogy válaszol-e rájuk.

Szia,
Kapcsolási rajzot fel tudnál rakni? Első körben a hardvert kéne átnézni.
Pl: D+, D- lábakon a felhuzó ellenállások rendben vannak?

Látom belsőleg kezeli a felhúzó ellenállásokat ha az R15 regiszter CONNECT bitjét bebillented. Ezután indul az enumeráció, és ha rendben válaszol a SETUP packetekre akkor a hostnak elvileg fel kell ismernie.

Triviális hardveres hibák amire a fenti hibaüzenet jöhet: Reset probléma, kvarc oszcillátor értéke, stabilitása, hidegítő kondik nem megfelelő értéke, vagy éppen a D-, D+ fordított bekötése.
Self-powered (vagyis ha nem az USB tápról működik) kapcsolás esetén célszerű az USB csatlakoztatott állapotát figyelni és a chipet minden esetben resetelni az SPI buszon. Egyelőre ennyi ötletem van.

Szerintem hardver hiba nincs, mert a SETUP packetek megjönnek és debuggolás alapján a PIC válaszol is rájuk, de mégse jön össze az enumeráció. Egyébként self-powered módban van bekötve a gyári kapcsolás alapján, és minden alkatrész értéke ugyanaz, mint amit az adatlapban ajánlanak. A PIC indulásakor reseteli a MAX3420E-t is, SPI oldalon nincs hiba, szerintem USB oldalon sem. Minden működik, csak az enumeráció nem megy.
Szerintem szoftver hiba lehet inkább. Annyit csináltam, hogy letöltöttem az említett példaprogit, és a PIC-hez módosítottam az SPI író-olvasó függvényeket. Ezt fel is rakom, hátha talál benne hibát valaki.

Köszi

A feltétel vizsgálat szándékosan van kikommentezve?
Igy ránézésre a service_irqs() -nak csak egyszer kéne futnia egy megszakitáskérésre. Nem lehet hogy igy több dolgot akar küldeni a PIC? Tudnád debuggolni hogy pontosan azt válaszolja amit a host vár?
Vagy lehet hogy valamelyik descriptorban van hibás adat.

Igen, az szándékosan van kiszedve. Javasolja is az egyik Maxim App Note hogy először ne foglalkozzunk a megszakítással. Így mindig ellenőrzi a MAX3420E megszakítás bitjeit. Sajnos nem tudom teljesen debuggolni, mert egy Pickit2 klónom van és valamiért nem lép be debug módba. Pedig az MPLAB szerint kéne szeretniük egymást. Megpróbálom kideríteni, hogy mit küld vissza a PIC (csináltam saját breakpoint függvényt ilyen célokra). Ha viszont a descriptorokban van hiba, az szomorú mert ahhoz nem nagyon értek.

Három programozó/nyomkövető bemenet van a PIC24HJ128GP502 mikrovezérlőn. Programozni bármelyikről lehet, debugolni csak arról, amit a konfigurációs bitek beállításánál engedélyeztél. Például:

Esetleg próbáld ki ezt a progit:
USB trace
Én pár éve használtam egy előző verzióját, sokat segitett. Töltsd le mellé az HID class dekódert is.
Ha felteszed a fórumra a trace eredményét (log file, screeenshot stb.) megpróbálok segiteni. De a PIC debug szerintem megkerülhetetlen dolog.

Próbáltam már ezt a progit, de vagy nem mutatja az enumerációt, vagy tényleg nem történik ott semmi. Vagy én nem értem a működését

Jó helyre van állítva ez is. Nem lehet hogy a pickit2 klón miatt van? Olvastam, hogy pl akkor lehet ilyen hiba, ha nincs 4k7 lehúzó ellenállás a PGC/PGD lábakon, de az én verziómban ez is van. Nem tudom mi lehet a baja. Próbáltam anno egy dsPIC30F3014-gyel is, ott működött a debug funkció.

Itt egy USBTrace log: Bővebben: Link

Milyen frekvencián (Fosc vagy Fcy) jár a PIC24 és milyen SPI frekvenciát választottál?

Ha jól látom, SPI1CON1 beállítása így néz ki:


Ha a PIC24 20 MHz-nél (10 MIPS) gyorsabban fut, akkor ez érvénytelen beállítás (az elsődleges vagy a másodlagos osztót 1-től különböző osztásarányra kell beállítani).

Igen, olvastam hogy 9MHz körül van a vége. Én most 8 MIPS-en járatom a PIC-et, így 8MHz-en megy az SPI is. Ott amúgy nincs is hiba, mert kipróbáltam hogy írtam adatokat az egyik FIFO-ba és hibátlanul vissza is tudtam olvasni őket. Na meg a regiszterek írása és olvasása is működik.

Egy kis debug után úgy tűnik, hogy azt a descriptort küldi el, ami az eredeti header fájlban meg van adva. Mondjuk érdekes, hogy abban az USB verzió 1.0-ra volt állítva, azt átírtam 2.0-ra de nem változott semmi.

Ez elég érdekes dolgokat produkál, ha az MAX3420E közben full speed eszköznek mondja magát a D+ vonal felhúzásával.

Én is furcsának tartom, hogy a gyári progiban ilyen van, ezért is írtam át. Már csak azt nem tudom, hogy miért nem működik

Szerintem debuggold az SPI kommunikációt és tedd fel az eredményt. Abból kiderithetünk valamit. Egyébként miből tudod hogy a Setup packetek megérkeznek?

Kiolvastam a bejövő adatokat (ezeket SETUP packet esetén külön FIFO-ba rakja), és összehasonlítottam azzal, ahogy egy SETUP packetnek ki kell néznie. amikor rádugom az USB-re az áramkört, akkor néhányszor kéri a Device Descriptort, aztán jön a Windowsos hibaüzenet.

Az USB trace logban nem látok IN packetet.
Kapcsold ki a Capture funkciót, és jelöld be a "Capture hot plugged device" ikont. Aztán start capture. Akkor logolja az enumerációt is. Abban kell látni " Get_descriptor..." requesteket és rá a "Control transfer" IN packeteket. Az lenne érdekes.

Igy néz ki egy sikeres enumeráció. Ez egyébként egy Microchip MCP2200 kontroller.

Be volt kapcsolva a hot-plug capture is meg az entire stack is. Ezek szerint nem válaszol egyáltalán?

Valami nem OK nálam az USBTrace háza táján. Kipróbáltam egy működő USB cuccal, és ott is csak OUT packetek vannak enumerációkor. A Filter nincs bekapcsolva. Egyre érdekesebb...

Nekem úgy tűnik hogy nem válaszol. Próbáld ki úgy hogy amikor a Trace-t indítod, az eszköz ne legyen csatlakoztatva, és csak ezt az eszközt figyeld( gondolom ez eddig is így volt). Amikor a kábelt rádugod a hostnak kérnie kell a descriptorokat hogy azonosítsa az eszközt. Legalább a Configuration, Interface és Endpoint descriptorokat el kell küldenie. Ezek mind az Endpoint0-n keresztül mennek (ez is érdekes a logban amit küldtél más értékek is vannak) . Ha semmilyen válasz nem jön, és az USB chip csak az SPI buszon érkező adatokat küldi (Az adatlap elég szűkszavú, ha nem megy a PIC tud enumerálni önállóan?) és a hardver is jó akkor mégis csak az SPI kommunikációt kell debuggolni.

Most épp nem nagyon értem az USBTrace-t. Enumerációkor semmilyen USB cuccnál nem mutat IN packeteket, ha viszont a Pickit2-n kattogtatom a Resetet MPLAB-ból, akkor IN és OUT is rendesen.
Az SPI-on mi lehet rossz ha tudom olvasni a SETUP packeteket és jól működnek a regiszter írások is? Hogy tudnám ellenőrizni?

Akkor lsd. valamelyik előző válaszom, ez lehet az USB chip reset problémája is. Figyelni kell a kábel csatlakoztatását, és akkor resetelni a chipet. Lehet hogy ez megoldja a problémát.

Sajnos ez a lehetőség is ki van már lőve, a PIC mindig reseteli az USB chipet, mielőtt bekattintja a CONNECT bitet.

És a CONNECT bitet mindig ki-be kapcsolod attól függően hogy van-e táp az USB kábel felől?

Gyakorlatilag igen, de nem én, hanem tud ilyet automatikusan az USB chip. Állítólag benne van az USB 2.0 szabványban, hogy ha a host kikapcsolja a tápfeszt, akkor le kell szedni a 1,5kOhmot a D+ vonalról. És ez a kis IC ezt meg is csinálja. Azt hiszem én mára feladom, aztán majd holnap folyt köv. Nagyon köszönöm az eddigi segítséget is!

Üdv !

Nem tudom volt e már róla szó, de nekem ilyen probléma akkor is volt, ha nem jó sebességen ment az usb. (igaz nem maxim-al).
De ha rossz a sebesség akkor is ez a hibajelenség látható host oldalon.
Úgy láttam a maximban is van pll, tehát gondolom hozzá kell állítani az órajelforráshoz.

Remélem tudtam segíteni.