PIC32MX795F512L + Harmony - Ethernet się wykrzacza

Jakiś czas temu złożyłem sobie projekt radia internetowego/odtwarzacza
MP3 z wykorzystaniem mikrokontrolera PIC32MX795F512L i układu Ethernet
PHY DP83848. Firmware napisałem przy użyciu starych bibliotek MLA.
Wszystko działało całkiem sprawnie.
Później powstała nowsza wersja hardware'u, wykorzystująca znacznie
mocniejszy PIC32MZ2048EFM100 i bibliotekę Harmony. Sprawdzała się ona
znacznie lepiej - chociażby z uwagi na domyślne wykorzystanie RTOS-a.

Ostatnio postanowiłem backportować nową wersję softu pod stary hardware.
Z czystej ciekawości chciałem się przekonać jak dobrze starszy MCU
będzie sobie radził z nowymi bibliotekami. Gdyby eksperyment się udał,
to potencjalnie mógłbym wykorzystać w przyszłych projektach tych kilka
scalaków leżących w szufladzie. ;)

Oczywiście głównym problemem były mniejsze zasoby sprzętowe. O ile
PIC32MZ2048EFM100 miał 2MB flasha i 512kB RAMu, to PIC32MX795F512L ma
odpowiednio tylko 512kB i 128kB. Program się zmieścił, zajmując jakieś
75% flasha. Zmniejszając rozmiar kilku statycznych buforów, manipulując
rozmiarem sterty i rozmaitymi ustawieniami w konfiguracji udało mi się
także (chyba) upchnąć wszystko w RAM-ie.

Pierwsze wrażenie były jak najbardziej pozytywne. Oprogramowanie
działało na starym sprzęcie zaskakująco dobrze. Powiedziałbym nawet, że
lepiej niż na starych bibliotekach, co zapewne jest zasługą RTOS-a
(różne procesy wykonują się równolegle i np. stos TCP/IP nie łapie
przestoju, gdy inny proces utyka w jakiejś dłuższej pętli).

Dzisiaj jednak kilkukrotnie zaobserwowałem dziwną awarię: komunikacja po
sieci wykrzaczyła się zupełnie. Płytka przestała odpowiadać na pingi,
nie mogłem się dostać do webUI, również kod kliencki na MCU przestał
otrzymywać dane z internetu. W momencie wystąpienia awarii dioda ACT na
gniazdku Ethernetowym zaczęła się świecić cały czas. Co więcej - parę
razy awaria spowodowała wykrzaczenie się komunikacji po Ethernecie na
wszystkich urządzeniach podpiętych do tego samego routera!

Nie był to jednak całkowity zawias - ciągle mogłem wydawać polecenia w
konsoli UART i otrzymywałem sensowne odpowiedzi.

Raczej nie jest to wina sprzętu, bo na starym sofcie (biblioteki MLA)
płytka była testowana miesiącami i zawsze działała stabilnie. Taki
problem nigdy nie wystąpił. Odnoszę też wrażenie, że prawdopodobieństwo
wystąpienia awarii jest silne skorelowane z ilością przesyłanych danych
- problem występował zawsze podczas odtwarzania streamu audio z sieci
(radio internetowe po HTTP).

Jakiś czas temu złożyłem sobie projekt radia internetowego/odtwarzacza
MP3 z wykorzystaniem mikrokontrolera PIC32MX795F512L i układu Ethernet
PHY DP83848. Firmware napisałem przy użyciu starych bibliotek MLA.
Wszystko działało całkiem sprawnie.
Później powstała nowsza wersja hardware'u, wykorzystująca znacznie
mocniejszy PIC32MZ2048EFM100 i bibliotekę Harmony. Sprawdzała się ona
znacznie lepiej - chociażby z uwagi na domyślne wykorzystanie RTOS-a.

Ostatnio postanowiłem backportować nową wersję softu pod stary hardware.
Z czystej ciekawości chciałem się przekonać jak dobrze starszy MCU
będzie sobie radził z nowymi bibliotekami. Gdyby eksperyment się udał,
to potencjalnie mógłbym wykorzystać w przyszłych projektach tych kilka
scalaków leżących w szufladzie. ;)

Oczywiście głównym problemem były mniejsze zasoby sprzętowe. O ile
PIC32MZ2048EFM100 miał 2MB flasha i 512kB RAMu, to PIC32MX795F512L ma
odpowiednio tylko 512kB i 128kB. Program się zmieścił, zajmując jakieś
75% flasha. Zmniejszając rozmiar kilku statycznych buforów, manipulując
rozmiarem sterty i rozmaitymi ustawieniami w konfiguracji udało mi się
także (chyba) upchnąć wszystko w RAM-ie.

Pierwsze wrażenie były jak najbardziej pozytywne. Oprogramowanie
działało na starym sprzęcie zaskakująco dobrze. Powiedziałbym nawet, że
lepiej niż na starych bibliotekach, co zapewne jest zasługą RTOS-a
(różne procesy wykonują się równolegle i np. stos TCP/IP nie łapie
przestoju, gdy inny proces utyka w jakiejś dłuższej pętli).

Dzisiaj jednak kilkukrotnie zaobserwowałem dziwną awarię: komunikacja po
sieci wykrzaczyła się zupełnie. Płytka przestała odpowiadać na pingi,
nie mogłem się dostać do webUI, również kod kliencki na MCU przestał
otrzymywać dane z internetu. W momencie wystąpienia awarii dioda ACT na
gniazdku Ethernetowym zaczęła się świecić cały czas. Co więcej - parę
razy awaria spowodowała wykrzaczenie się komunikacji po Ethernecie na
wszystkich urządzeniach podpiętych do tego samego routera!
Nie był to jednak całkowity zawias - ciągle mogłem wydawać polecenia w
konsoli UART i otrzymywałem sensowne odpowiedzi.

Raczej nie jest to wina sprzętu, bo na starym sofcie (biblioteki MLA)
płytka była testowana miesiącami i zawsze działała stabilnie. Taki
problem nigdy nie wystąpił. Odnoszę też wrażenie, że prawdopodobieństwo
wystąpienia awarii jest silne skorelowane z ilością przesyłanych danych
- problem występował zawsze podczas odtwarzania streamu audio z sieci
(radio internetowe po HTTP). Chociaż ta hipoteza musi jeszcze zostać
przetestowana, to na razie urządzenie działa odtwarzając lokalne pliki i
problem jeszcze nie wystąpił.

Ktoś ma jakąś hipotezę? Gdzie szukać potencjalnej przyczyny?
Po co ci takie coś co nazwales radiem a nie napisałeś czy wydaje jakieś dźwięki poza tym że ciągle w nim coś nie działa. Czy czasami ono nie jest z tej samej serii co traktor co ma trzy koła dobre?

Po co ci takie coś co nazwales radiem a nie napisałeś czy wydaje
jakieś dźwięki poza tym że ciągle w nim coś nie działa. Czy czasami
ono nie jest z tej samej serii co traktor co ma trzy koła dobre?

On 10.04.2023 00:11, Zenek Kapelinder wrote:

Po co ci takie coś co nazwales radiem a nie napisałeś czy wydaje
jakieś dźwięki poza tym że ciągle w nim coś nie działa. Czy czasami
ono nie jest z tej samej serii co traktor co ma trzy koła dobre?
Oczywiście, że wydaje dźwięki. Skąd pomysł, że mogłoby być inaczej?
Stream audio odbierany przez HTTP (albo odczytywany z pliku) jest
kierowany do bufora cyklicznego, skąd trafia do dekodera VS1003 i na
głośniki.
Jak działa to czy po tym jak roztrajbujesz ferszluz żeby droselklapa mniej o może wcale nie ryksztosowala będą w nim lepsze dla ciebie wiadomości? Albo muzyka symfoniczna przesyłana do głośników kablami że zwykłej miedzi będzie brzmiała jak by była przesyłana kablami z miedzi wytapianiej na międzynarodowej stacji kosmicznej?

Pomysl pierwszy - brak pamieci. Mozesz tam jakąs czujke dodac, która
diode zapali czy na konsole napisze, jak zacznie brakowac?

On 9.04.2023 20:09, J.F wrote:
Pomysl pierwszy - brak pamieci. Mozesz tam jakąs czujke dodac, która
diode zapali czy na konsole napisze, jak zacznie brakowac?

Wygląda na to, że namierzyłem przyczynę. Jeszcze nie na 100%, bo będę
musiał przeprowadzić dłuższe testy, jednak jak na razie urządzenie
działa od kilku godzin i problem nie wystąpił.

Po pierwsze potwierdziłem, że problem pojawiał się podczas odtwarzania
streamów z sieci. Prada w trybie "idle" albo odtwarzanie audio z
lokalnego nośnika nie powodowało jego wystąpienia.
Przyjrzałem się więc różnicom pomiędzy oryginalną wersją softu (z
PIC32MZ2048) a tą zmodyfikowaną pod PIC32MX795F512L. Jedną różnic było
ograniczenie rozmiaru bufora odbiorczego w gnieździe sieciowym z 4096 do
2048 bajtów. Po przywróceniu poprzedniego rozmiaru problem przestał
występować, a przynajmniej nie pojawił się w ciągu kilku godzin testów.

Jest to o tyle dziwne, że wartość domyślna wynosi 512 bajtów, jednak
przy niej stos nie radzi sobie z odbieraniem streamu audio w czasie
rzeczywistym i słychać wyraźne przycięcia.

Nie mam jednak pojęcia w jaki sposób za mały bufor może powodować taką
awarię - wykrzaczenie się całego stosu i zakłócenie działania innych
urządzeń na okolicznym Ethernecie.

poniedziałek, 10 kwietnia 2023 o 09:35:57 UTC+2 Atlantis napisał(a):
On 10.04.2023 00:11, Zenek Kapelinder wrote:

Po co ci takie coś co nazwales radiem a nie napisałeś czy wydaje
jakieś dźwięki poza tym że ciągle w nim coś nie działa. Czy czasami
ono nie jest z tej samej serii co traktor co ma trzy koła dobre?
Oczywiście, że wydaje dźwięki. Skąd pomysł, że mogłoby być inaczej?
Stream audio odbierany przez HTTP (albo odczytywany z pliku) jest
kierowany do bufora cyklicznego, skąd trafia do dekodera VS1003 i na
głośniki.
Jak działa to czy po tym jak roztrajbujesz ferszluz żeby droselklapa mniej o może wcale nie ryksztosowala będą w nim lepsze dla ciebie wiadomości? Albo muzyka symfoniczna przesyłana do głośników kablami że zwykłej miedzi będzie brzmiała jak by była przesyłana kablami z miedzi wytapianiej na międzynarodowej stacji kosmicznej?

On Mon, 10 Apr 2023 01:49:27 -0700 (PDT), Zenek Kapelinder wrote:
poniedziałek, 10 kwietnia 2023 o 09:35:57 UTC+2 Atlantis napisał(a):
On 10.04.2023 00:11, Zenek Kapelinder wrote:

Po co ci takie coś co nazwales radiem a nie napisałeś czy wydaje
jakieś dźwięki poza tym że ciągle w nim coś nie działa. Czy czasami
ono nie jest z tej samej serii co traktor co ma trzy koła dobre?
Oczywiście, że wydaje dźwięki. Skąd pomysł, że mogłoby być inaczej?
Stream audio odbierany przez HTTP (albo odczytywany z pliku) jest
kierowany do bufora cyklicznego, skąd trafia do dekodera VS1003 i na
głośniki.
Jak działa to czy po tym jak roztrajbujesz ferszluz żeby droselklapa mniej o może wcale nie ryksztosowala będą w nim lepsze dla ciebie wiadomości? Albo muzyka symfoniczna przesyłana do głośników kablami że zwykłej miedzi będzie brzmiała jak by była przesyłana kablami z miedzi wytapianiej na międzynarodowej stacji kosmicznej?
Chcial miec chłop wlasny "odbiornik internetowy", to ma, nie jest juz
skazany na sklepowe ... ktore nie wiadomo kiedy przestana dzialac.

J.
Jak do mnie piszesz to przedtem jakieś tabletki na dysleksję bierzesz? Wiesz że z tobą nie gadam to po chuj się wpierdalasz? Uznaj że miły byłem.