Problem z uruchomieniem stosu TCP/IP na PIC32MZ2048EFM100

Wed Jan 18, 2023 1:43 am   

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ą?

Wed Jan 18, 2023 1:43 am   

Atlantis <marekw1986NOSPAM_at_wp.pl> Wrote in message:r

Szapoba.

Wasze posty czyta się jak dobry kryminał Agaty Cristii ;-)

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

--
Pozdrawiam - titanus

Wed Jan 18, 2023 10:53 am   

On Wed, 18 Jan 2023 01:43:34 +0100, Atlantis <marekw1986NOSPAM_at_wp.pl>
wrote:

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

--
Marek

Wed Jan 18, 2023 3:18 pm   

On 18.01.2023 10:53, Marek wrote:


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

Wed Jan 18, 2023 7:42 pm   

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
3. 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".
4. 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).
5. 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.

Wed Jan 18, 2023 9:51 pm   

On Wed, 18 Jan 2023 19:42:21 +0100, Atlantis <marekw1986NOSPAM_at_wp.pl>
wrote:

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

--
Marek

Wed Jan 18, 2023 10:15 pm   

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.

Wed Jan 18, 2023 11:03 pm   

On 18.01.2023 21:51, Marek wrote:


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.

Thu Jan 19, 2023 9:57 am   

ś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 ?

--
Adam

Thu Jan 19, 2023 10:03 am   

On 19.01.2023 08:57, ada...@poczta.onet.pl wrote:


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.

Thu Jan 19, 2023 6:22 pm   

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?

Thu Jan 19, 2023 8:46 pm   

On 18/01/2023 01:43, Atlantis wrote:

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

Thu Jan 19, 2023 8:49 pm   

On Thu, 19 Jan 2023 18:22:11 +0100, Atlantis <marekw1986NOSPAM_at_wp.pl>
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.

--
Marek

Thu Jan 19, 2023 9:18 pm   

On 19.01.2023 20:49, Marek wrote:


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

Fri Jan 20, 2023 12:09 am   

On Thu, 19 Jan 2023 21:18:03 +0100, Atlantis <marekw1986NOSPAM_at_wp.pl>
wrote:

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