u

Ciągle czekamy na analizę ruchu w kablu, czemu tego nie zrobisz? Etap wróżenia z fusów się już za nami...

Chwilowy brak czasu - miałem parę innych spraw na głowie, wiec skupiłem się na tych testach, które można wykonać "z doskoku". Jak wspominałem, problemu nie można striggerować na żądanie, a niekiedy pojawia się on dopiero po kilku dniach pracy urządzenia. Będe musiał więc wziąć laptopa, ustawić na nim połączenie bridge i przechwytywać cały ruch za pomocą tcpdumpa, być może nawet przez kilka dni.

Na razie porównałem działanie firmware'u na kilku różnych rewizjach płytki. Czas nie był stracony, bo namierzyłem jeszcze jednego buga w kodzie obsługującym printowanie dynamicznych zmiennych przez serwer HTTP

- w pewnej sytuacji dochodziło do zarezerwowania bufora, który nigdy nie był zwalniany, przez co cały system printowania tych zmiannych przestawał działać. Nie ma to nic wspólnego z głównym problemem (komunikacja na płytce z PIC32MX512F512L+DP83848 wywala się nawet wtedy, gdy w ogóle zrezygnujemy z serwera HTTP), ale przynajmniej daje mi to jedną zmienną mniej, która mogłaby zaciemniać sprawę.

On 11.02.2024 15:33, Atlantis wrote: .

Problem ustaje po odpięciu i podpięciu rj-ki czy nie? Bo jeśli jest nadal to co za problem odpiąć ją i podpiąć pod laptopa i odpalić wiresharka? Wystarczy sprawdzić podstawowe rzeczy, czyli jak to urządzenie reaguje na arp, ping i czy nie wysyła czegoś głupiego i już coś się rozjaśni. Tak samo nie widzę problemu, żeby nie odpinać rj-ki tylko podpiąć się do switcha i sprawdzić, ewentualnie przepuścić sobie ruch przez laptopa.

Racja, można próbować w ten sposób. Mi jednak zależałoby na przechwyceniu całej sekwencji zdarzeń, która prowadzi do wystąpienia awarii.

W każdym razie obecnie mija trzecia doba, jak urządzenie pracuje i do tej pory nie zawiesiło jednocześnie wykrzaczając wszystkie urządzenia na tym samym switchu. Nie jestem pewien która zmiana za to odpowiada, bo zmieniłem kilka rzeczy: usunąłem znalezionego buga w kodzie printującym zmienne dynamiczne w plikach HTTP, ograniczyłem trochę użycie pamięci oraz zmieniłem ustawienia sterty (teraz zarówno stos TCP/IP jak i FreeRTOS korzystają z głównej sterty systemowej, bez wydzielania osobnych części).

Pojawił się za to inny błąd - mniej drastyczny, ale także uciążliwy. Mianowicie po jakimś czasie urządzenie z jakiegoś powodu traci możliwość nawiązywania połączeń jako klient. Jeśli próbuję połączyć się z jakimś stremem, proces pada na poziomie DNS-a (zwrócony zostaje błąd -5, oznaczający DNS timeout). Jeśli próbuję połączyć ze stremem, który ma w URL-u adres IP widzę następującą sekwencję zdarzeń:

- Aplikacja uzyskuje socket (a więc problemem nie jest brak dostępnych socketów TCP)

- Aplikacja z powodzeniem rozszerza bufor odbiorczy socketa do 4096 bajtów (a wiec problemem nie jest brak miejsca na stercie)

- Po pięciu sekundach socket nie jest jednak w stanie uzyskać połączenia i wołany jest timeout (który sam dodałem w swojej aplikacji)

Serwer HTTP odpalony na płytce w tym czasie działa normalnie, odpowiedzi na pingi też przychodzą. Jednak połączenia z serwerem w sieci nie da się zainicjować.

W tym wypadku problem znika po odpięciu na chwilę kabla ethernetowego. Nie trzeba nawet resetować urządzenia.

Nie ma pojęcia czy ten problem jest w jakikolwiek sposób związany z tym poprzednim, poważnym, który mi zawieszał kawałek sieci.

Czekaj co jest serwerem i co gdzie jest? Serwer http jest na tej płytce i odpowiada? W tym samym czasie chcesz się z płytki połączyć z jakimś serwerem w sieci i utyka na dns-ach? Strzelam: dostaje adres IPv6 i nie wie co z nim zrobić? Ale to strzał całkiem na ślepo i z niewyczyszczonej broni. Trzeba zrobić rozpoznanie Wiresharkiem, a jak nie, to musisz zrobić rozpoznanie bojem czyli wyrzucić sobie na terminal po kolei co się dzieje.

Na płytce jest zarówno serwer, jak i klient HTTP:

1. Serwer obsługuje prosty webowy interfejs użytkownika, za pomocą którego można m.in. sterować odtwarzaniem.
2. Klient łączy się z serwerami HTTP w sieci, które strumieniują audio stacji radiowych. Po połączeniu parsowane są nagłówki, a gdy wszystko się zgadza zaczyna ładować dane do bufora cyklicznego, skąd są przekazywane do dekodera audio (VS1003).

W momencie gdy klient przestaje się łączyć ze stacjami internetowymi, webUI nadal działa.

To byłaby dobra hipoteza, gdyby problem nie dotyczył także URL-i z adresem IP. Adresy, które wymagają zaangażowania DNS-a faktycznie utykają na tym etapie. Stacja do której dostaje się przez IP z oczywistego powodu pomija ten etap i wywala timeout nie mogąc się doczekać połączenia.

Obsługa IPv6 jest w tej chwili zupełnie wyłączona w opcjach klienta DNS.

Masz tam slota na karte sd z tym VS-em? Nie mialem czasu sie jeszzce zajac tematem ale mam pare modulow z VSami z i bez kart i sie zastanawiam czy te karty sa podpiete tak ze mozna je czytac i pisac z zewnetrznego kontrolera.

Nie mailem czasu zajrzec w schematy a te co widzialem to maja dziwnie rozmalowane polaczenia i nie do konca wiem czy sdkarta jest dostepna po spi/iic

Mam na tej płytce kartę gniazdo karty SD, ale jest podpięte do osobnej magistrali SPI. W dokumentacji VS1003 była informacja, że możliwe jest używanie kodeka na jednej magistrali z innymi urządzeniami, ale nieraz wymaga to dodatkowych kroków (np. rekonfiguracji między transmisjami). Skoro miałem taką możliwość, wolałem sobie oszczędzić kłopotów. Płytke i tak projektowałem od podstaw i nie stosowałem fabrycznych modułów.

Prawdopodobnie w przypadku tych modułów z kartą SD jest ona po prostu podłączona do tej samej magistrali SPI. Powinno się dać korzystać z obydwu urządzeń jednocześnie, ale warto najpierw wczytać się w dokumentację i zapoznać się z ograniczeniami.

Najlepiej będzie sprawdzić właśnie na schemacie. Interfejs VS10xx jest relatywnie prosty - zwykła magistrala SPI + kilka dodatkowych sygnałów sterujących. Jeśli karta współdzieli magistralę z kodekiem, to powinny być wspólne piony MISO, MOSI i SCK oraz osobny CS + ewentualnie piny charakterystyczne dla kart SD (present i write protect).

No dobra, już coś wiemy. Czyli problem nie jest z DNS, tylko wygląda to na problem z połączeniem do IP poza siecią lokalną - zgadza się? Połączenie z DNS też utyka, bo łączysz się np. do 1.1.1.1? czy za ten serwer DNS robi ruter w sieci lokalnej? I teraz dlaczego wypięcie i wpięcie rj-ki to naprawia? Obsługujesz to jakoś, tzn pobranie adresu od nowa, restart połączeń?

Bronisz się przed tym wiresharkiem, ale przynajmniej byś wiedział, czy zapytanie wychodzi prawidłowo do serwera i czy coś wraca czy nie.

Ah, sam se zrobiles. ok. Obstawiam ze bedzie sie dalo z karta gadac.

dzieki za opinie. Nie jest mi potrzebne jednoczesne korzystanie z karty przez dekoder i esp. startczy osobno.

no wlasnie adafruit pokazuje to dziwnie i nie wypatrzylem czy miso jest tylko miedzy dekoderem i karta czy do zewnatrz tez.

Właśnie kwestia polega na tym, że w tej chwili za serwer DNS robi lokalny router. Dlatego odrzuciłem hipotezę, że płytka ma problem z wykonywaniem połączeń poza sieć, bo z jej punktu widzenia serwer DNS znajduje się w sieci lokalnej. Bardziej prawdopodobne wydaje mi się, że problem był związany z inicjowaniem połączeń jako klient.

Ja bezpośrednio tego nie obsługuję, ale zapewne robi to biblioteka TCP/IP.

W każdym razie udało mi się namierzyć jeszcze jeden błąd. Zintegrowałem ze swoim kodem pewną bibliotekę przeniesioną z ze starszego projektu, który był przygotowywany jeszcze na bibliotekach MLA i bez wykorzystania FreeRTOS-a. Mojej uwadze umknęło, że w jednym miejscu zachodzi dynamiczna alokacja pamięci za pomocą standardowych funkcji malloc/free. Jak wiadomo mogą one generować problemy w wielowątkowym środowisku RTOS. Zamieniłem je na pvPortMalloc oraz vPortFree. Niedługo minie druga doba od wprowadzenia tej zmiany i nie miałem ani jednego przypadku wywalenia łączności ani zawieszenia się gniazda klienta, z którego korzysta moja aplikacja.

Z tego schematu wynika, że interfejs SPI jest wyprowadzony na złącze JP2. Po prostu nie jest to zrobione bezpośrednio, ale za pośrednictwem bufora 74HC4050. W ten sposób ludzie z Adafruit zadbali o to, żeby moduł mógł działać także z płytkami Arduino, działającymi na logice 5V. Wyjątek stanowią tutaj linie DREQ oraz MISO, które są podłączone bezpośrednio, ale w tą stronę Arduino powinno być w stanie poprawnie rozpoznać sygnały.

Aaaa teraz widze to miso. Dzieki. Wczesniej jak patrzylem to nie widzialem napisu...

W końcu znalazłem trochę czasu, żeby podłączyc płytkę przez laptopa i przechwycić pakiety. Konfiguracja wygląda następująco:

1. Stary ThinkPad x201 podpięty do switacha w miejscu, w którym oryginalnie podłączona była płytka.
2. Płytka podłączona do dodatkowej karty sieciowej na USB, za pośrednictwem scrossowanego kabla.
3. Na laptopie ustawiony bridge pomiędzy obydwiema kartami sieciowymi.
4. Ruch zbierany z karty USB za pomocą tcpdump.

Zestaw chodzi tak już tak prawie cztery doby. Przez ten czas nic nie wywaliło się ani razu. Można chyba mówić o nowym rekordzie, bo do tej pory najdłużej poprawne działanie obserwowałem przez jakieś trzy dni, a zwykle problem pojawiał się po dniu, lub nawet częściej.

Zostawię go tak jeszcze przez kilka dni, może jeszcze uda się ponownie zreplikować błąd. Co jeśli nie będzie on chciał wystąpić? Czy sam fakt poprawnego działania na takim "układzie testowym" może coś powiedzieć?

Może sam układ PHY z przyległościami to powoduje? Skoro zapala ci się ACK na stałe - to chyba on tym steruje? Podłączenie w innej konfiguracji może zmniejszyć zakłócenia albo szkodliwe potencjały i usterka może się nie objawić. Musisz testować - przynajmniej dwukrotność najdłuższego czasu między usterkami, później odtworzyć warunki ostatniej usterki i znów czekać.

Dawno temu pewna firma do pewnego swojego produktu postanowiła dodać jako opcję moduł Ethernetu. Jak postanowiono, tak zrobiono. Zaprojektowano, oprogramowano i wyprodukowano trochę modułów na RTL8019. Wszystko było mniej więcej OK. Mniej więcej, bo czasami Ethernet nie chciał działać z powodów nieznanych. Ja (softłerowiec) z pomocą kolegi hardłerowca (który projektował ten moduł jak i całe urządzenie zresztą) dostaliśmy za zadanie zdebugowanie problemu. Po jakichś dwóch czy trzech dniach walki zdesperowany odkryłem, ze kolega hardłerowiec nie przemalował z noty aplikacyjnej kości oporka 200 Ω, który znajdował się na wejściu pomiędzy pinami TPIN+ i TPIN-. Po dolutowaniu oporka problemy zniknęły jak ręką odjął. No i na produkcji musieli trochę więcej tych oporków polutować, bo to było na niedługo przed wypuszczeniem produktu na rynek i troche elektroniki firma już zdążyła naklepać. :-) Ot, tak historyjka do rozważenia.

Teoretycznie możliwe. Biorę pod uwagę opcję, że wina może leżeć po stronie jakiejś pomyłki przy budowaniu/konstruowaniu hardware'u. Jednak jest kilka "ale", które zdają się przeczyć tej hipotezie.

1. Nie przypominam sobie, żeby problem kiedykolwiek wystąpił na starej wersji oprogramowania, na którym nie było jeszcze FreeRTOS-a, a zamiast Harmony3 były użyte stare biblioteki MLA (w tym sterownik MAC/PHY i stos TCP/IP). Jak inne opcje zawiodą, to poszukam tej starej wersji softu i wykonam na nim kilkudniowe testy.
2. Istnieje nowsza wersja hardware z PIC32MZ2048. To właściwie ta sama płytka, w której podmieniony został mikrokontroler. Część z PHY właściwie nie zmieniła się ani trochę. Możliwość mapowania pinów MCU pozwoliła nieco zoptymalizować prowadzenie części ścieżek i przez to linie interfejsu RMII udało się nieznacznie skrócić, ale poza tym istotnych różnic nie ma. Ta wersja płytki działa zupełnie poprawnie.
3. Identyczny design części PHY stosowałem też w kilku projektach z STM32F1xx i STM32F4xx. Tam problem także nigdy nie wystąpił.

Jak na razie w tym "układzie testowym" urządzenie pracuje już szósty dzień i nigdy nie zaliczyło crasha. Jeszcze dam mu parę dni, ale zaczyna to wyglądać tak, jakby połączenie w tanią kartą Ethernet na USB za pomocą scrossowanego kabla było środowiskiem odpornym na ten problem. Problem występuje za to na kilku tanich switchach TP-Link 100 Mpbs oraz nieco nowszym routerze - również TP-Link, ale już z gigabitowym Ethernetem.

Nie wiem czy w ramach testu nie wyciągnę pudełka lepszego rackowego switcha (kupiony jakiś czas temu z myślą o modernizacji sieci w domu, za którą nie mogę się zabrać) i zobaczę czy nam nim problem też będzie występował.

Zaraz zaraz, działa poprawnie z tym samym softem?

Nie, nie tym samym. A przynajmniej nie do końca. Nie mogę tak po prostu przenieść projektu Harmony z PIC32MX795F512L na PIC32MZ2048. Niskopoziomowe sterowniki trzeba wygenerować jeszcze raz. Proces przenoszenia kodu wyglądał następująco:

1. Utworzyłem czysty projekt Harmony na PIC32MZ2048.
2. Zaimportowałem do niego konfigurację MHC (Microchip Harmony Configurator) z wersji na PIC32MZ2048.
3. Jeszcze raz sprawdziłem i dostosowałem niektóre ustawienia konfiguracji. Trzeba było uwzględnić różnice wynikające z użycia innych pinów GPIO czy niektórych interfejsów. Dużo więcej RAM-u pozwoliło mi też rozszerzyć nieco stertę.
4. Wygenerowałem i skompilowałem "czysty" projekt. Na tym etapie miałem już w pełni działające peryferia. Między innymi praktycznie bezobsługowo zaczęła działać łączność sieciowa.
5. Stopniowo zintegrowałem z tym czystym projektem kod mojej aplikacji, przeniesiony ze starszej wersji. W większości przypadków wystarczyło skopiować i dodać do projektu pliki z kodem źródłowym, ewentualnie powklejać gdzieniegdzie jego fragmenty, co najwyżej uważając na niektóre define'y, odnoszące się do różnic sprzętowych.

Tak więc reasumując:

- Warstwa sterowników została wygenerowana przez MHC dla nowego MCU, ale na podstawie praktycznie tej samej konfiguracji (z drobnymi zmianami).

- Warstwa aplikacji została przeniesiona ze starszej wersji ręcznie (z uwzględnieniem pewnych zmian w warstwie sprzętowej).

W ten sam sposób przeniosłem projekt także na starszą wersję płytki z ENC28J60. Płytki z PIC32MX795F512L+ENC28J60 i PIC32MZ2048+DP83848 działają w tej chwili perfekcyjnie stabilnie. Płytka z PIC32MX795F512L+DP83848 ma ten dziwny problem z okazjonalnym wywalaniem łączności na poziomie switcha.