Goto page Previous 1, 2, 3 Next
Atlantis
Guest
Thu Feb 08, 2024 10:18 pm
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
Guest
Fri Feb 09, 2024 2:05 am
On Thu, 8 Feb 2024 21:18:58 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
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
Guest
Fri Feb 09, 2024 10:24 am
On 9.02.2024 01:05, Marek wrote:
Quote:
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.
Quote:
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
Guest
Fri Feb 09, 2024 9:04 pm
On 8.02.2024 21:18, Atlantis wrote:
Quote:
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
Guest
Sat Feb 10, 2024 10:16 am
On Fri, 9 Feb 2024 20:04:50 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
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
Guest
Sat Feb 10, 2024 3:12 pm
On 10.02.2024 09:16, Marek wrote:
Quote:
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.
Quote:
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
Guest
Sat Feb 10, 2024 8:17 pm
On 10.02.2024 14:12, Atlantis wrote:
Quote:
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
Guest
Sun Feb 11, 2024 11:17 am
On Sat, 10 Feb 2024 19:17:13 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
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
Guest
Sun Feb 11, 2024 4:33 pm
On 11.02.2024 10:17, Marek wrote:
Quote:
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
Guest
Sun Feb 11, 2024 5:09 pm
On 11.02.2024 15:33, Atlantis wrote:
..
Quote:
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
Guest
Fri Feb 16, 2024 10:14 am
On 16.02.2024 01:11, ptoki wrote:
Quote:
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.
Quote:
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.
Quote:
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
Guest
Fri Feb 16, 2024 8:51 pm
On 16.02.2024 00:46, Atlantis wrote:
Quote:
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
Guest
Sat Feb 17, 2024 4:04 am
On 2024-02-16 02:14, Atlantis wrote:
Quote:
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.
Quote:
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.
Quote:
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
Guest
Sun Feb 18, 2024 10:18 am
On 16.02.2024 19:51, Mirek wrote:
Quote:
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.
Quote:
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.
Mirek
Guest
Thu Feb 29, 2024 9:03 pm
On 28.02.2024 22:28, Atlantis wrote:
Quote:
On 28.02.2024 22:13, Mirek wrote:
A diodka na switchu? Też się świeci ciągle czy mruga nerwowo?
A diodki od innych portów?
Dobre pytanie... Prawdę mówiąc nie zwróciłem uwagi na ten konkretny
objaw. Ciągłego świecenia raczej nie zauważyłem - pewnie zwróciłbym na
to uwagę. Podejrzewam, że mogły mrugać, co uznałem za normalne zachowanie.
Przy zapętleniu cały switch mruga nieprzerwanie jak szalony - tego nie
da się pomylić z normalnym zachowaniem. No chyba, że tam masz jakieś
multicasty, albo kamery tam chodzą i generują ciągły ruch.
Quote:
To samo może się stać jak zapętlisz tx z rx w jednym porcie.
Co mogłoby być przyczyną takiego zapętlenia na jednym porcie, w
przypadku tego mojego urządzenia?
Nie mam pojęcia - może jakieś przesłuchy, ale to mało realne.
--
Mirek
Goto page Previous 1, 2, 3 Next