Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[Rozwiązano] [XMEGA][C]losowe zachowanie modułu Ethernet W5100

joik123 29 Sie 2018 19:11 189 4
  • #1 29 Sie 2018 19:11
    joik123
    Poziom 9  

    Witam,
    Mam problem odnośnie modułu W5100. Mianowicie, po fizycznym resecie modułu (przycisk), moduł zachowuje się w 3 bliżej określonych stanach:
    1. działa stabilnie - nie mam nic do zarzucenia
    2. działa, ale odbiera tylko niektóre ramki
    3. nie działa

    Opis:
    Z komputera, za pomocą skryptu, wysyłam ramki w odstępie 100ms do płytki z W5100 i mikrokontrolerem ATXmega128A1U. Wykorzystuje protokół UDP. Na samym początku programu w xmega inicjalizuję SPI, W5100, oraz przerwanie od W5100 na odpowiednim pinie. Po zainicjalizowaniu modułów mam pętlę while jedynie z opóźnieniem i miganiem diody(aby wykryć zawieszenie programu). W procedurze obsługi przerwania od W5100 zmieniam wyjście pinu na przeciwny (odpowiadający za inną diodę) i zeruję rejestr przerwań odpowiedniego socketu w W5100. Prosty program. Po wejściu w pętle while program nie korzysta już z SPI bo nie musi - rejestruję tylko przerwanie INT z W5100 i na podstawie zmiany szybkości diody wiem czy dane dobrze odbiera czy nie.

    Problem:
    Przy niektórych resetach program działa wręcz idealnie - miganie diody odpowiada dokładnie wysyłanym ramkom, następnie dochodzi do końca bufora RX i jest błąd(co jest normalne).
    W niektórych przypadkach dioda miga bardzo rzadko (ok raz na 5-20 ramek) i bardzo nieregularnie.
    Po niektórych restartach dioda nie miga - program działa normalnie, lecz nie ma przerwań od W5100 - nawet zmierzyłem poziom napięcia na pinie /INT od W5100 - wynosi ok 3,2V :P

    W tych trzech wypadkach używam tego samego programu na AVR tego samego skryptu na PC i tylko za pośrednictwem przycisku wymuszam reset który jest resetem jednocześnie dla xmegi i w5100.
    Oczywiście używam także programowego resetu na początku inicjalizacji w5100 w programie zapisując 7 bit rejestru MR '1'.

    Borykam się z tym problemem już dość długo ...zdecydowanie za długo :D. Ktoś ma jakieś doświadczenia z podobnym zachowaniem W5100?
    Z góry dziękuję za odpowiedź.
    Pozdrawiam.

    0 4
  • #2 29 Sie 2018 23:50
    michalko12
    Specjalista - Mikrokontrolery

    Gdybyś sam przeczytał taki opis problemu to co byłbyś w stanie odpowiedzieć autorowi?

    Zwolnij SPI, powstawiaj większe timeouty w trakcie inicjalizacji i po resetach. Po załączeniu zasilania też wydłuż czas po którym procesor będzie cokolwiek robił z W5500. Jeśli to nie zadziała to znaczy, że masz skopaną inicjalizację.

    0
  • #3 31 Sie 2018 20:14
    joik123
    Poziom 9  

    Zrobiłem wszystko co pisałeś, a także masę innych testów z których wynikło, że komunikacja zawsze działa ale tylko z W5100 do komputera, natomiast problem jest "jedynie" w ramkach przychodzących. Dodatkowo przetestowałem ten sam program na arduino UNO i ethernet shield i po fizycznym resecie (przyciskiem) W5100 działał bez zarzutu, lecz wtedy gdy odłączałem i załączałem zasilanie problem powrócił z tymi samymi objawami. Postanowiłem odgiąć 2 piny z nakładki odpowiadające za reset i wykonać "fizyczno - programowy" reset W5100 przez podłączenie pinu resetu z chipu do jednej z nóżek mikrokontrolera. Podziałało. Przeprowadziłem kilkadziesiąt testów (zanik zasilania, odłączenie kabla, reset arduino), w których nie stwierdziłem nieprawidłowości. Więc sama konfiguracja jest ok. Ten sam zabieg zastosowałem na płytce uC xmega niestety bez większego rezultatu :(.
    Z tego wnioskuję, że są 2 możliwe przyczyny: SPI w xmega lub sam w5100.
    Porównałem schemat nakładki arduino i fragment płytki gdzie jest w5100. Oprócz kilku kondensatorów zabezpieczających na 2 pinach istotną różnicą jest jedynie zastosowanie układu przerzutnika Schmitta na pinie SEN. Co do konfiguracji SPI mam mieszane uczucia, bo mam kości pamięci SRAM na SPI i działają bez zarzutu, tylko że na innych portach, a poza tym non stop wysyłam ramki przez SPI do W5100 i chip zawsze przekazuje ramkę do komputera.
    Trochę zawiły problem. Pozostaje jeszcze wymiana W5100, ale dalej myślę że jest to programowy błąd, tylko nadal nie wiem jaki.
    Sprawdziłem zasilanie płytki xmega oscyloskopem i nie ma żadnych szpilek napięcia, a dodatkowo na tym samym źródle uruchomiłem arduino uno z nakładką ethernet i również nie było żadnych błędów.
    Macie jakieś pomysły?

    Mój kod:
    Zmieniłem trochę bibliotekę celem testów - uprościłem ją celem wyeliminowania błędów. Zmieniłem jedynie funkcje W51_write i W51_read oraz w W51_config - dodałem ustawianie docelowego IP i portu.

    Pozdrawiam.

    0
  • #4 05 Wrz 2018 17:42
    joik123
    Poziom 9  

    Przyprowadzając różnorakie testy, spróbowałem zmienić prędkość transmisji Ethernet. O dziwo wszystko działa tak, jak powinno na 10Mbit/s. Co potwierdza, że transmisja po SPI i konfiguracja są w porządku. Zauważyłem także, że na 100Mbit/s po zawieszce W5100 i zrobieniu link down i link up (wyciągniecie i włożenie kabla) zazwyczaj zaczyna działać poprawnie, aż do kolejnego feralnego restartu. Czy to może być wina zasilania? Na pinie zasilającym jest szereg kondensatorów, a zasilanie jest z liniowego stabilizatora na 3.3V. Jak ewentualnie sprawdzić czy z zasilaniem jest wszystko ok?
    Ktoś może wie, co dzieje się z W5100 po wyciągnięciu i włożeniu kabla, bo nie mogę tego w datashieet-cie znaleźć.
    Pozdrawiam.

    EDIT:
    Na jednej forum chyba znalazłem rozwiązanie mojego problemu. Chodzi o "Auto-negotiation" prędkości. Niektóre chipy miały z tym problem i po prostu trzeba było ustawić na stałe 100Mbit/s lub 10Mbit/s doprowadzając nóżki 65, 64, 63 do odpowiedniego poziomu napięć.

    0
  • #5 07 Wrz 2018 18:52
    joik123
    Poziom 9  

    Problem tkwił w błędzie auto-negocjacji na poziomie chip-a W5100.

    0