On Tue, 6 Feb 2024 20:03:56 +0100, Atlantis <m...@w...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

do góry

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.

do góry

On Wed, 7 Feb 2024 09:51:17 +0100, Atlantis <m...@w...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

do góry

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.

do góry

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.

do góry

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.

do góry

On Thu, 8 Feb 2024 21:18:58 +0100, Atlantis <m...@w...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

do góry

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.

do góry

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.

do góry

On Fri, 9 Feb 2024 20:04:50 +0100, Atlantis <m...@w...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

do góry