PIC32MX795F512 + DP83848: Zawieszanie się Ethernetu

[Atlantis]

Od jakiegoś czasu rozwijam pewien projekt oparty na PIC32MX795F512,
który korzysta z wbudowanego w ten mikrokontroler sterownika MAC, z
zewnętrznym układem PHY (DP83848). W wielkim skrócie jest to stacjonarny
odtwarzacz plików z audio, z funkcją odbierania streamów po HTTP.

Firmware napisałem za pomocą bibliotek Harmony3 od Microchipa oraz
FreeRTOS. O ile sama aplikacja działa całkiem nieźle, to nie mogę sobie
poradzić z pewną uciążliwą przypadłością - co jakiś czas łączność
sieciowa zawiesza się. I to w tak dziwny sposób, że zawias wywala
łączność we wszystkich urządzeniach podłączonych do tego samego switcha.
Jestem pewien, że przyczyną jest moja płytka, bo prowadziłem testy z
kilkoma różnymi switchami i za każdym razem wygląda to dokładnie tak samo.

Objawy są następujące:
- W pewnym momencie urządzenie traci łączność z siecią. Przestaje
odpowiadać na pingi, nie można się dostać do prostego serwera HTTP
(obsługującego webUI), a socket odbierający w danym momencie stream
audio przestaje otrzymywać dane.
- Co więcej, w tym samym momencie przestaje działać łączność sieciowa na
wszystkich urządzeniach podpiętych do tego samego switcha.
- Dioda ACT na gniazdku ethernetowym mojej płytki świeci ciągle, zamiast
migać w rytm przesyłanych pakietów.
- Co ciekawe problem często nie ustępuje po soft-resecie albo nawet
pełnym power cycle - po ponownym podpięciu zasilania dioda ACT błyśnie
parę razy, a w chwilę później znów zaczyna świecić. W takiej sytuacji
trzeba chwilę odczekać przed ponownym podłączeniem zasilania. Takie
zachowanie nie występuje jednak zawsze. Często zwykły, programowy reset
wystarcza w zupełności.
- Częstotliwość występowania problemu jest różna. Czasem występuje raz
na kilka dni, czasem kilka razy jednego dnia.

Co sprawdziłem do tej pory:
- Włączyłem opcję raportowania zajętości tej części sterty, która jest
wydzielona na użytek stosu TCP/IP. Nie zauważyłem, żeby problem
korelował z brakami miejsca na stercie. Zwiększenie rozmiaru sterty w
niczym nie rozwiązuje problem.
- Próbowałem podnieść rozmiary stosu dla tasków FreeRTOS-a związanych z
TCP/IP, ale nie przyniosło to żadnego efektu.
- Próbowałem manipulować rozmiarami rozmaitych buforów wykorzystywanych
przez TCP/IP, żeby oszczędzić pamięć. W niczym to nie pomogło.

Dodatkowo: jakiś czas temu opracowałem nową wersję płytki do tego
urządzenia, z dużo mocniejszym MCU (PIC32MZ2048). Tam nie zauważyłem
jeszcze nigdy podobnego objawu. Może jest to związane z większą ilością
zasobów sprzętowych - samo procesor jest znacznie szybszy, mogłem też
ustawić większe rozmiary sterty oraz jej części przeznaczonej dla zadań
TCP/IP.

Można by co prawda próbować zrzucić winę na fakt, że urządzenie jest
zbudowane na samodzielnie trawionej (dwustronnej) płytce. Jednak poza
tymi dziwnymi zawiasami nie występują absolutnie żadne problemy z
łącznością, nie zauważyłem ani jednego zgubionego pakietu podczas
normalnej pracy. Poza tym zbudowałem jeszcze kilka innych urządzeń z
DP83848 (w tym również z mikrokontrolerami STM32) na samodzielnie
trawionych płytkach i nigdy nie miałem z tego tytułu żadnych problemów.

Ktoś ma jakiś pomysł co do możliwej przyczyny? Szczególnie zastanawia
mnie to wywalanie łączności na wszystkich urządzeniach podpiętych do
tego switcha. W wolnej chwili spróbuję podpiąć Wiresharka i zobaczyć co
tak właściwie się wtedy dzieje, jednak może ktoś z was zetknął się z
czymś takim, albo przynajmniej ma pomysł jak to dalej debugować? ;)

[Mirek]

On 5.02.2024 20:34, Atlantis wrote:

> Ktoś ma jakiś pomysł co do możliwej przyczyny? Szczególnie zastanawia
> mnie to wywalanie łączności na wszystkich urządzeniach podpiętych do
> tego switcha. W wolnej chwili spróbuję podpiąć Wiresharka i zobaczyć co
> tak właściwie się wtedy dzieje, jednak może ktoś z was zetknął się z
> czymś takim, albo przynajmniej ma pomysł jak to dalej debugować? ;)

Koniecznie odpal Wiresharka i zobacz co się dzieje.
Jak kładzie całą sieć, to możliwe, że odpowiada na każdy pakiet TCP -
tak jakby nie filtruje własnego MAC-a - każdy traktuje jak swój i w
rezultacie switch wszystkie pakiety kieruje do niego.
Drugi problem może być z samym układem PHY - wtedy prawdopodobnie nic
nie zobaczysz.
Z tym pierwszym przypadkiem spotkałem się OIDP tylko raz i co ciekawe
tak się zachowywała końcówka GPON operatora.
Z drugim przypadkiem spotkałem się wielokrotnie - zwykle był to switch z
kategorii mały, tani 4-ro, 8-mio portowy, ale też pamiętam Mikrotika i
mediakonwerter MOXA - tak że nie ma reguły.
Na Wiresharku nic nie widać - po prostu z czasem pakiety nie dochodzą i
tyle. Po odłączeniu pacjenta od sieci sytuacja wraca do normy, ale
dopiero po pewnym czasie. Tak samo po podłączeniu problem zaczyna się
robić z dużym opóźnieniem, tak że w rozległej sieci ciężko coś takiego
namierzyć.

--
Mirek.

[Marek]

On Mon, 5 Feb 2024 20:57:52 +0100, Mirek <mi...@null.dev> wrote:
> Jak kładzie całą sieć, to możliwe, że odpowiada na każdy pakiet TCP
> -
> tak jakby nie filtruje własnego MAC-a - każdy traktuje jak swój i w
> rezultacie switch wszystkie pakiety kieruje do niego.

Mógłbyś to precyzyjniej opisać? Przecież to switch decyduje co komu
wg tablicy, który MAC "widać" na danym porcie. Urządzenie musiałoby
odpowiadać na każdy whohas o dowolny IP co jest nieprawdopodobne w
stosie mchp.
Jak przez mgłę kojarzę bardzo podobny przypadek jaki miałem z tym
stosem (nagła niewidzialność innych urządzeń) ale niestety nie mogę
sobie przypomnieć wniosków z diagnostyki.

--
Marek

[Marek]

On Mon, 5 Feb 2024 20:34:17 +0100, Atlantis <marekw19...@wp.pl>
wrote:

> tak właściwie się wtedy dzieje, jednak może ktoś z was zetknął się
> z
> czymś takim, albo przynajmniej ma pomysł jak to dalej debugować? ;)

Rozumiem, że aplikacja działa nadal podczas zwieszki sieciowej, nie
wiesza się, tylko sieć nie działa? Czy możesz periodycznie na konsole
debug wyrzucać bieżącą konfigurację sieci (przydzielony IP, maska)
oraz MAC? Czy czasem ona się nie zmienia po wystąpieniu zwieszki?

--
Marek

[Atlantis]

On 5.02.2024 22:13, Marek wrote:

> Rozumiem, że aplikacja działa nadal podczas zwieszki sieciowej, nie
> wiesza się, tylko sieć nie działa? Czy możesz periodycznie na konsole
> debug wyrzucać bieżącą konfigurację sieci (przydzielony IP, maska) oraz
> MAC? Czy czasem ona się nie zmienia po wystąpieniu zwieszki?

Tak, mogę. Zapomniałem właśnie o tym wspomnieć. Konfiguracja po stronie
urządzenia nie zmienia się. Komenda "netinfo" pokazuje poprawną
konfigurację. Adresy IP i MAC nie zmieniają się, system twierdzi, że
interfejs sieciowy jest w stanie "up". Komenda "macinfo" pokazuje tylko
tyle, że licznik odebranych/wysłanych pakietów w pewnym momencie
przestaje się zwiększać.

Przyszedł mi do głowy jeszcze pomysł - uruchomiłem urządzenie na
minimalnej konfiguracji. Ro znaczy zostawiłem jedynie obsługę
podstawowego stosu z TCP/IP/UDP/ARP/DHCP/DNS. Wywaliłem NBNS, HTTP i
biblioteki kryptograficzne związane z WOLFSSL (nawet jeśli się z niego
nie korzysta, autorzy bibliotek zalecają dodanie ich do projektu, ze
względu na lepsza obsługę RNG, można to jednak wyłączyć).

Jak na razie projekt się nie zawiesił, ale jak mówiłem - niekiedy działo
się to po kilku dniach. Jeśli do tego nie dojdzie, będę powoli dodawał
kolejne usunięte komponenty. Na pewno nie chciałbym rezygnować z HTTP,
bo webUI było bardzo wygodną funkcjonalnością. Z SSL mogę na dobrą
sprawę zrezygnować, bo na chwilę obecną i tak nie zaimplmenetowałem
funkcji odbioru streamów HTTPS.

[Adam Górski]

Miałem kiedyś problem taki , że na mierniku agilent 34461A podpiętego do
LANu z inetem wywalało okienko z błędem. Chamski WEB error.

Wywalał się tylko wtedy gdy do sieci wpięty był modem/router LTE od
T-Mobila i jego implementacja IPv6.

kupiłem nawet na okazję debugowania tego switcha z mirroringiem portów.
Złapałem nawet całą sytuację na wiresharku i wysłałem do Agilenta.

Ale mieli na to wyjebane odpisując , że przy kolejnej rewizji softu zobaczą.

Może zatem u Ciebie coś podobnego. Jakaś dziwna jumbo ramka wypiernicza
phy lub maca. Albo jakiś inny problem się nakłada na brak odporności.

Powodzenia. Żeby cokolwiek zobaczyć trzebaby mieć switcha z mirrorem i
na tym porcie nagrywać.

Pozdrawiam
Adam Górski

[Marek]

On Tue, 6 Feb 2024 18:46:58 +0100, Adam
Górski<gorskia_i_tak_t...@wp.pl> wrote:
> Miałem kiedyś problem taki , że na mierniku agilent 34461A
> podpiętego do
> LANu z inetem wywalało okienko z błędem. Chamski WEB error.

Co ma warstwa 7 OSI do warstwy 4?
Ewidentnie problem jest raczej poniżej warstwy 5.

--
Marek

[Mirek]

On 5.02.2024 22:09, Marek wrote:

> Mógłbyś to precyzyjniej opisać? Przecież to switch decyduje co komu wg
> tablicy, który MAC "widać" na danym porcie. Urządzenie musiałoby
> odpowiadać na każdy whohas  o dowolny IP co jest nieprawdopodobne w
> stosie mchp.

Nieprawdopodobne jest to, co napisałem, czyli że odpowiada na każdy MAC
- żeby to zadziałało, to musiałby odpowiedzieć pakietem z takim samym
MAC-iem źródłowym jak dostał docelowy żeby zmylić switcha.
Bardziej możliwe jest, że pamięć mnie zawodzi - faktycznie chyba
odpowiadał na każde who has, czyli brał na siebie wszystkie IP. Szkoda,
że nie zrobiłem wtedy zrzutu z wiresharka. Zwykle przy takich akcjach
jest wszystko na wczoraj i nie ma czasu na dociekanie co się dzieje.
Sukcesem jest znalezienie wadliwego urządzenia, a co ono tam wyprawia to
już nie ma znaczenia.

--
Mirek.

[Atlantis]

No cóż... Uruchomiłem bardziej minimalistyczną wersję stosu, z wywalona
obsługą HTTP, NBNS oraz WolfSSL (z towarzyszącymi mu bibliotekami).
Od tamtego momentu problem wystąpił już jeden raz.
Przyszedł mi do głowy jeszcze jeden pomysł. Płytka podczas testów
właściwie non-stop jest pingowana przez peceta. Zobaczę jak urządzenie
się zachowa, jeśli tego zaniecham na jakiś czas.

Przypomniałem sobie jeszcze, że przez pewien czas (na samym początku)
urządzenie pracowało na firmware napisanym za pomocą starych bibliotek
MLA. Dopiero później przeniosłem je na Harmony. Nie przypominam sobie
żeby podczas testów na starym FW wystąpił taki błąd. To zmniejsza
prawdopodobieństwo hipotezy, że winę ponosi problem sprzętowy.

[Adam Górski]

>> Miałem kiedyś problem taki , że na mierniku agilent 34461A podpiętego
>> do LANu z inetem wywalało okienko z błędem. Chamski WEB error.
>
> Co ma warstwa 7 OSI do warstwy 4?
> Ewidentnie problem jest raczej poniżej warstwy 5.
>

Ty mi powiedz.

Pozdrawiam

Adam Górski

[Marek]

On Tue, 6 Feb 2024 20:03:56 +0100, Atlantis <marekw19...@wp.pl>
wrote:

> Przypomniałem sobie jeszcze, że przez pewien czas (na samym
> początku)
> urządzenie pracowało na firmware napisanym za pomocą starych
> bibliotek
> MLA. Dopiero później przeniosłem je na Harmony. Nie przypominam
> sobie

W odpowiedzi komu innemu pisałem że na 99% kilka lat temu zetknąłem
się z tym samym problemem na pic32. Tylko niestety nie pamiętam,
który to był stos mla czy Harmony bo w tamtym czasie używałem oba.
Pamiętam blokadę "ruchu" na switchu i palącą się na stałe diodę ACT
na gnieździe eth z pic32. Jak tylko przypomnę sobie co to było dam
znać.

--
Marek

[Atlantis]

On 7.02.2024 00:25, Marek wrote:

> W odpowiedzi komu innemu pisałem że na 99% kilka lat temu zetknąłem się
> z tym samym problemem na pic32. Tylko niestety nie pamiętam, który to
> był stos mla czy Harmony bo w tamtym czasie używałem oba. Pamiętam
> blokadę "ruchu" na switchu i palącą się na stałe diodę ACT na gnieździe
> eth z pic32. Jak tylko przypomnę sobie co to było dam znać.

Gdyby udało się przypomnieć co to powodowało, to byłbym bardzo wdzięczny
za tę informację.
Na razie sprawdzam hipotezę na temat wpływu pingowania płytki na to
zachowanie. Póki co od wczoraj się nie zawiesiła, ale to jeszcze niczego
nie przesądza, bo nieraz problem występował dopiero po kilku dniach.

[Marek]

On Wed, 7 Feb 2024 09:51:17 +0100, Atlantis <marekw19...@wp.pl>
wrote:

> zachowanie. Póki co od wczoraj się nie zawiesiła, ale to jeszcze
> niczego
> nie przesądza, bo nieraz problem występował dopiero po kilku dniach.

Gdy jest zwieszka i wyjmiesz wtyk eth z płytki ruch na switchu się
przywraca? Czy po włożeniu wtyczki z powrotem (bez resetowania
płytki) od razu diioda ACT zapala się na stałe i ruch ponownie
zanika?

--
Marek

[Atlantis]

On 8.02.2024 07:41, Marek wrote:

> Gdy jest zwieszka i wyjmiesz wtyk eth z płytki ruch na switchu się
> przywraca?

Tak. Komputer podłączony do tego samego switcha odzyskuje łączność
natychmiast po wyjęciu kabla Ethernet z mojej płytki. Jeśli podłączę
kabel ponownie, problem powraca - dioda ACT znów zaczyna świecić cały
czas, chociaż komputer traci łączność z drobnym opóźnieniem.

Problem powrócił dzisiaj, czyli jednak wiadomo, że to nie pingowanie
płytki było przyczyną.

> Czy po włożeniu wtyczki z powrotem (bez resetowania płytki)
> od razu diioda ACT zapala się na stałe i ruch ponownie zanika?

Tak. Po włożeniu kabla bez resetu dioda zapala się cały czas i problem
pojawia się natychmiast.

Było też kilka sytuacji, kiedy problem pojawiał się ponownie po resecie,
ale wtedy dioda zdążyła jeszcze mignąć kilka razy przed zapaleniem się
na stałe.

[Atlantis]

Przyszedł mi jeszcze do głowy pomysł, że może dochodzić do zagłodzenia
któregoś z tasków odpowiedzialnych za łączność sieciową. Sprawdziłem i
faktycznie wszystkie one mają priorytet 1 - taki sam, jak task w którym
wykonuje się mój kod. Zmieniłem go na 2 i zobaczę jak teraz zachowa się
urządzenie.

[Atlantis]

Tak w sumie zapomniałem dodać, że równolegle mam do czynienia z nieco
podobnym problemem, którego przyczyna może (chociaż wcale nie musi) być
związana z tym opisywanym powyżej.

Mianowicie jakiś czas wcześniej powstała uboższa wersja tego hardware'u,
gdzie jedyną róznicą było zastosowanie układu ENC28J60 zamiast
wbudowanego w PIC32MX795F512L układu MAC z zewnętrznym PHY. Ta płytka
również oryginalnie pracowała na bibliotekach MLA. Jakiś czas temu
postanowiłem jednak przenieść na nią nową wersję firmware (napisaną przy
pomocy Harmony3). Było to dosyć proste - wystarczyło wygenerować kod w
oparciu o prawie taką samą konfigurację (zmieniając jedynie kontroler
Ethernetu i kilka pinów) oraz przerzucić pliki z kodem aplikacji.
Urządzenie generalnie działa, ale również od czasu do czasu wywala się w
nim stos TCP/IP. W tym wypadku crashe nie są jednak losowe, a dzieją się
w konkretnym momencie - przy próbie dostania się do serwera HTTP.
Dosłownie w momencie otwarcia adresu w przeglądarce wywala się łączność.
Jeśli usunę serwer HTTP z konfiguracji (albo przynajmniej nie próbuję
się z nim łączyć) urządzenia działa całkowicie stabilnie.

Tutaj także w przypadku wywalenia łączności cała reszta aplikacji działa
poprawnie. Na wydzielonym dla TCP/IP fragmencie sterty jest jeszcze
sporo miejsca. W "macinfo" widzę natomiast nTxPendBuffers: 3 - wartość
ta się nie zmienia. Jakby nie mógł wysłać tych danych.

[Marek]

On Thu, 8 Feb 2024 21:18:58 +0100, Atlantis <marekw19...@wp.pl>
wrote:

> Tutaj także w przypadku wywalenia łączności cała reszta aplikacji
> działa
> poprawnie. Na wydzielonym dla TCP/IP fragmencie sterty jest jeszcze
> sporo miejsca. W "macinfo" widzę natomiast nTxPendBuffers: 3 -
> wartość
> ta się nie zmienia. Jakby nie mógł wysłać tych danych.

Nie mam zbyt dużo doswiadczenia z Harmony, Kiedyś krótko to
testowałem ale nie wdrażałem produkcyjnie. Natomiast na MLA +
enc28j60 mam na produkcji urządzenia chodzące już 10 rok 24h i nigdy
nie było problemu z łącznością z nimi, uważam, że stos MLA jest
bardzo stabilny (TCP + UDP, jedyne co nie używam, ze stosu to DHCP
oraz tego ich serwera HTTP, używam własny).
Był jeden incydent w trakcie jakiś testów właśnie podobny do tego co
opisujesz, ale ciągle nie pamiętam szczegółów.

--
Marek

[Atlantis]

On 9.02.2024 01:05, Marek wrote:

> Nie mam zbyt dużo doswiadczenia z Harmony, Kiedyś krótko to testowałem
> ale nie wdrażałem produkcyjnie. Natomiast na MLA + enc28j60 mam na
> produkcji urządzenia chodzące już 10 rok 24h i nigdy nie było problemu z
> łącznością z nimi, uważam, że stos MLA jest bardzo stabilny (TCP + UDP,
> jedyne co nie używam, ze stosu to DHCP oraz tego ich serwera HTTP,
> używam własny).

Ja też właśnie przez długie lata korzystałem z z MLA i ciągle korzystam
z niego w projektach z mniejszymi MCU. W przypadku PIC18/PIC24 innego
wyjścia właściwie nie ma, a i część PIC32 ma za mało zasobów, żeby
obsłużyć Harmony. Jednak jakby nie patrzeć, MLA jest już dość starą i
nierozwijaną biblioteką, która z kolei nie wspiera nowszych układów.
To jest właśnie główny powód, dla którego przeniosłem ten projekt na
Harmony - nowsza wersja hardware'u wykorzystuje PIC32MZ2048.

Harmony ma też swoje zalety - kod łatwo generuje się z konfiguratora,
jest też dostępnych więcej bibliotek. Pamiętam, że kiedyś spędziłem
kilka tygodni naprawiając jakiś krzywy kod z GitHuba, aby mieć na MLA
obsługę klienta MQTT. W Harmony taki klient po prostu jest zaimplementowany.

Co do stabilności - jak wspomniałem, na PIC32MZ2048 nie natknąłem się na
podobne problemy. Dlatego podejrzewam, że kwestia może się kryć gdzieś w
optymalizacji konfiguracji pod kątem wykorzystania zasobów.

> Był jeden incydent w trakcie jakiś testów właśnie podobny do tego co
> opisujesz, ale ciągle nie pamiętam szczegółów.

Pamiętasz czy to było na MLA czy Harmony?
W każdym razie, odkąd wczoraj zmieniłem priorytet tasku z moja
aplikacją, problem się nie pojawił. To znaczy był inny crash, ale
znacznie mniej uciążliwy: klient z utracił łączność i nie chciał się
połączyć ponownie (DNS wywalał błąd -5) ale nie było już efektu
świecenia diody ACT i blokady ruchu na poziomie switcha. Tym razem
wystarczyło tylko odpiąć o ponownie podpiąć kabel ethernetowy, bez
resetowania całego urządzenia.

[Atlantis]

On 8.02.2024 21:18, Atlantis wrote:

> Mianowicie jakiś czas wcześniej powstała uboższa wersja tego hardware'u,
> gdzie jedyną róznicą było zastosowanie układu ENC28J60 zamiast

> wbudowanego w PIC32MX795F512L układu MAC z zewnętrznym PHY. (...)

> W tym wypadku crashe nie są jednak losowe, a dzieją się
> w konkretnym momencie - przy próbie dostania się do serwera HTTP.

Ok. Wygląda na to, że ten problem udało mi się rozwiązać. Wystarczyło
włączyć obsługę DMA na SPI, który obsługuje ENC28J60.

[Marek]

On Fri, 9 Feb 2024 20:04:50 +0100, Atlantis <marekw19...@wp.pl>
wrote:

> Ok. Wygląda na to, że ten problem udało mi się rozwiązać.
> Wystarczyło
> włączyć obsługę DMA na SPI, który obsługuje ENC28J60.

Gdzie? Driver Harmony en28j60 używa DMA?
Ale jaki to ma bezpośredni związek z blokadą switcha?
Liczyłem na to, że jednak zrobisz analize ruchu w tym kablu bom był
ciekaw jak taka 10Mbit zabawka może takiego DOSa na współczesnym
switchu spowodować

--
Marek

[Atlantis]

On 10.02.2024 09:16, Marek wrote:

> Gdzie? Driver Harmony en28j60 używa DMA?

Tak. To znaczy jest taka opcja. Można wygenerować konfigurację, w której
ENC28J60 jest podpięty do drivera SPI skonfigurowanego do działania w
trybie DMA.

> Ale jaki to ma bezpośredni związek z blokadą switcha? Liczyłem na to, że
> jednak zrobisz analize ruchu w tym kablu bom był ciekaw jak taka 10Mbit
> zabawka może takiego DOSa na współczesnym switchu spowodować

Tutaj mówimy o dwóch osobnych problemach na dwóch podobnych płytkach.

Blokowanie switcha z objawem ciągłego świecenia ACT występuje (lub
występowało) na nowszej wersji hardware'u, z PIC32MX795F512 + DP83848 (a
więc FastEthernet). Na razie w ramach eksperymentu zmieniłem trochę
konfigurację tasków FreeRTOS-a, obniżając priorytet tego, w którym
działa mój kod. Jak na razie problem z blokadą nie wystąpił, chociaż
jeszcze nie mogę tego wykluczyć, bo nieraz zdarzało się kilka dni
spokoju. Jeśli jednak faktycznie nie powróci to będzie oznaczało, że
powodem blokady było zagłodzenie któregoś z tasków zaangażowanych w
łączność TCP/IP.

Osobny problem miałem na bliźniaczej, starszej wersji płytki z
PIC32MX795F512L + ENC28J60. Tam dochodziło do crasha łączności sieciowej
przy próbie wejścia na stronę obsługiwaną przez serwerek HTTP odpalony
na tej płytce. W tym przypadku nie dochodziło jednak do zablokowania
łączności na switchu (ani ciągłego świecenia ACT). Problem nie był też
losowy - można było go dość jasno skojarzyć serwerem HTTP.
W tym wypadku pomogło właśnie właczenie DMA, nie wiem dlaczego.

Oczywiście obydwie płytki nadal obserwuję, bo o ile sytuacja się
poprawiła nie mogę mieć pewności, że wszystkie problemy zostały rozwiązane.

[Atlantis]

On 10.02.2024 14:12, Atlantis wrote:

> Blokowanie switcha z objawem ciągłego świecenia ACT występuje (lub
> występowało) na nowszej wersji hardware'u, z PIC32MX795F512 + DP83848 (a
> więc FastEthernet). Na razie w ramach eksperymentu zmieniłem trochę
> konfigurację tasków FreeRTOS-a, obniżając priorytet tego, w którym
> działa mój kod. Jak na razie problem z blokadą nie wystąpił, chociaż
> jeszcze nie mogę tego wykluczyć, bo nieraz zdarzało się kilka dni
> spokoju.

A jednak byłem w błędzie. Problem powrócił z tymi samymi objawami:
wywalenie komunikacji na switchu, cały czas świecąca się dioda ACK.
Czyli wracamy do punktu wyjścia...

[Marek]

On Sat, 10 Feb 2024 19:17:13 +0100, Atlantis <marekw19...@wp.pl>
wrote:

> A jednak byłem w błędzie. Problem powrócił z tymi samymi objawami:
> wywalenie komunikacji na switchu, cały czas świecąca się dioda ACK.
> Czyli wracamy do punktu wyjścia...

Ciągle czekamy na analizę ruchu w kablu, czemu tego nie zrobisz? Etap
wróżenia z fusów się już za nami...

--
Marek

[Atlantis]

On 11.02.2024 10:17, Marek wrote:

> Ciągle czekamy na analizę ruchu w kablu, czemu tego nie zrobisz? Etap
> wróżenia z fusów się już za nami...

Chwilowy brak czasu - miałem parę innych spraw na głowie, wiec skupiłem
się na tych testach, które można wykonać "z doskoku".
Jak wspominałem, problemu nie można striggerować na żądanie, a niekiedy
pojawia się on dopiero po kilku dniach pracy urządzenia. Będe musiał
więc wziąć laptopa, ustawić na nim połączenie bridge i przechwytywać
cały ruch za pomocą tcpdumpa, być może nawet przez kilka dni.

Na razie porównałem działanie firmware'u na kilku różnych rewizjach
płytki. Czas nie był stracony, bo namierzyłem jeszcze jednego buga w
kodzie obsługującym printowanie dynamicznych zmiennych przez serwer HTTP
- w pewnej sytuacji dochodziło do zarezerwowania bufora, który nigdy nie
był zwalniany, przez co cały system printowania tych zmiannych
przestawał działać. Nie ma to nic wspólnego z głównym problemem
(komunikacja na płytce z PIC32MX512F512L+DP83848 wywala się nawet wtedy,
gdy w ogóle zrezygnujemy z serwera HTTP), ale przynajmniej daje mi to
jedną zmienną mniej, która mogłaby zaciemniać sprawę.

[Mirek]

On 11.02.2024 15:33, Atlantis wrote:
.
> Jak wspominałem, problemu nie można striggerować na żądanie, a niekiedy
> pojawia się on dopiero po kilku dniach pracy urządzenia. Będe musiał
> więc wziąć laptopa, ustawić na nim połączenie bridge i przechwytywać
> cały ruch za pomocą tcpdumpa, być może nawet przez kilka dni.
>

Problem ustaje po odpięciu i podpięciu rj-ki czy nie?
Bo jeśli jest nadal to co za problem odpiąć ją i podpiąć pod laptopa i
odpalić wiresharka?
Wystarczy sprawdzić podstawowe rzeczy, czyli jak to urządzenie reaguje
na arp, ping i czy nie wysyła czegoś głupiego i już coś się rozjaśni.
Tak samo nie widzę problemu, żeby nie odpinać rj-ki tylko podpiąć się do
switcha i sprawdzić, ewentualnie przepuścić sobie ruch przez laptopa.

--
Mirek.

[Atlantis]

On 11.02.2024 16:09, Mirek wrote:

> Problem ustaje po odpięciu i podpięciu rj-ki czy nie?
> Bo jeśli jest nadal to co za problem odpiąć ją i podpiąć pod laptopa i
> odpalić wiresharka?

Racja, można próbować w ten sposób. Mi jednak zależałoby na
przechwyceniu całej sekwencji zdarzeń, która prowadzi do wystąpienia awarii.

W każdym razie obecnie mija trzecia doba, jak urządzenie pracuje i do
tej pory nie zawiesiło jednocześnie wykrzaczając wszystkie urządzenia na
tym samym switchu. Nie jestem pewien która zmiana za to odpowiada, bo
zmieniłem kilka rzeczy: usunąłem znalezionego buga w kodzie printującym
zmienne dynamiczne w plikach HTTP, ograniczyłem trochę użycie pamięci
oraz zmieniłem ustawienia sterty (teraz zarówno stos TCP/IP jak i
FreeRTOS korzystają z głównej sterty systemowej, bez wydzielania
osobnych części).

Pojawił się za to inny błąd - mniej drastyczny, ale także uciążliwy.
Mianowicie po jakimś czasie urządzenie z jakiegoś powodu traci możliwość
nawiązywania połączeń jako klient. Jeśli próbuję połączyć się z jakimś
stremem, proces pada na poziomie DNS-a (zwrócony zostaje błąd -5,
oznaczający DNS timeout). Jeśli próbuję połączyć ze stremem, który ma w
URL-u adres IP widzę następującą sekwencję zdarzeń:

- Aplikacja uzyskuje socket (a więc problemem nie jest brak dostępnych
socketów TCP)
- Aplikacja z powodzeniem rozszerza bufor odbiorczy socketa do 4096
bajtów (a wiec problemem nie jest brak miejsca na stercie)
- Po pięciu sekundach socket nie jest jednak w stanie uzyskać połączenia
i wołany jest timeout (który sam dodałem w swojej aplikacji)

Serwer HTTP odpalony na płytce w tym czasie działa normalnie, odpowiedzi
na pingi też przychodzą. Jednak połączenia z serwerem w sieci nie da się
zainicjować.

W tym wypadku problem znika po odpięciu na chwilę kabla ethernetowego.
Nie trzeba nawet resetować urządzenia.

Nie ma pojęcia czy ten problem jest w jakikolwiek sposób związany z tym
poprzednim, poważnym, który mi zawieszał kawałek sieci.

[Mirek]

On 15.02.2024 20:43, Atlantis wrote:

>
> Serwer HTTP odpalony na płytce w tym czasie działa normalnie, odpowiedzi
> na pingi też przychodzą. Jednak połączenia z serwerem w sieci nie da się
> zainicjować.
>

Czekaj co jest serwerem i co gdzie jest?
Serwer http jest na tej płytce i odpowiada?
W tym samym czasie chcesz się z płytki połączyć z jakimś serwerem w
sieci i utyka na dns-ach?
Strzelam: dostaje adres IPv6 i nie wie co z nim zrobić?
Ale to strzał całkiem na ślepo i z niewyczyszczonej broni.
Trzeba zrobić rozpoznanie Wiresharkiem, a jak nie, to musisz zrobić
rozpoznanie bojem czyli wyrzucić sobie na terminal po kolei co się dzieje.

--
Mirek.

[Atlantis]

On 15.02.2024 21:37, Mirek wrote:

> Czekaj co jest serwerem i co gdzie jest?
> Serwer http jest na tej płytce i odpowiada?

Na płytce jest zarówno serwer, jak i klient HTTP:
1. Serwer obsługuje prosty webowy interfejs użytkownika, za pomocą
którego można m.in. sterować odtwarzaniem.
2. Klient łączy się z serwerami HTTP w sieci, które strumieniują audio
stacji radiowych. Po połączeniu parsowane są nagłówki, a gdy wszystko
się zgadza zaczyna ładować dane do bufora cyklicznego, skąd są
przekazywane do dekodera audio (VS1003).

W momencie gdy klient przestaje się łączyć ze stacjami internetowymi,
webUI nadal działa.

> W tym samym czasie chcesz się z płytki połączyć z jakimś serwerem w
> sieci i utyka na dns-ach?

To byłaby dobra hipoteza, gdyby problem nie dotyczył także URL-i z
adresem IP. Adresy, które wymagają zaangażowania DNS-a faktycznie
utykają na tym etapie. Stacja do której dostaje się przez IP z
oczywistego powodu pomija ten etap i wywala timeout nie mogąc się
doczekać połączenia.

> Strzelam: dostaje adres IPv6 i nie wie co z nim zrobić?

Obsługa IPv6 jest w tej chwili zupełnie wyłączona w opcjach klienta DNS.

[ptoki]

On 2024-02-15 17:46, Atlantis wrote:
> On 15.02.2024 21:37, Mirek wrote:
>
>> Czekaj co jest serwerem i co gdzie jest?
>> Serwer http jest na tej płytce i odpowiada?
>
> Na płytce jest zarówno serwer, jak i klient HTTP:
> 1. Serwer obsługuje prosty webowy interfejs użytkownika, za pomocą
> którego można m.in. sterować odtwarzaniem.
> 2. Klient łączy się z serwerami HTTP w sieci, które strumieniują audio
> stacji radiowych. Po połączeniu parsowane są nagłówki, a gdy wszystko
> się zgadza zaczyna ładować dane do bufora cyklicznego, skąd są
> przekazywane do dekodera audio (VS1003).
>

Masz tam slota na karte sd z tym VS-em?
Nie mialem czasu sie jeszzce zajac tematem ale mam pare modulow z VSami
z i bez kart i sie zastanawiam czy te karty sa podpiete tak ze mozna je
czytac i pisac z zewnetrznego kontrolera.

Nie mailem czasu zajrzec w schematy a te co widzialem to maja dziwnie
rozmalowane polaczenia i nie do konca wiem czy sdkarta jest dostepna po
spi/iic

--
Lukasz

[Atlantis]

On 16.02.2024 01:11, ptoki wrote:

> Masz tam slota na karte sd z tym VS-em?

Mam na tej płytce kartę gniazdo karty SD, ale jest podpięte do osobnej
magistrali SPI. W dokumentacji VS1003 była informacja, że możliwe jest
używanie kodeka na jednej magistrali z innymi urządzeniami, ale nieraz
wymaga to dodatkowych kroków (np. rekonfiguracji między transmisjami).
Skoro miałem taką możliwość, wolałem sobie oszczędzić kłopotów. Płytke i
tak projektowałem od podstaw i nie stosowałem fabrycznych modułów.

> Nie mialem czasu sie jeszzce zajac tematem ale mam pare modulow z VSami
> z i bez kart i sie zastanawiam czy te karty sa podpiete tak ze mozna je
> czytac i pisac z zewnetrznego kontrolera.

Prawdopodobnie w przypadku tych modułów z kartą SD jest ona po prostu
podłączona do tej samej magistrali SPI. Powinno się dać korzystać z
obydwu urządzeń jednocześnie, ale warto najpierw wczytać się w
dokumentację i zapoznać się z ograniczeniami.

> Nie mailem czasu zajrzec w schematy a te co widzialem to maja dziwnie
> rozmalowane polaczenia i nie do konca wiem czy sdkarta jest dostepna po
> spi/iic

Najlepiej będzie sprawdzić właśnie na schemacie. Interfejs VS10xx jest
relatywnie prosty - zwykła magistrala SPI + kilka dodatkowych sygnałów
sterujących. Jeśli karta współdzieli magistralę z kodekiem, to powinny
być wspólne piony MISO, MOSI i SCK oraz osobny CS + ewentualnie piny
charakterystyczne dla kart SD (present i write protect).

[Mirek]

On 16.02.2024 00:46, Atlantis wrote:

> To byłaby dobra hipoteza, gdyby problem nie dotyczył także URL-i z
> adresem IP. Adresy, które wymagają zaangażowania DNS-a faktycznie
> utykają na tym etapie. Stacja do której dostaje się przez IP z
> oczywistego powodu pomija ten etap i wywala timeout nie mogąc się
> doczekać połączenia.

No dobra, już coś wiemy. Czyli problem nie jest z DNS, tylko wygląda to
na problem z połączeniem do IP poza siecią lokalną - zgadza się?
Połączenie z DNS też utyka, bo łączysz się np. do 1.1.1.1? czy za ten
serwer DNS robi ruter w sieci lokalnej?
I teraz dlaczego wypięcie i wpięcie rj-ki to naprawia?
Obsługujesz to jakoś, tzn pobranie adresu od nowa, restart połączeń?

Bronisz się przed tym wiresharkiem, ale przynajmniej byś wiedział, czy
zapytanie wychodzi prawidłowo do serwera i czy coś wraca czy nie.

--
Mirek.

[ptoki]

On 2024-02-16 02:14, Atlantis wrote:
> On 16.02.2024 01:11, ptoki wrote:
>
>> Masz tam slota na karte sd z tym VS-em?
>
> Mam na tej płytce kartę gniazdo karty SD, ale jest podpięte do osobnej
> magistrali SPI. W dokumentacji VS1003 była informacja, że możliwe jest
> używanie kodeka na jednej magistrali z innymi urządzeniami, ale nieraz
> wymaga to dodatkowych kroków (np. rekonfiguracji między transmisjami).
> Skoro miałem taką możliwość, wolałem sobie oszczędzić kłopotów. Płytke i
> tak projektowałem od podstaw i nie stosowałem fabrycznych modułów.
>

Ah, sam se zrobiles. ok.
Obstawiam ze bedzie sie dalo z karta gadac.

>
>> Nie mialem czasu sie jeszzce zajac tematem ale mam pare modulow z
>> VSami z i bez kart i sie zastanawiam czy te karty sa podpiete tak ze
>> mozna je czytac i pisac z zewnetrznego kontrolera.
>
> Prawdopodobnie w przypadku tych modułów z kartą SD jest ona po prostu
> podłączona do tej samej magistrali SPI. Powinno się dać korzystać z
> obydwu urządzeń jednocześnie, ale warto najpierw wczytać się w
> dokumentację i zapoznać się z ograniczeniami.
>
>

dzieki za opinie. Nie jest mi potrzebne jednoczesne korzystanie z karty
przez dekoder i esp. startczy osobno.

>> Nie mailem czasu zajrzec w schematy a te co widzialem to maja dziwnie
>> rozmalowane polaczenia i nie do konca wiem czy sdkarta jest dostepna
>> po spi/iic
>
> Najlepiej będzie sprawdzić właśnie na schemacie. Interfejs VS10xx jest
> relatywnie prosty - zwykła magistrala SPI + kilka dodatkowych sygnałów
> sterujących. Jeśli karta współdzieli magistralę z kodekiem, to powinny
> być wspólne piony MISO, MOSI i SCK oraz osobny CS + ewentualnie piny
> charakterystyczne dla kart SD (present i write protect).
>

no wlasnie adafruit pokazuje to dziwnie i nie wypatrzylem czy miso jest
tylko miedzy dekoderem i karta czy do zewnatrz tez.

https://learn.adafruit.com/assets/11221



--
Lukasz

[Atlantis]

On 16.02.2024 19:51, Mirek wrote:

> No dobra, już coś wiemy. Czyli problem nie jest z DNS, tylko wygląda to
> na problem z połączeniem do IP poza siecią lokalną - zgadza się?
> Połączenie z DNS też utyka, bo łączysz się np. do 1.1.1.1?  czy za ten
> serwer DNS robi ruter w sieci lokalnej?

Właśnie kwestia polega na tym, że w tej chwili za serwer DNS robi
lokalny router. Dlatego odrzuciłem hipotezę, że płytka ma problem z
wykonywaniem połączeń poza sieć, bo z jej punktu widzenia serwer DNS
znajduje się w sieci lokalnej. Bardziej prawdopodobne wydaje mi się, że
problem był związany z inicjowaniem połączeń jako klient.

> I teraz dlaczego wypięcie i wpięcie rj-ki to naprawia?
> Obsługujesz to jakoś, tzn pobranie adresu od nowa, restart połączeń?

Ja bezpośrednio tego nie obsługuję, ale zapewne robi to biblioteka TCP/IP.

W każdym razie udało mi się namierzyć jeszcze jeden błąd. Zintegrowałem
ze swoim kodem pewną bibliotekę przeniesioną z ze starszego projektu,
który był przygotowywany jeszcze na bibliotekach MLA i bez wykorzystania
FreeRTOS-a. Mojej uwadze umknęło, że w jednym miejscu zachodzi
dynamiczna alokacja pamięci za pomocą standardowych funkcji malloc/free.
Jak wiadomo mogą one generować problemy w wielowątkowym środowisku RTOS.
Zamieniłem je na pvPortMalloc oraz vPortFree. Niedługo minie druga doba
od wprowadzenia tej zmiany i nie miałem ani jednego przypadku wywalenia
łączności ani zawieszenia się gniazda klienta, z którego korzysta moja
aplikacja.

[Atlantis]

On 17.02.2024 03:04, ptoki wrote:

> no wlasnie adafruit pokazuje to dziwnie i nie wypatrzylem czy miso jest
> tylko miedzy dekoderem i karta czy do zewnatrz tez.
>
> https://learn.adafruit.com/assets/11221

Z tego schematu wynika, że interfejs SPI jest wyprowadzony na złącze
JP2. Po prostu nie jest to zrobione bezpośrednio, ale za pośrednictwem
bufora 74HC4050. W ten sposób ludzie z Adafruit zadbali o to, żeby moduł
mógł działać także z płytkami Arduino, działającymi na logice 5V.
Wyjątek stanowią tutaj linie DREQ oraz MISO, które są podłączone
bezpośrednio, ale w tą stronę Arduino powinno być w stanie poprawnie
rozpoznać sygnały.

[ptoki]

Aaaa teraz widze to miso.
Dzieki. Wczesniej jak patrzylem to nie widzialem napisu...
--
Lukasz