On 23.02.2024 16:33, JDX wrote:

> 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ł.