PIC18F45K50 - [MikroPascal] USB - awaria nieznanego urządzenia

Jesteś pewien, że oscylator hula na 16MHz?
Bo nie widzę, abyś sprawdzał HFIOFS, PLLRDY
ani abyś używał Active Clock Tuning, co powinieneś chyba robić w tym przypadku.
Dlaczego używasz LowSpeed ?

Albert

Nie używałem PIC18F45K50, nie używałem MicroPascala, nie używałem Windows do debugowania USB.

Z 8 bitowców Microchipa z USB używałem PIC18F14K50 i PIC16F145*
Bardzo dobrym punktem startowym jest MLA http://www.microchip.com/pagehandler/en-us/devtools/mla/home.html
Wszystkie przykłady ruszały praktycznie od razu bez problemu.
Jedyny wyjątek miałem z XC8 w wersji 1.32 i PIC16F1455.
Ale inne wersje OK. Dotyczy to także wersji free kompilatorów (zarówno XC jak i C18)
Zamiast windows używam linuxa, Łatwiej analizować transmisję usb, jako że narzędzia systemowe są bardziej gadatliwe oraz jest https://www.kernel.org/doc/Documentation/usb/usbmon.txt

Nie wiem, czy to Ci pomoże, ale myślę że taka informacja może się przydać.

Albert

Urgon napisał:

problem można chyba zawęzić do samej biblioteki i procesu enumeracji.

Raczej tak. co sugeruje zwłaszcza komunikat 11.
Choć jeszcze przetestowałbym full speed dla pewności ze względu na różne niuanse.
Pytanie na ile program jest przykładem użycia biblioteki, a na ile go modyfikowałeś.

Albert

To dokładnie ten sam błąd (teraz nr 16, poprzednio 11)
Urządzenie nieprawidłowo reaguje na żądanie odczytu deskryptora interfejsu.
Spróbuj full speed, Spróbuj z innymi /vid/pid.

Albert

Urgon napisał:

USBLyzer pokazał mi dokładnie miejsce i znaczenie błędu w komunikacji.

Nie sądzę, abyś miał rację. Przy prawidłowym działaniu urządzenia host nie powinien go usuwać.
A "Removal Relations" jak nazwa wskazuje są częścią procesu usuwania.

Albert

Urgon napisał:

Zmieniłem tę prędkość z USB 2.0 na 1.1.

Nie ma czegoś takiego. To są numery wersji protokołu.
Prędkości to LowSpeed lub FullSpeed.

Urgon napisał:

Przy czym zastanawiające jest, dlaczego biblioteka USB dostarczana z MikroPascalem oraz plik deskryptora przez narzędzie w IDE wbudowane generują te same błędy co biblioteka z LibStock, zaś bootloader z Pinguino działa poprawnie?

Może jednak biblioteki (jak i bootloader) są przystosowane do FullSpeed. Ty natomiast konfigurujesz swój procesor jako LowSpeed (a w przypadku bootloadera tego nie robisz)

Albert

Dla protokołów USB 1.1 i USB 2.0 prędkości interfejsu są określane jako Low-Speed (LS), Full-Speed (FS) i High-Speed (HS). Taktowanie modułu w uC to jedno, ale z punktu widzenia hosta istotne jest na której linii jest podciągnięcie do zasilania po podłączeniu urządzenia. Host lub hub ma wpięte rezystory pull-down na obu liniach danych (D+ i D-), a urządzenie w zależności od prędkości z jaką chce/może pracować musi mieć wpięty pull-up na jednej z linii. Jeżeli to jest LS, to pull-up jest na D-, jeżeli to jest FS, to pull-up jest na D+. Być może tutaj jest problem z brakiem wymiany informacji. Ja używam USBTrace do podglądania transmisji, ponieważ daje bardzo dobry podgląd na transmisję i dość dobrze dekoduje klasy urządzeń. Jeżeli po dołączeniu urządzenia (włączenie pull-up'a) nie przychodzi żadne żądanie z hosta, to pewnie wszystko jest skonfigurowane na inną prędkość. Dostajesz pakiety SETUP i odpowiadasz na nie? Jeżeli nie działa logowanie ruchu po UART, to loguj wszystkie odebrane pakiety do ramu, a po zatrzymaniu programu będziesz wiedział gdzie szukać błędu.

W pierwszym programie (post #1) pojawiło się wywołanie procedury: InitUSB;
W kolejnej wersji (post #7) wywołujesz HID_Enable(@readbuff,@writebuff);
Nie wiem co robią te funkcje i jakich definicji oczekują, ale na pewno szukałbym błędu w organizacji pamięci (obszar musi być dostępny dla USB) i konfiguracji przerwań (wektory, zezwolenia i same funkcje).
To wszystko dlatego, że patrząc w logi widać, że urządzenie się zgłosiło, czyli programowe włączenie (pull-up) działa, ale nie przesyła ani jednego bajtu. Jeżeli układ podłączasz bezpośrednio do komputera (bez huba) to zawsze po drodze jest kontroler usb i to do niego jest kierowany co drugi pakiet (Status success). Urządzenie jest kompletnie głuche lub nawet jeżeli przyjmuje pakiety, to nie potrafi odpowiedzieć. Dlatego co druga linia to (Status not supported).
Niezależnie od tego co piszą na stronie µPascal'a czy innych, sprawdziłbym czy przerwania są włączone, czy wykonywane są funkcje w poszczególnych obszarach obsługi USB, a jeżeli są, to logowałbym cały ruch (czas+dane) do ramu lub wyrzucałbym to przez szybki (115200) uart do PC. Mając logi ze strony uC, będzie duuużo łatwiej znaleźć błąd. W tej chwili nic innego nie potrafię doradzić.
A w załączniku możesz zobaczyć logi dla urządzenia VCP (FS).

Marek_Skalski napisał:

Jeżeli układ podłączasz bezpośrednio do komputera (bez huba) to zawsze po drodze jest kontroler usb i to do niego jest kierowany co drugi pakiet (Status success).

Choć nie używam także tych programów co kolega myślę Marku, że źle je interpretujesz.
Co drugi pakiet to pakiet OUT - czyli wychodzący z hosta, a co drugi IN - przychodzący.

Albert

albertb
Jeżeli urządzenie działa prawidłowo, to wtedy w logach są 2 operacje dla każdego transferu:
1. Wynik operacji przesłania polecenia/danych między systemem a kontrolerem usb.
2. Wynik operacji przesłania polecenia/danych między kontrolerem usb a urządzeniem.
To widzę zawsze w logach z moich urządzeń, gdzie w komputerze jest 7 kontrolerów usb, każdy ma 2 porty, a urządzenie jest przypięte do jednego z portów.
Ponieważ w logach Urgona widzę za każdym razem tylko 1 operację w każdym kierunku, dlatego wnioskuję, że wszystko działa dobrze na poziomie hosta, czyli polecenia i dane są przesyłane do kontrolera usb, a ten odpowiada. Niestety, kontroler nie potwierdza przesyłania danych do urządzenia, pewnie brak ACK lub NACK i podobnie kontroler nie może potwierdzić odbioru danych dla transakcji IN, ponieważ w zadanym czasie nie dostaje żadnych informacji z urządzenia.
Ale to tylko moje spekulacje i masz rację, mogę się mylić.
Urgon
Niestety, nie mam czym rozpakować biblioteki z której korzystasz, nie mam też takiego uC aby sprawdzić na żywo. Może jednak spróbujesz z kodem w C? Wtedy przynajmniej możesz użyć symulatora. Jeżeli masz ICD 3 lub PicKit3 to nie powinno być problemu z programowaniem i debugowaniem w MPLAB X.

Marek_Skalski napisał:

Ponieważ w logach Urgona widzę za każdym razem tylko 1 operację w każdym kierunku, dlatego wnioskuję, że wszystko działa dobrze na poziomie hosta, czyli polecenia i dane są przesyłane do kontrolera usb, a ten odpowiada. Niestety, kontroler nie potwierdza przesyłania danych do urządzenia,

Ale analizatora prawdopodobnie używasz innego jak i ja.
Zwróć uwagę, że zalogowane komunikaty różnią się kierunkiem (na przemian) i rodzajem zapytania (ale w parach) Natomiast pozostałe pola są identyczne. W kontekście tego jaki i widocznego zapytania o interfejs (takie zapytanie do kontrolera to raczej mogłoby być na etapie enumeracji kontrolera) uważam co napisałem. Ale to moje spekulacje i też mogę się mylić . Reasumując nie polecałbym programu, który daje takie logi.

Albert

Używamy tego samego programu - USBTrace i dlatego pozwalam sobie porównać zawartość plików
Jak znajdę chwilę, to podłączę urządzenie i zatrzymam enumerację na pierwszym odebranym pakiecie dla sprawdzenia czy dostanę podobne logi jak Urgon. Ale to nie dzisiaj.

Te błędy dla komend PnP, to nie są błędy. To tylko odpowiedź z urządzenia, że nie potrafi pracować jako High-Speed.
Pozostałe "Invalid Device Request", to informacje prawidłowo przesyłane z urządzenia, które informują hosta, że pewnych elementów protokołu urządzenie nie obsługuje. W protokole są polecenia, które muszą być obsługiwane obowiązkowo, np. Get Descriptor, Set Address, Set Configuration. Są też żądania opcjonalne i nie wszystkie muszą być implementowane w urządzeniu, np. sygnał dzwonka dla klasy CDC, jeżeli pracuje jako VCP.
Fajnie, że działa