Problem z uruchomieniem stosu TCP/IP na PIC32MZ2048EFM100

Złożyłem ostatnio płytkę z mikrokontrolerem PIC32MZ2048EFM100. Na płytce znajduje się też układ Ethernet (PHY) DP83848, korzystający z wbudowanego w MCU modułu MAC. PCB zaprojektowane i wykonane w domowych warunkach, a więc nie byłem w stanie poprowadzić interfejsu RMII zgodnie ze sztuką, jednak starałem się aby połączenia były możliwie krótkie. Zresztą identyczny rozwiązanie zastosowałem już w kilku innych projektach i Ethernet działał zawsze bez najmniejszych problemów. Omawiana płytka jest zresztą modyfikacją wcześniejszego projektu na PIC32MX795F512L, w stosunku do którego jedyną zmianą jest zastosowanie nowszego MCU.

Dzisiaj zabrałem się za uruchamianie części sofware'owej. O ile stara wersja działała na leciwych bibliotekach MLA od Microchipa, to tutaj postanowiłem zastosować nowe środowisko Harmony v3, w którym właściwie cała konfigurację można sobie wyklikać.

Na chwilę obecną sytuacja wygląda następująco:

- Udało mi się bez większych problemów wygenerować i skompilować konfigurację opartą na FreeRTOS-ie. Kod umieszczony w głównym tasku wykonuje się.

- Inicjacja stosu TCP/IP przechodzi prawidłowo.

- Na początku na skutek kilku błędów w konfiguracji system wywalał się na konfiguracji DP83848, a więc wygląda na to, że PHY jest widziane przez mikrokontroler i mamy komunikację po magistrali RMII.

- Aktywowałem w Harmony moduł konsoli do debugowania, dzięki czemu mogę przez port szeregowy wywoływać komendy pozwalające na sprawdzanie stanu urządzenia. Jest m.in. komenda netinfo pozwalająca sprawdzić konfigurację sieci.

- Wspomniane komenda netinfo twierdzi, że płytka posiada statyczny adres IP, nadany w konfiguracji. Twierdzi również, że interfejs jest aktywny, a DHCP działa.

- Płytki nie widzę jednak w interfejsie routera, a w logach serwera DHCP nie ma śladu po próbie uzyskania adresu przez urządzenie o tym MAC-u.

- Nie jestem w stanie także spingowac adresu IP płytki. Serwer ICMP został aktywowany w konfiguracji Harmony.

- Jeśli uruchomię płytkę z odłączonym kablem ethernetowyn, adresy IP w konfiguracji widnieją jako 0.0.0.0, a interfejs ma status "down".

- Jeśli próbuję podłączać albo odłączać kabel ethernetowy podczas pracy płytki, ta się zawiesza (przestaje działać nawet ta konsola do debugowania).

Ktoś ma jakiś pomysł gdzie szukać możliwej przycyzny i od czego zacząć debugowanie? Takie obsjawy wskazują raczej na kwestię sprzętową czy programową?

Od wyłączenia FTOS i zbudowania projektu bez niego. Harmony testowałem bez FTOS i działało bez zarzutu.

Doszedłem do podobnego wniosku po rzuceniu okiem jeszcze raz na konfigurację. Widzę, że nie tylko stos dostaje swój własny task, ale także m.in. sterownik MIIM. Wieczorem przyjrzę się temu jeszcze raz, ale zacznę od zwiększenia przydziału pamięci przeznaczonej na stosy dla tasków. Pamiętam, że nie tak dawno miałem nieco podobny problem z siecią na STM32 i tam też winę ponosił za mały stos w tasku lwIP. Tam co prawda MCU był dużo mniejszy, ale możliwe, że przeoczyłem jakieś ustawienie, a domyślne wartości się nie sprawdzają.

Praca bez RTOS w Harmony v3 ponoć jest możliwa, ale jego wyłączenie może być nietrywialne - konfigurator upiera się, żeby dodać ten komponent po aktywowaniu trochę bardziej zaawansowanych bibliotek (jak stos TCP/IP właśnie).

Ok. Łączność z siecią nadal nie działa, ale udało mi się pchnąć kilka rzeczy do przodu.

Po pierwsze poeksperymentowałem trochę z ustawieniami pamięci w u stawieniach FreeRTOS. Zmieniłem model z heap_1 na heap_3, zwiększyłem rozmiar systemowej sterty do 96kB oraz zwiększyłem rozmiary stosów sterownika MIIM oraz samego stosu TCP/IP (z 4kB do 8kB). Do 4kB podniosłem rozmiar stosu systemowej konsoli. Ta ostatnia zmiana okazała się być najbardziej przydatna, bo system przestał się wywalać przy próbie skorzystania z niektórych komend, np. macinfo.

Co udało mi się na chwilę obecną ustalić:

1. Zaraz po restarcie netinfo pokazuje adresy, maskę podsieci i bramkę jako 0.0.0.0. Po kilku sekundach ustawiany jest domyślny, statyczny IP.
2. Komenda macinfo zwraca następujące dane: Receive Statistics nRxOkPackets: 0 nRxPendBuffers: 0 nRxSchedBuffers: 4 nRxErrorPackets: 0 nRxFragmentErrors: 0 nRxBuffNotAvailable: 0

Transmit Statistics nTxOkPackets: 0 nTxPendBuffers: 0 nTxErrorPackets: 0 nTxQueueFull: 0

Interface: PIC32INT Hardware Register Status FRMTXOK : 0x0 FRMRXOK : 0x0 RXBUFCNT: 0x0 RXOVFLOW: 0x0 FCSERROR: 0x0 ALGNERR : 0x0 SCOLFRM : 0x0 MCOLFRM : 0x0

1. Płytka przestała się zawieszać przy odłączeniu kabla. Komenda netinfo reaguje na jego odłączenie, aktualizując status na "Link is DOWN/Status: Not Ready". Ponowne podłączenie przywraca "Link is UP/Status: Ready".
2. Klient DHCP niby działa, ale ale adres IP nie jest pobierany za jego pomocą. Przy pomocy konsoli jestem w stanie klienta włączyc i wyłączyć, a także poprosić o renew albo info (zwraca fail).
3. Aktywowałem możliwość debugowania sterownika MIIM. Mogę teraz m.in. odczytywać zawartość rejestrów DP83848. Komunikacja najwyraźniej działa, bo jeśli podam prawidłowy adres (0x01) otrzymuję sensownie wyglądające wartości, ale po podaniu błednego, leci seria 0xffff.

Wychodzi więc na to, że kontroler MAC działa i komunikuje się z PHY. Podłączenie kabla ethernetowego jest wykrywane. Stos TCP/IP jest inicjowany. Tylko z jakiegoś powodu nie mam łączności z innymi urządzeniami w sieci, nie działa DHCP i płytka nie odpowiada na pingi.

Zapomniałem też wspomnieć, że diody na gniazdku RJ-45 działają prawidłowo. Po podpięciu kabla LINK świeci się, a ACT błyska tak, jakby faktycznie były odbierane jakieś pakiety.

A komunikacja z tym domyślnym IP działa?

Ok, znalazłem pierwszy poważniejszy bład. Pin EREFCLK nie był prawidłowo skonfigurowany, przez co nie mogła się prawidłowo odbywać transmisja danych, chociaż sam układ PHY był widziany.

Naprawa tego błedu trochę zmieniła sytuację, choć nadal jest dziwnie:

- DHCP ciągle nie działa

- Statystyki w macinfo pokazują, że jakieś pakiety są wysyłane i odbierane. Wskazuje na to też zmieniająca się zawartość rejestrów FRMTXOK i FRMRXOK. Wartość nTxErrorPackets i nRxErrorPackets jest cały czas na 0.s

- Wartość nRxOkPackets i nTxOkPackets stopniowo rośnie. Rośnie szybciej, jeśli próbuję pingować płytkę. Tak, jakby faktycznie pingi docierały i były odsyłane. Tylko komputer po drugiej stronie tego nie widzi.

Nie. Nie mogę go nawet spingować, chociaż sterownik MAC (po usunięciu innego błedu z konfiguracją jednej z linii interfejsu RMII) pokazuje, coraz większa liczbę wysłanych i odebranych pakietów. Liczba błednych pakietów jest cały czas na 0.

środa, 18 stycznia 2023 o 01:43:37 UTC+1 Atlantis napisał(a):

Skoro w konfiguracji nadałeś statyczny adres IP to dlaczego oczekujesz że ma być używane DHCP ?

Bo mam włączone DHCP? Statycznego adresu w konfiguracji nie da się nie podać. Mógłbym tam co najwyżej umieścić wartości w stylu 0.0.0.0 (czego zresztą próbowałem), ale włączenie DHCP nie usuwa tego fragmenty konfiguracji. Jeśli dobrze rozumiem, to ten statyczny adres będzie używany np. wtedy, gdy nie uda się uzyskać dynamicznie przyznawanego adresu. Przynajmniej tak to działało jeszcze w starym stosie z bibliotek MLA od Microchipa. Zakładam wiec, że w Harmony jest dokładnie tak samo.

Ok. Usunąłem w MHC całą konfigurację wszystkiego związanego z siecią, zbudowałem ją od nowa i po raz kolejny wygenerowałem kod. Problem powtarza się w dokładnie taki sam sposób, a objawy są dziwne.

Podsumowując:

- Stos TCP/IP inicjuje się prawidłowo, podobnie jak sterownik MAC/PHY.

- Sterownik MIM jest w stanie czytać rejestry układu PHY (DP83848).

- Pomimo umieszczenia w projekcie serwera ICMP, nie jestem w stanie pingować płytki. Komputer nie otrzymuje odpowiedzi.

- Nie działa właściwie żadna łączność. Płytka nie otrzymuje adresu z DHCP (w logach routera nie widać w ogóle, żeby była podejmowana taka próba). Nie jestem w stanie przeprowadzić kwerendy za pomocą klienta DNS. Przeglądarka WWW nie widzi serwera HTTP odpalonego na płytce.

- Sterownik MAC rejestruje statystyki odbieranych i wysyłanych pakietów. Wartości te narastają szybciej, jeśli podejmowana jest próba pingowania płytki.

- Stos reaguje na odpinanie i podłączanie kabla Ethernet, dostosowując odpowiednio status połączenia wyświetlany przez narzędzie netinfo.

- Na liście ARP urządzenia widoczne są adresy MAC i IP rzeczywistych urządzeń z tej sieci, w tym routera oraz komputerów, z których wysyłane były pingi.

Czyli wygląda na to, że jakaś komunikacja jest. Tylko jakby w jedną stronę - płytka coś odbiera (a konkretnie pakiety ARP z informacjami na temat urządzeń w sieci) ale nie jest w stanie wysyłać (nie widać odpowiedzi na pingi ani prośby o przyznanie konfiguracji przez DHCP).

Zaczynam się zastanawiać czy gdzieś nie ma problemu sprzętowego. Ktoś ma jakiś pomysł co do możliwej przyczyny, która mogłaby powodować tak dziwne działanie Ethernetu?

Od zainstalowania Wiresharka.

Jesteś w stanie, tym frameworku, wysyłać pakiety UDP?

Więc napisz kawałek kodu, który wyśle dowolną ramkę UDP na adres rozgłoszeniowy (ff:ff:ff:ff) i obserwuj, co widzi Wireshark.

Jeszcze lepiej, jesli możesz tam wysyłać gołe ramki ethernetowe. Zrób taką, z dowolną zawartością i też wyślij na rozgłoszeniowy adres ethernetu. Wireshark ją zobaczy.

Ogólnie zacznij od podpięcia Wiresharka do tego setupu i patrz w nim co lata po drucie.

Nie wpinaj tego do routera, pod żanym pozorem, pojawią się miliony ramek, ciezko to będzie odfiltrować.

Wepnij kablem ethernet urządzenie<->PC, odpal wiresharka i zacznij generować gołe ramki rozgłoszeniowe.

I najlepiej nie robić tego na windowsie. Windows w taki ethernet będzie pakować swoje ramki rózne. Przynajmniej przełacz windowsa na statyczny numer IP na tym interfejsie, żeby nie szukał serwera DHCP i nie generował pustego ruchu. Ma być cisza na ethernecie a to pod windowsem ciężko zrobić.

PS. Stawiam na przepełnienie stosu ;) W ciemno ;)

To trochę wyglada na transmisję z uszkodzonym (nieprawidłowe crc) payloadem w IP/MAC. Liczniki się zwiększają, pakiety wychodzą ale komputer je po prostu ignoruje dlatego "nie widzisz" komunikacji.

Tylko co mogłoby być powodem takiego stanu rzeczy? Najprościej oczywiście byłoby zwalić winę na interfejs RMII. Płytka jest robiona domowa metodą, wiec nie mogłem prowadzić linii w najbardziej własciwy sposób (meandry, wyrównywanie długości ścieżek). Jednak ten sam projekt płytki przetestowałem już w kilku projektach na PIC32 i STM32. W każdym działało bez najmniejszego problemu.

Ta konkretna płytka jest modyfikacją starszego projektu na PIC32MX795F512L. Niektóre ścieżki RMII mogły się symbolicznie wydłużyć w związku z tym, że nowy układ ma niektóre linie w trochę innych miejscach oraz jest w obudowie 14x14 (zamiast 12x12).

Wcześniejsze projekty działały perfekcyjnie - nie było żadnych widocznych błedów transmisji, żadnych zgubionych pingów itp. Cość ciężko mi sobie wyobrazić, żeby minimalne wydłużenie albo przesunięcie płytki spowodowało sytuację kiedy nie działa nic i nie dochodzą żadne pingi.

Z drugiej strony jednak coś do tej płytki dolatuje, bo tabela ARP zostaje uzupełniona właściwymi adresami IP i MAC...

Zakładam, że to raczej problem software'owy. Czegoś niedoklikałeś. Jest jakiś problem powodujący jednostronną komunikację, jeśli płytka sugeruje (na podstawie liczników) że wysyła pakiety a nie widać ich u odbiorcy to albo fizycznie nie wychodzą z interfejsu eth albo wychodzą ale są popsute, przez to ignorowane lub dropowane po drodze (mądry switch?). Zweryfikuj wpierw czy prawidłowo na pewno odbiera UDP w warstwie aplikacji, jakiś prosty klient na szybko dołącz. Możesz też pokazać jak Ci się wygenerował system_config.h porównam ze swoim.

A możesz zbudować hexa dla 32MZ2064DAH169 + MIIM i wysłać mi na maila?

Mam właśnie taką nadzieję. Robiłem już wizualną inspekcję okolic DP83848 oraz linii interfejsu RMII, ale nie widzę niczego podejrzanego. Zastanawiam się jak wyglądałoby zachowanie układu, gdyby był problem na liniach danych TX0 i TX1 interfejsu RMII, ale wtedy chyba byłby w ogóle problem z inicjalizacją sterownika i czytaniem zawartości rejestrów PHY. A to jestem w stanie zrobić.

Żadnego mądrego switcha po drodze nie było. Jeden z pingujących komputerów jest podłaczony do tego samego prostego switcha od TP-Linka, co testowana płytka. Drugi był podłączony do innego portu Ethernet domowego routera. Może router mógłby mieć jakąś funkcję dropowania uszkodzonych pakietów, ale tego prostego switcha o to nie podejrzewam.

Ok. Chyba nawet można w systemowej konsoli aktywować komendę do wysyłania pakietów UDP i TCP. Jest też klient ICMP. Płytka też nie jest w stanie niczego pingować, za wyjątkiem samej siebie.

Ok, spróbuję z tym poeksperymentować dzisiaj albo przez weekend. Podepnę też Wiresharka i zobaczę czy coś w ogóle widać.

W dniu 19.01.2023 o 18:22, Atlantis pisze:

Jeżeli MDIO/MDC komunikacja działa to co zostaje ?

TX_CLK,TX_EN,TXD[3..0]

Czy widać tam cokolwiek ?

Skoro to PCB ręcznej roboty to może sprawdź połączenia i zwarcia. Zwłaszcza pomiędzy TXD[3..0]

Ewentualnie jeszcze to samo po stronie RJ45

Bywało i tak że się jeden pin z RJ45 nie kontaktował.

Na stronie 81 dataszyta masz wygląd przebiegów na kablu eth.

Poza tym to już tylko kwarc zostaje.

BTW Wygląda to bardziej właśnie na problem sprzętowy niż softwarowy.

Pozdrawiam

Adam Górski

A jednak był sprzętowy. ;) Krótko mówiąc - udało się! W akcie desperacji jeszcze raz zabrałem się za inspekcję wizualną za pomocą luby, nie znajdując żadnego problemu. Zacząłem więc przedzwaniać kolejne linie multimetrem, szukając zwarć do masy i sąsiednich ścieżek, oraz testując ciągłość linii. W pewnym momencie trafiłem na dziwną sytuację. Ścieżka z stgnałem ETXEN "cała", a nie przewodzi. Znalazłem miejsce w którym miała być przerwa i dopiero po chwili przyglądając się ju przez najlepszą lupę znalazłem przerwę, mniejszą od grubości ludzkiego włosa. Mostek z cyny i kawałka cienkiego drucika załatwił sprawę. Wszystko działa. Płytka pobiera adres z DHCP i odpowiada na pingi, nawet serwer http ruszył z miejsca. :)

Jak najbardziej osiągalne. Trzeba tylko nauczyć się robić dwustronne płytki z przelotkami i relatywnie cienkimi ścieżkami (8-12 milsów). Najbardziej uciążliwą częścią jest wiercenie otworów w taki sposób, żeby po obydwu stronach trafić we właściwym miejscu. :)

Generalnie długości linii szczególnie pilnuję w przypadku wejścia i wyjścia różnicowego PHY. Staram się, żeby układ był tak blisko gniazdka, jak to tylko możliwe, a do tego stosuję meandrowanie, żeby wyrównać długości obydwu ścieżek w parze. Do tego oczywiście wszystko zalane masą.

Miałem dylemat w przypadku połączenia pomiędzy ETH i PHY. Tutaj są dwie opcje - albo interfejs MII (częstotliwość 25 MHz, ale więcej ścieżek do poprowadzenia) albo RMII (50 MHz, ale mniej ścieżek).

Finalnie wybrałem tę drugą opcję. Niestety z uwagi na ograniczenia domowej technologii produkcji płytek (np. brak możliwości wykonania przelotek pod układami albo zrobienia dostatecznie cienkich ścieżek) nie byłem w stanie sensownie poprowadzić linii tego interfejsu w zgodzie z najlepszymi zasadami (meandry, izolowanie poszczególnych ścieżek masą), jednocześnie trzymając obydwa układy blisko siebie. Postanowiłem więc, że skupię się na tym, żeby połączenia były możliwe jak najkrótsze. Trochę łatwiej było to zrobić w przypadków STM32 niż PIC32, bo wszystkie linie interfejsu RMII zgrupowane są po jednej stronie układu.

Testu EMC to oczywiście nie przejdzie, jednak działa. Połączenie jest stabilne, a na kilkadziesiąt tysięcy wysłanych pingów nie ginie ani jeden. Generalnie spodziewałem się, że to ma szansę działać, bo widziałem eksperymenty ludzi podpinających do zestawu testowego PHY w formie modułu, na kabelkach. ;)

Aha. Oczywiście to, że Ethernet wynegocjuje z infrastrukturą zestawienie połączenia 100Mbps nie oznacza, że będziemy mieć takie transfery. ;) Tutaj ograniczeniem będzie wydajność procesora i przepustowość innych peryferiów.

To byłby ciekawy wątek, gdyby nie jego autor sprowadził go w wielkim finale do poziomu problemu klasy "niepodłączony kabelek".