On 20.01.2023 00:09, Marek wrote:

> Zakładam, że to raczej problem software'owy. Czegoś niedoklikałeś.

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


> 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?).

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


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

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.


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

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