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.

do góry

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

do góry

On Sat, 10 Feb 2024 19:17:13 +0100, Atlantis <m...@w...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

do góry

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

do góry

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.

do góry

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.

do góry

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.

do góry

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.

do góry

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

do góry

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

do góry