On 16.02.2024 00:46, Atlantis wrote:

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

do góry

On 2024-02-16 02:14, Atlantis wrote:
> 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.

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

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

do góry

On 16.02.2024 19:51, Mirek wrote:

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


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

do góry

On 17.02.2024 03:04, ptoki wrote:

> 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

Z tego schematu wynika, że interfejs SPI jest wyprowadzony na złącze
JP2. Po prostu nie jest to zrobione bezpośrednio, ale za pośrednictwem
bufora 74HC4050. W ten sposób ludzie z Adafruit zadbali o to, żeby moduł
mógł działać także z płytkami Arduino, działającymi na logice 5V.
Wyjątek stanowią tutaj linie DREQ oraz MISO, które są podłączone
bezpośrednio, ale w tą stronę Arduino powinno być w stanie poprawnie
rozpoznać sygnały.

do góry

On 2024-02-18 03:27, Atlantis wrote:
> On 17.02.2024 03:04, ptoki wrote:
>
>> 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
>
> Z tego schematu wynika, że interfejs SPI jest wyprowadzony na złącze
> JP2. Po prostu nie jest to zrobione bezpośrednio, ale za pośrednictwem
> bufora 74HC4050. W ten sposób ludzie z Adafruit zadbali o to, żeby moduł
> mógł działać także z płytkami Arduino, działającymi na logice 5V.
> Wyjątek stanowią tutaj linie DREQ oraz MISO, które są podłączone
> bezpośrednio, ale w tą stronę Arduino powinno być w stanie poprawnie
> rozpoznać sygnały.
>

Aaaa teraz widze to miso.
Dzieki. Wczesniej jak patrzylem to nie widzialem napisu...
--
Lukasz

do góry

W końcu znalazłem trochę czasu, żeby podłączyc płytkę przez laptopa i
przechwycić pakiety. Konfiguracja wygląda następująco:

1. Stary ThinkPad x201 podpięty do switacha w miejscu, w którym
oryginalnie podłączona była płytka.
2. Płytka podłączona do dodatkowej karty sieciowej na USB, za
pośrednictwem scrossowanego kabla.
3. Na laptopie ustawiony bridge pomiędzy obydwiema kartami sieciowymi.
3. Ruch zbierany z karty USB za pomocą tcpdump.

Zestaw chodzi tak już tak prawie cztery doby. Przez ten czas nic nie
wywaliło się ani razu. Można chyba mówić o nowym rekordzie, bo do tej
pory najdłużej poprawne działanie obserwowałem przez jakieś trzy dni, a
zwykle problem pojawiał się po dniu, lub nawet częściej.

Zostawię go tak jeszcze przez kilka dni, może jeszcze uda się ponownie
zreplikować błąd. Co jeśli nie będzie on chciał wystąpić? Czy sam fakt
poprawnego działania na takim "układzie testowym" może coś powiedzieć?

do góry

On 22.02.2024 16:51, Atlantis wrote:

> Czy sam fakt
> poprawnego działania na takim "układzie testowym" może coś powiedzieć?

Może sam układ PHY z przyległościami to powoduje?
Skoro zapala ci się ACK na stałe - to chyba on tym steruje?
Podłączenie w innej konfiguracji może zmniejszyć zakłócenia albo
szkodliwe potencjały i usterka może się nie objawić.
Musisz testować - przynajmniej dwukrotność najdłuższego czasu między
usterkami, później odtworzyć warunki ostatniej usterki i znów czekać.

--
Mirek.

do góry

On 22.02.2024 19:29, Mirek wrote:
> On 22.02.2024 16:51, Atlantis wrote:
>
>> Czy sam fakt poprawnego działania na takim "układzie testowym" może
>> coś powiedzieć?
>
> Może sam układ PHY z przyległościami to powoduje?
Dawno temu pewna firma do pewnego swojego produktu postanowiła dodać
jako opcję moduł Ethernetu. Jak postanowiono, tak zrobiono.
Zaprojektowano, oprogramowano i wyprodukowano trochę modułów na RTL8019.
Wszystko było mniej więcej OK. Mniej więcej, bo czasami Ethernet nie
chciał działać z powodów nieznanych. Ja (softłerowiec) z pomocą kolegi
hardłerowca (który projektował ten moduł jak i całe urządzenie zresztą)
dostaliśmy za zadanie zdebugowanie problemu. Po jakichś dwóch czy trzech
dniach walki zdesperowany odkryłem, ze kolega hardłerowiec nie
przemalował z noty aplikacyjnej kości oporka 200 ?, który znajdował się
na wejściu pomiędzy pinami TPIN+ i TPIN-. Po dolutowaniu oporka problemy
zniknęły jak ręką odjął. No i na produkcji musieli trochę więcej tych
oporków polutować, bo to było na niedługo przed wypuszczeniem produktu
na rynek i troche elektroniki firma już zdążyła naklepać. :-) Ot, tak
historyjka do rozważenia.

do góry

On 23.02.2024 16:33, JDX wrote:

> oporków polutować, bo to było na niedługo przed wypuszczeniem produktu
> na rynek i troche elektroniki firma już zdążyła naklepać. :-) Ot, tak
> historyjka do rozważenia.

Teoretycznie możliwe. Biorę pod uwagę opcję, że wina może leżeć po
stronie jakiejś pomyłki przy budowaniu/konstruowaniu hardware'u. Jednak
jest kilka "ale", które zdają się przeczyć tej hipotezie.

1. Nie przypominam sobie, żeby problem kiedykolwiek wystąpił na starej
wersji oprogramowania, na którym nie było jeszcze FreeRTOS-a, a zamiast
Harmony3 były użyte stare biblioteki MLA (w tym sterownik MAC/PHY i stos
TCP/IP). Jak inne opcje zawiodą, to poszukam tej starej wersji softu i
wykonam na nim kilkudniowe testy.
2. Istnieje nowsza wersja hardware z PIC32MZ2048. To właściwie ta sama
płytka, w której podmieniony został mikrokontroler. Część z PHY
właściwie nie zmieniła się ani trochę. Możliwość mapowania pinów MCU
pozwoliła nieco zoptymalizować prowadzenie części ścieżek i przez to
linie interfejsu RMII udało się nieznacznie skrócić, ale poza tym
istotnych różnic nie ma. Ta wersja płytki działa zupełnie poprawnie.
3. Identyczny design części PHY stosowałem też w kilku projektach z
STM32F1xx i STM32F4xx. Tam problem także nigdy nie wystąpił.

Jak na razie w tym "układzie testowym" urządzenie pracuje już szósty
dzień i nigdy nie zaliczyło crasha. Jeszcze dam mu parę dni, ale zaczyna
to wyglądać tak, jakby połączenie w tanią kartą Ethernet na USB za
pomocą scrossowanego kabla było środowiskiem odpornym na ten problem.
Problem występuje za to na kilku tanich switchach TP-Link 100 Mpbs oraz
nieco nowszym routerze - również TP-Link, ale już z gigabitowym Ethernetem.

Nie wiem czy w ramach testu nie wyciągnę pudełka lepszego rackowego
switcha (kupiony jakiś czas temu z myślą o modernizacji sieci w domu, za
którą nie mogę się zabrać) i zobaczę czy nam nim problem też będzie
występował.

do góry

On Sat, 24 Feb 2024 22:28:01 +0100, Atlantis <m...@w...pl>
wrote:
> istotnych różnic nie ma. Ta wersja płytki działa zupełnie poprawnie.

Zaraz zaraz, działa poprawnie z tym samym softem?

--
Marek

do góry