On 18/01/2023 01:43, Atlantis wrote:
> Ktoś ma jakiś pomysł gdzie szukać możliwej przycyzny i od czego zacząć
> debugowanie?

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 ;)

do góry

On Thu, 19 Jan 2023 18:22:11 +0100, Atlantis <m...@w...pl>
wrote:
> 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?

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.

--
Marek

do góry

On 19.01.2023 20:49, Marek wrote:

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

do góry

On Thu, 19 Jan 2023 21:18:03 +0100, Atlantis <m...@w...pl>
wrote:
> Tylko co mogłoby być powodem takiego stanu rzeczy?

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?

--
Marek

do góry

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

do góry

W dniu 19.01.2023 o 18:22, Atlantis pisze:
> 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?

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

do góry

On 19.01.2023 20:46, heby wrote:

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

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

do góry

On 21.01.2023 06:38, titanus wrote:

> Swoją drogą "ręcznie robiona" płytka do komunikacji na 100Mbit?

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.

do góry

On Sat, 21 Jan 2023 06:38:12 +0100 (GMT+01:00), titanus
<t...@g...kom> wrote:
> Wasze posty czyta się jak dobry kryminał Agaty Cristii ;-)

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

--
Marek

do góry

W dniu 21.01.2023 o 06:38, titanus pisze:
[...]
> Szapoba.
>
> Wasze posty czyta się jak dobry kryminał Agaty Cristii ;-)

Nudny ten kryminał. Wszystkie odcinki takie same: wiele hipotez, a w
końcu okazuje się, że Autor spieprzył jakąś prostą rzecz. Szkoda czasu
na czytanie.

P.P.

do góry