eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaPIC32MX795F512 + DP83848: Zawieszanie się Ethernetu › Re: PIC32MX795F512 + DP83848: Zawieszanie się Ethernetu
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!.POSTED.cdh119.neoplus.adsl.tpnet.pl!no
    t-for-mail
    From: Atlantis <m...@w...pl>
    Newsgroups: pl.misc.elektronika
    Subject: Re: PIC32MX795F512 + DP83848: Zawieszanie się Ethernetu
    Date: Thu, 15 Feb 2024 20:43:51 +0100
    Organization: ICM, Uniwersytet Warszawski
    Message-ID: <uqlphn$2tg8a$1@news.icm.edu.pl>
    References: <uprd7p$fh7k$1@news.icm.edu.pl> <uptvqs$136nb$1@news.icm.edu.pl>
    <a...@n...icm.edu.pl>
    <upvga5$161s7$1@news.icm.edu.pl>
    <a...@n...icm.edu.pl>
    <uq3cvi$1fum3$1@news.icm.edu.pl> <uq5t0i$1kius$1@news.icm.edu.pl>
    <a...@n...icm.edu.pl>
    <uq7so1$1s6kn$1@news.icm.edu.pl> <uq8ej9$1u14v$1@news.icm.edu.pl>
    <a...@n...icm.edu.pl>
    <uqalsh$2356t$1@news.icm.edu.pl> <uqanuk$99f$1$Mirek@news.chmurka.net>
    Mime-Version: 1.0
    Content-Type: text/plain; charset=UTF-8; format=flowed
    Content-Transfer-Encoding: 8bit
    Injection-Date: Thu, 15 Feb 2024 19:43:51 -0000 (UTC)
    Injection-Info: news.icm.edu.pl;
    posting-host="cdh119.neoplus.adsl.tpnet.pl:83.30.157.119";
    logging-data="3064074"; mail-complaints-to="u...@n...icm.edu.pl"
    User-Agent: Mozilla Thunderbird
    Content-Language: en-US, pl-PL
    In-Reply-To: <uqanuk$99f$1$Mirek@news.chmurka.net>
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:789009
    [ ukryj nagłówki ]

    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.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: