PIC32MX795F512 z DP83848: Zawieszanie się Ethernetu i wpływ na sieć lokalną

Mon Feb 05, 2024 9:34 pm   

Od jakiegoś czasu rozwijam pewien projekt oparty na PIC32MX795F512,
który korzysta z wbudowanego w ten mikrokontroler sterownika MAC, z
zewnętrznym układem PHY (DP83848). W wielkim skrócie jest to stacjonarny
odtwarzacz plików z audio, z funkcją odbierania streamów po HTTP.

Firmware napisałem za pomocą bibliotek Harmony3 od Microchipa oraz
FreeRTOS. O ile sama aplikacja działa całkiem nieźle, to nie mogę sobie
poradzić z pewną uciążliwą przypadłością - co jakiś czas łączność
sieciowa zawiesza się. I to w tak dziwny sposób, że zawias wywala
łączność we wszystkich urządzeniach podłączonych do tego samego switcha.
Jestem pewien, że przyczyną jest moja płytka, bo prowadziłem testy z
kilkoma różnymi switchami i za każdym razem wygląda to dokładnie tak samo.

Objawy są następujące:
- W pewnym momencie urządzenie traci łączność z siecią. Przestaje
odpowiadać na pingi, nie można się dostać do prostego serwera HTTP
(obsługującego webUI), a socket odbierający w danym momencie stream
audio przestaje otrzymywać dane.
- Co więcej, w tym samym momencie przestaje działać łączność sieciowa na
wszystkich urządzeniach podpiętych do tego samego switcha.
- Dioda ACT na gniazdku ethernetowym mojej płytki świeci ciągle, zamiast
migać w rytm przesyłanych pakietów.
- Co ciekawe problem często nie ustępuje po soft-resecie albo nawet
pełnym power cycle - po ponownym podpięciu zasilania dioda ACT błyśnie
parę razy, a w chwilę później znów zaczyna świecić. W takiej sytuacji
trzeba chwilę odczekać przed ponownym podłączeniem zasilania. Takie
zachowanie nie występuje jednak zawsze. Często zwykły, programowy reset
wystarcza w zupełności.
- Częstotliwość występowania problemu jest różna. Czasem występuje raz
na kilka dni, czasem kilka razy jednego dnia.

Co sprawdziłem do tej pory:
- Włączyłem opcję raportowania zajętości tej części sterty, która jest
wydzielona na użytek stosu TCP/IP. Nie zauważyłem, żeby problem
korelował z brakami miejsca na stercie. Zwiększenie rozmiaru sterty w
niczym nie rozwiązuje problem.
- Próbowałem podnieść rozmiary stosu dla tasków FreeRTOS-a związanych z
TCP/IP, ale nie przyniosło to żadnego efektu.
- Próbowałem manipulować rozmiarami rozmaitych buforów wykorzystywanych
przez TCP/IP, żeby oszczędzić pamięć. W niczym to nie pomogło.

Dodatkowo: jakiś czas temu opracowałem nową wersję płytki do tego
urządzenia, z dużo mocniejszym MCU (PIC32MZ2048). Tam nie zauważyłem
jeszcze nigdy podobnego objawu. Może jest to związane z większą ilością
zasobów sprzętowych - samo procesor jest znacznie szybszy, mogłem też
ustawić większe rozmiary sterty oraz jej części przeznaczonej dla zadań
TCP/IP.

Można by co prawda próbować zrzucić winę na fakt, że urządzenie jest
zbudowane na samodzielnie trawionej (dwustronnej) płytce. Jednak poza
tymi dziwnymi zawiasami nie występują absolutnie żadne problemy z
łącznością, nie zauważyłem ani jednego zgubionego pakietu podczas
normalnej pracy. Poza tym zbudowałem jeszcze kilka innych urządzeń z
DP83848 (w tym również z mikrokontrolerami STM32) na samodzielnie
trawionych płytkach i nigdy nie miałem z tego tytułu żadnych problemów.

Ktoś ma jakiś pomysł co do możliwej przyczyny? Szczególnie zastanawia
mnie to wywalanie łączności na wszystkich urządzeniach podpiętych do
tego switcha. W wolnej chwili spróbuję podpiąć Wiresharka i zobaczyć co
tak właściwie się wtedy dzieje, jednak może ktoś z was zetknął się z
czymś takim, albo przynajmniej ma pomysł jak to dalej debugować?

Mon Feb 05, 2024 9:57 pm   

On 5.02.2024 20:34, Atlantis wrote:


Koniecznie odpal Wiresharka i zobacz co się dzieje.
Jak kładzie całą sieć, to możliwe, że odpowiada na każdy pakiet TCP -
tak jakby nie filtruje własnego MAC-a - każdy traktuje jak swój i w
rezultacie switch wszystkie pakiety kieruje do niego.
Drugi problem może być z samym układem PHY - wtedy prawdopodobnie nic
nie zobaczysz.
Z tym pierwszym przypadkiem spotkałem się OIDP tylko raz i co ciekawe
tak się zachowywała końcówka GPON operatora.
Z drugim przypadkiem spotkałem się wielokrotnie - zwykle był to switch z
kategorii mały, tani 4-ro, 8-mio portowy, ale też pamiętam Mikrotika i
mediakonwerter MOXA - tak że nie ma reguły.
Na Wiresharku nic nie widać - po prostu z czasem pakiety nie dochodzą i
tyle. Po odłączeniu pacjenta od sieci sytuacja wraca do normy, ale
dopiero po pewnym czasie. Tak samo po podłączeniu problem zaczyna się
robić z dużym opóźnieniem, tak że w rozległej sieci ciężko coś takiego
namierzyć.

--
Mirek.

Mon Feb 05, 2024 11:09 pm   

On Mon, 5 Feb 2024 20:57:52 +0100, Mirek <mirek@null.dev> wrote:

Mógłbyś to precyzyjniej opisać? Przecież to switch decyduje co komu
wg tablicy, który MAC "widać" na danym porcie. Urządzenie musiałoby
odpowiadać na każdy whohas o dowolny IP co jest nieprawdopodobne w
stosie mchp.
Jak przez mgłę kojarzę bardzo podobny przypadek jaki miałem z tym
stosem (nagła niewidzialność innych urządzeń) ale niestety nie mogę
sobie przypomnieć wniosków z diagnostyki.

--
Marek

Mon Feb 05, 2024 11:13 pm   

On Mon, 5 Feb 2024 20:34:17 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Rozumiem, że aplikacja działa nadal podczas zwieszki sieciowej, nie
wiesza się, tylko sieć nie działa? Czy możesz periodycznie na konsole
debug wyrzucać bieżącą konfigurację sieci (przydzielony IP, maska)
oraz MAC? Czy czasem ona się nie zmienia po wystąpieniu zwieszki?

--
Marek

Tue Feb 06, 2024 9:58 am   

On 5.02.2024 22:13, Marek wrote:


Tak, mogę. Zapomniałem właśnie o tym wspomnieć. Konfiguracja po stronie
urządzenia nie zmienia się. Komenda "netinfo" pokazuje poprawną
konfigurację. Adresy IP i MAC nie zmieniają się, system twierdzi, że
interfejs sieciowy jest w stanie "up". Komenda "macinfo" pokazuje tylko
tyle, że licznik odebranych/wysłanych pakietów w pewnym momencie
przestaje się zwiększać.

Przyszedł mi do głowy jeszcze pomysł - uruchomiłem urządzenie na
minimalnej konfiguracji. Ro znaczy zostawiłem jedynie obsługę
podstawowego stosu z TCP/IP/UDP/ARP/DHCP/DNS. Wywaliłem NBNS, HTTP i
biblioteki kryptograficzne związane z WOLFSSL (nawet jeśli się z niego
nie korzysta, autorzy bibliotek zalecają dodanie ich do projektu, ze
względu na lepsza obsługę RNG, można to jednak wyłączyć).

Jak na razie projekt się nie zawiesił, ale jak mówiłem - niekiedy działo
się to po kilku dniach. Jeśli do tego nie dojdzie, będę powoli dodawał
kolejne usunięte komponenty. Na pewno nie chciałbym rezygnować z HTTP,
bo webUI było bardzo wygodną funkcjonalnością. Z SSL mogę na dobrą
sprawę zrezygnować, bo na chwilę obecną i tak nie zaimplmenetowałem
funkcji odbioru streamów HTTPS.

Tue Feb 06, 2024 7:46 pm   

Miałem kiedyś problem taki , że na mierniku agilent 34461A podpiętego do
LANu z inetem wywalało okienko z błędem. Chamski WEB error.

Wywalał się tylko wtedy gdy do sieci wpięty był modem/router LTE od
T-Mobila i jego implementacja IPv6.

kupiłem nawet na okazję debugowania tego switcha z mirroringiem portów.
Złapałem nawet całą sytuację na wiresharku i wysłałem do Agilenta.

Ale mieli na to wyjebane odpisując , że przy kolejnej rewizji softu zobaczą.

Może zatem u Ciebie coś podobnego. Jakaś dziwna jumbo ramka wypiernicza
phy lub maca. Albo jakiś inny problem się nakłada na brak odporności.

Powodzenia. Żeby cokolwiek zobaczyć trzebaby mieć switcha z mirrorem i
na tym porcie nagrywać.

Pozdrawiam
Adam Górski

Tue Feb 06, 2024 8:09 pm   

On Tue, 6 Feb 2024 18:46:58 +0100, Adam
Górski<gorskia_i_tak_tego_nie_czytam_@wp.pl> wrote:

Co ma warstwa 7 OSI do warstwy 4?
Ewidentnie problem jest raczej poniżej warstwy 5.

--
Marek

Tue Feb 06, 2024 8:57 pm   

On 5.02.2024 22:09, Marek wrote:


Nieprawdopodobne jest to, co napisałem, czyli że odpowiada na każdy MAC
- żeby to zadziałało, to musiałby odpowiedzieć pakietem z takim samym
MAC-iem źródłowym jak dostał docelowy żeby zmylić switcha.
Bardziej możliwe jest, że pamięć mnie zawodzi - faktycznie chyba
odpowiadał na każde who has, czyli brał na siebie wszystkie IP. Szkoda,
że nie zrobiłem wtedy zrzutu z wiresharka. Zwykle przy takich akcjach
jest wszystko na wczoraj i nie ma czasu na dociekanie co się dzieje.
Sukcesem jest znalezienie wadliwego urządzenia, a co ono tam wyprawia to
już nie ma znaczenia.

--
Mirek.

Tue Feb 06, 2024 9:03 pm   

No cóż... Uruchomiłem bardziej minimalistyczną wersję stosu, z wywalona
obsługą HTTP, NBNS oraz WolfSSL (z towarzyszącymi mu bibliotekami).
Od tamtego momentu problem wystąpił już jeden raz.
Przyszedł mi do głowy jeszcze jeden pomysł. Płytka podczas testów
właściwie non-stop jest pingowana przez peceta. Zobaczę jak urządzenie
się zachowa, jeśli tego zaniecham na jakiś czas.

Przypomniałem sobie jeszcze, że przez pewien czas (na samym początku)
urządzenie pracowało na firmware napisanym za pomocą starych bibliotek
MLA. Dopiero później przeniosłem je na Harmony. Nie przypominam sobie
żeby podczas testów na starym FW wystąpił taki błąd. To zmniejsza
prawdopodobieństwo hipotezy, że winę ponosi problem sprzętowy.

Tue Feb 06, 2024 11:16 pm   

Ty mi powiedz.

Pozdrawiam

Adam Górski

Wed Feb 07, 2024 1:25 am   

On Tue, 6 Feb 2024 20:03:56 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

W odpowiedzi komu innemu pisałem że na 99% kilka lat temu zetknąłem
się z tym samym problemem na pic32. Tylko niestety nie pamiętam,
który to był stos mla czy Harmony bo w tamtym czasie używałem oba.
Pamiętam blokadę "ruchu" na switchu i palącą się na stałe diodę ACT
na gnieździe eth z pic32. Jak tylko przypomnę sobie co to było dam
znać.

--
Marek

Wed Feb 07, 2024 10:51 am   

On 7.02.2024 00:25, Marek wrote:


Gdyby udało się przypomnieć co to powodowało, to byłbym bardzo wdzięczny
za tę informację.
Na razie sprawdzam hipotezę na temat wpływu pingowania płytki na to
zachowanie. Póki co od wczoraj się nie zawiesiła, ale to jeszcze niczego
nie przesądza, bo nieraz problem występował dopiero po kilku dniach.

Thu Feb 08, 2024 7:45 am   

On Wed, 7 Feb 2024 09:51:17 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Gdy jest zwieszka i wyjmiesz wtyk eth z płytki ruch na switchu się
przywraca? Czy po włożeniu wtyczki z powrotem (bez resetowania
płytki) od razu diioda ACT zapala się na stałe i ruch ponownie
zanika?

--
Marek

Thu Feb 08, 2024 9:18 am   

On 8.02.2024 07:41, Marek wrote:


Tak. Komputer podłączony do tego samego switcha odzyskuje łączność
natychmiast po wyjęciu kabla Ethernet z mojej płytki. Jeśli podłączę
kabel ponownie, problem powraca - dioda ACT znów zaczyna świecić cały
czas, chociaż komputer traci łączność z drobnym opóźnieniem.

Problem powrócił dzisiaj, czyli jednak wiadomo, że to nie pingowanie
płytki było przyczyną.


Tak. Po włożeniu kabla bez resetu dioda zapala się cały czas i problem
pojawia się natychmiast.

Było też kilka sytuacji, kiedy problem pojawiał się ponownie po resecie,
ale wtedy dioda zdążyła jeszcze mignąć kilka razy przed zapaleniem się
na stałe.

Thu Feb 08, 2024 10:35 am   

Przyszedł mi jeszcze do głowy pomysł, że może dochodzić do zagłodzenia
któregoś z tasków odpowiedzialnych za łączność sieciową. Sprawdziłem i
faktycznie wszystkie one mają priorytet 1 - taki sam, jak task w którym
wykonuje się mój kod. Zmieniłem go na 2 i zobaczę jak teraz zachowa się
urządzenie.