-
1. Data: 2023-01-18 01:43:34
Temat: Problem z uruchomieniem stosu TCP/IP na PIC32MZ2048EFM100
Od: Atlantis <m...@w...pl>
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ą?
-
2. Data: 2023-01-18 10:53:37
Temat: Re: Problem z uruchomieniem stosu TCP/IP na PIC32MZ2048EFM100
Od: Marek <f...@f...com>
On Wed, 18 Jan 2023 01:43:34 +0100, Atlantis <m...@w...pl>
wrote:
> Ktoś ma jakiś pomysł gdzie szukać możliwej przycyzny i od czego
> zacząć
> debugowanie?
Od wyłączenia FTOS i zbudowania projektu bez niego. Harmony
testowałem bez FTOS i działało bez zarzutu.
--
Marek
-
3. Data: 2023-01-18 15:18:11
Temat: Re: Problem z uruchomieniem stosu TCP/IP na PIC32MZ2048EFM100
Od: Atlantis <m...@w...pl>
On 18.01.2023 10:53, Marek wrote:
> Od wyłączenia FTOS i zbudowania projektu bez niego. Harmony testowałem
> bez FTOS i działało bez zarzutu.
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).
-
4. Data: 2023-01-18 19:42:21
Temat: Re: Problem z uruchomieniem stosu TCP/IP na PIC32MZ2048EFM100
Od: Atlantis <m...@w...pl>
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.
-
5. Data: 2023-01-18 21:51:39
Temat: Re: Problem z uruchomieniem stosu TCP/IP na PIC32MZ2048EFM100
Od: Marek <f...@f...com>
On Wed, 18 Jan 2023 19:42:21 +0100, Atlantis <m...@w...pl>
wrote:
> jako 0.0.0.0. Po kilku sekundach ustawiany jest domyślny, statyczny
> IP.
A komunikacja z tym domyślnym IP działa?
--
Marek
-
6. Data: 2023-01-18 22:15:36
Temat: Re: Problem z uruchomieniem stosu TCP/IP na PIC32MZ2048EFM100
Od: Atlantis <m...@w...pl>
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.
-
7. Data: 2023-01-18 23:03:38
Temat: Re: Problem z uruchomieniem stosu TCP/IP na PIC32MZ2048EFM100
Od: Atlantis <m...@w...pl>
On 18.01.2023 21:51, Marek wrote:
> A komunikacja z tym domyślnym IP działa?
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.
-
8. Data: 2023-01-19 08:57:24
Temat: Re: Problem z uruchomieniem stosu TCP/IP na PIC32MZ2048EFM100
Od: "a...@p...onet.pl" <a...@p...onet.pl>
środa, 18 stycznia 2023 o 01:43:37 UTC+1 Atlantis napisał(a):
> - 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.
Skoro w konfiguracji nadałeś statyczny adres IP
to dlaczego oczekujesz że ma być używane DHCP ?
--
Adam
-
9. Data: 2023-01-19 10:03:56
Temat: Re: Problem z uruchomieniem stosu TCP/IP na PIC32MZ2048EFM100
Od: Atlantis <m...@w...pl>
On 19.01.2023 08:57, a...@p...onet.pl wrote:
> Skoro w konfiguracji nadałeś statyczny adres IP
> to dlaczego oczekujesz że ma być używane DHCP ?
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.
-
10. Data: 2023-01-19 18:22:11
Temat: Re: Problem z uruchomieniem stosu TCP/IP na PIC32MZ2048EFM100
Od: Atlantis <m...@w...pl>
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?