On 25.02.2024 09:41, Marek wrote:

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

Nie, nie tym samym. A przynajmniej nie do końca.
Nie mogę tak po prostu przenieść projektu Harmony z PIC32MX795F512L na
PIC32MZ2048. Niskopoziomowe sterowniki trzeba wygenerować jeszcze raz.
Proces przenoszenia kodu wyglądał następująco:
1. Utworzyłem czysty projekt Harmony na PIC32MZ2048.
2. Zaimportowałem do niego konfigurację MHC (Microchip Harmony
Configurator) z wersji na PIC32MZ2048.
3. Jeszcze raz sprawdziłem i dostosowałem niektóre ustawienia
konfiguracji. Trzeba było uwzględnić różnice wynikające z użycia innych
pinów GPIO czy niektórych interfejsów. Dużo więcej RAM-u pozwoliło mi
też rozszerzyć nieco stertę.
4. Wygenerowałem i skompilowałem "czysty" projekt. Na tym etapie miałem
już w pełni działające peryferia. Między innymi praktycznie bezobsługowo
zaczęła działać łączność sieciowa.
5. Stopniowo zintegrowałem z tym czystym projektem kod mojej aplikacji,
przeniesiony ze starszej wersji. W większości przypadków wystarczyło
skopiować i dodać do projektu pliki z kodem źródłowym, ewentualnie
powklejać gdzieniegdzie jego fragmenty, co najwyżej uważając na niektóre
define'y, odnoszące się do różnic sprzętowych.

Tak więc reasumując:
- Warstwa sterowników została wygenerowana przez MHC dla nowego MCU, ale
na podstawie praktycznie tej samej konfiguracji (z drobnymi zmianami).
- Warstwa aplikacji została przeniesiona ze starszej wersji ręcznie (z
uwzględnieniem pewnych zmian w warstwie sprzętowej).

W ten sam sposób przeniosłem projekt także na starszą wersję płytki z
ENC28J60. Płytki z PIC32MX795F512L+ENC28J60 i PIC32MZ2048+DP83848
działają w tej chwili perfekcyjnie stabilnie. Płytka z
PIC32MX795F512L+DP83848 ma ten dziwny problem z okazjonalnym wywalaniem
łączności na poziomie switcha.

do góry

On 22.02.2024 19:29, Mirek wrote:

> Może sam układ PHY z przyległościami to powoduje? (...)
> Musisz testować - przynajmniej dwukrotność najdłuższego czasu między
> usterkami, później odtworzyć warunki ostatniej usterki i znów czekać.

Finalnie urządzenie chodziło podłączone do laptopa w Wiresharkiem przez
trochę ponad tydzień. Problem nie pojawił się ani razu, wszystko
działało perfekcyjnie stabilnie.
Potem podłączyłem płytkę do nieco lepszego gigabitowego switcha (TP-Link
TL-SG1024D). Od tego momentu minęły już prawie trzy doby i jak dotąd
problem nie wystąpił. Jeszcze za wcześnie, żeby to stwierdzać ze 100%
pewnością, ale trochę wygląda na to, że źródło problemu jest związane z
najniższą warstwą. Najwyraźniej znaczenie ma to, co znajduje się po
drugiej stronie kabla Ethernetowego.
Awaria nie wystąpiła po podłączeniu crossem do taniej karty USB Ethernet
wpiętej w laptopa oraz (przynajmniej jak na razie) do lepszego switcha.
Występowała natomiast w przypadku domowego routera oraz tanich, starych,
plastikowych 100Mbps switchy TP-Linka.

Skoro nie udało mi się zebrać ruchu na interfejsie sieciowym samej
płytki w momencie awarii, w dalszej kolejności spróbuję zrobić kolejną
najlepszą rzecz - zobaczę jak to wygląda z perspektywy jednego z
komputerów podpiętych do tego samego switcha w momencie, gdy pada łączność.

do góry

On 28.02.2024 19:21, Atlantis wrote:

> Awaria nie wystąpiła po podłączeniu crossem do taniej karty USB Ethernet
> wpiętej w laptopa oraz (przynajmniej jak na razie) do lepszego switcha.
> Występowała natomiast w przypadku domowego routera oraz tanich, starych,
> plastikowych 100Mbps switchy TP-Linka.

Ale mówimy tu o utracie możliwości zainicjowania połączenia przy
jednoczesnej możliwości połączenia do urządzenia czy o całkowitym
zablokowaniu ethernetu - bo już się pogubiłem (i możliwe że sam to
poknociłem)?

Dwie uwagi:
Dawno nie widziałem urządzenia, które wymaga kabla cross (chyba że PoE)
Te ogonki usb <> ethernet bywają tak podłe, że nie mają nawet
transformatorków - jaja są z potencjałami.

Tak jeszcze BTW: widziałem już różne cuda z ethernetem, np zdarzyła mi
się kamera, która działała parę lat na odwróconej parze 1-2
(biało-pomarańczowy zamieniony z pomarańczowym z jednej strony). Klient
skarżył się, że czasem się zwiesza, ale to było raz na parę tygodni i
pomagał restart switcha PoE. Aż któregoś pięknego dnia po burzy padł
rzeczony switch - wymieniamy, ale ta jedna kamera nie wstaje.
Podmieniamy kamerę... nie wstaje. Sprawdzamy kabel... szczena nam opada
bo jest odwrócona para. Poprawiamy, podłączamy starą kamerę, która
działa i już się później nie zawiesza.

--
Mirek

do góry

On 28.02.2024 19:52, Mirek wrote:

> Ale mówimy tu o utracie możliwości zainicjowania połączenia przy
> jednoczesnej możliwości połączenia do urządzenia czy o całkowitym
> zablokowaniu ethernetu - bo już się pogubiłem (i możliwe że sam to
> poknociłem)?

Mówimy o całkowitym zablokowaniu Ethernetu na poziomie całego switcha.
Dioda ACT na urządzeniu zaczyna się świecić cały czas, a ono samo traci
kontakt z siecią. Jednocześnie łączność tracą wszystkie inne urządzenia,
podłączone do tego samego switcha.
Problem z zainicjowaniem połączenia klienta był osobną kwestią, o której
wspominałem przy okazji. Najwyraźniej ustąpił po wgraniu poprawek kilku
błędów, które zauważyłem w międzyczasie (najpewniej chodziło o
korzystanie z malloc/free zamiast pvPortMalloc/vPortFree).


> Dwie uwagi: Dawno nie widziałem urządzenia, które wymaga kabla cross
> (chyba że PoE)

Tak, wiem. Ale to raczej siła przyzwyczajenia. Skoro miałem pod ręką
scrossowany kabel, to postanowiłem go wykorzystać, skoro już łączyłem
urządzenia bezpośrednio.
Raczej w niczym to nie zaszkodziło, a połączenie przez tydzień działało
stabilnie.


> Te ogonki usb <> ethernet bywają tak podłe, że nie mają nawet
> transformatorków - jaja są z potencjałami.

No cóż, to było jedynie urządzenie, jakie miałem pod ręką do
wykorzystania na szybko. No i jak mówię - w tym wypadku się sprawdziło.
A w tym konkretnym przypadku transformatorek jest - widać do przez
półprzezroczystą obudowę. ;)


> tygodni i pomagał restart switcha PoE. Aż któregoś pięknego dnia po
> burzy padł rzeczony switch - wymieniamy, ale ta jedna kamera nie
> wstaje. Podmieniamy kamerę... nie wstaje. Sprawdzamy kabel... szczena
> nam opada bo jest odwrócona para. Poprawiamy, podłączamy starą
> kamerę, która działa i już się później nie zawiesza.

Też o tym pomyślałem, ale taką opcję wyeliminowałem na samym początku,
testując z kilkoma różnymi kablami i switchami. Tak więc to nie jest
kwestia niekontaktującego styku, złego kabla albo uwalonego portu w switchu.

Prawdę mówiąc stawiałem na to, że przyczyna będzie leżała na warstwie
MAC lub wyżej. Ten sam układ PHY (DP83848) wykorzystałem już w kilku
różnych projektach, z kilkoma różnymi MCU, używając identycznego układu
ścieżek na PCB (oczywiście z pominięciem linii interfejsu RMII, które są
unikalne dla konkretnego typu mikrokontrolera) i podobny problem nigdy
nie wystąpił. Stawiałem albo na jakiś bug programowy, albo problem z
kontrolerem MAC w strukturze PIC32MX795F512, albo ewentualnie jakiś
problem na liniach interfejsu RMII. Wtedy jednak awaria powinna wystąpić
też przy testach z laptopem.
Tymczasem to zaczyna wyglądać na problem na warstwie fizycznej,
ograniczony do sytuacji, kiedy po drugiej stronie kabla znajdują się
dość konkretne urządzenia...

do góry

On 28.02.2024 21:47, Atlantis wrote:

> Mówimy o całkowitym zablokowaniu Ethernetu na poziomie całego switcha.
> Dioda ACT na urządzeniu zaczyna się świecić cały czas, a ono samo traci
> kontakt z siecią. Jednocześnie łączność tracą wszystkie inne urządzenia,
> podłączone do tego samego switcha.

A diodka na switchu? Też się świeci ciągle czy mruga nerwowo?
A diodki od innych portów?
Typowy dla prostych switchów jest brak odporności na pętlę, czyli
spinasz dwa porty kablem... i nic się nie dzieje, bo prosty switch nie
wygeneruje sam żadnego pakietu, ale wystarczy wpuścić jeden broadcast i
będzie krążył tym kablem i jak to broadcast będzie się powielał na
wszystkich portach. Na inne pakiety już nie starczy pasma albo mocy
procesora switcha. To samo może się stać jak zapętlisz tx z rx w jednym
porcie.

--
Mirek

do góry

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.


> Typowy dla prostych switchów jest brak odporności na pętlę, czyli
> spinasz dwa porty kablem... i nic się nie dzieje, bo prosty switch
> nie wygeneruje sam żadnego pakietu, ale wystarczy wpuścić jeden
> broadcast i będzie krążył tym kablem i jak to broadcast będzie się
> powielał na wszystkich portach. Na inne pakiety już nie starczy pasma
> albo mocy procesora switcha.
Hipoteza brzmi sensownie. Tylko w takim razie dlaczego problem nie
wystąpił ani razu, gdy przez tydzień cały ruch przechodził przez
bridge'a ustawionego na laptopie? Jeśli dobrze rozumiem, bridge powinien
być przezroczysty i przepuszczać te broadcastowe pakiety, co powinno
doprowadzić do zablokowania switcha w taki sam sposób, jak miało to
miejsce przy bezpośrednim połączeniu.


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

do góry

On 28.02.2024 22:28, Atlantis wrote:
>
> 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.


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

do góry

No cóż... Urządzenie w chwili obecnej pracuje już ponad tydzień podpięte
do lepszego, gigabitowego switcha. Wygląda więc na to, że problem z
zawieszaniem się i wywalaniem komunikacji na całym switchu dotyczy tylko
niektórych modeli.
Ciekawe co może powodować takie zachowanie...

do góry

On 2024-03-05 15:00, Atlantis wrote:
> No cóż... Urządzenie w chwili obecnej pracuje już ponad tydzień podpięte
> do lepszego, gigabitowego switcha. Wygląda więc na to, że problem z
> zawieszaniem się i wywalaniem komunikacji na całym switchu dotyczy tylko
> niektórych modeli.
> Ciekawe co może powodować takie zachowanie...

Kiedys mi znajomy mowil ze jakis soft sie wywalal ale nie dalo sie tego
zdebugowac bo jak lecial przez strace to sie nie wywalal.

Pewnie jakies warunki wyscigowe i strace spowalnialo nieco te krytyczna
czesc. Ale tak to czasem jest, mierzysz i wplywasz na uklad.
--
Lukasz

do góry

W końcu udało mi się podejrzeć sytuację podczas awarii. Jak wspominałem,
nie byłem w stanie zreplikować problemu z laptopem wpiętym pomiędzy
urządzenie a switcha. Zrobiłem więc kolejną najlepszą rzecz - zobaczyłem
co się dzieje na interfejsie sieciowym komputera, który jest podłączony
do wspomnianego switcha.
Okazuje się, że jest on spamowany znaczną liczbą następujących wiadomości:

Source: 00:00:00_00:00:01
Destination: MAC-specific-ctrl-proto-01
Protocol: MAC CTRL
Length: 60
Info: Pause: pause_time: 65535 quanta

Hex dump przykładowej ramki:

0000 01 80 c2 00 00 01 00 00 00 00 00 01 88 08 00 01
0010 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00

Ktoś ma jakiś pomysł co do przyczyny takiego zachowania?

do góry