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.

[MMnetSAM7X Propoxu, FreeRTOS demo] reset połączenia LAN

nyxnyx 14 Gru 2009 09:46 2529 13
  • #1 14 Gru 2009 09:46
    nyxnyx
    Poziom 9  

    Witam,
    czy komukolwiek udało się uruchomić ten moduł?
    Otóż podłączam moduł do płytki na której mam podane zasilanie 3.3 V (zasilam z USB).
    Moduł startuje, świeci się czerwona dioda. Po wgraniu oprogramowania (demo z FreeRTOS z obsługą sieci + obsługa usb) po podłączeniu do komputera moduł jest widziany jako urządzenie USB.
    Stan interfejsu Ethernet jest sygnalizowany przez 3 diody:
    1. zielona na module - oznaczona FULL
    2. zielona w gniazdku
    3. pomarańczowa w gniazdku

    Problem dotyczy ethernetu. Na module jest Davicom DM9161. Sprawdzam, czy w kodzie FreeRTOS jest on obsługiwany - jest:

    Code:
            if( ( ( ulPHYId1 << 16 ) | ( ulPHYId2 & 0xfff0 ) ) != MII_DM9161_ID )
    
            {
                    /* Did not expect this ID. */
                    xReturn = pdFAIL;
            } 

    Po wgraniu, efekt jest taki że wszystkie diody sygnalizujące stan ethernetu zapalają się na około 1 - 2 sekundy, gasną na 1-2 sekundy i tak dalej.

    Po podłączeniu kablem cross ethernet do komputera objaw jest taki, że na chwilę interfejs wstaje (widać w pasku windowsa że jest podłączenie) potem się rozłącza (kabel sieciowy rozłączony) i tak w koło.

    Patrząc w kod, wydaje mi się że sprawa dotyczy zmiennej xSemaphore:

    Code:
    /* The semaphore used by the EMAC ISR to wake the EMAC task. */
    
    static xSemaphoreHandle xSemaphore = NULL; 


    i w pliku SAM7_EMAC.h czytamy:

    Code:
    /*
    
     * Initialise the EMAC driver.  If successful a semaphore is returned that
     * is used by the EMAC ISR to indicate that Rx packets have been received.
     * If the initialisation fails then NULL is returned.
     */
    xSemaphoreHandle xEMACInit( void );


    Wydaje się, że nie alokuje się xSemaphore w xEMACInit, bo jeśli się nie alokuje to:
    (w pliku: ethernetif.c)

    Code:
       
    
    while( xEMACInit() == NULL )
       {
          __asm( "NOP" );
       }

    Kiedy może się nie zaalokować xSemaphore?

    w SAM7X_EMAC.c na końcu funkcji xEMACInit(void) widzimy:

    Code:

       /* Are we connected? */
       if( prvProbePHY() )
       {
          /* Enable the interrupt! */
          portENTER_CRITICAL();
          {
             prvSetupEMACInterrupt();
             vPassEMACSemaphore( xSemaphore );
          }
          portEXIT_CRITICAL();
       }

       return xSemaphore;


    Próbowałem debugować przez JTAG, ale bez istotnych wniosków. Wpada gdzieś w boot.s w pętlę i kręci się w kółko (nie pamiętam w tej chwili).

    Próbowałe z ChibiOS, efekt jest inny - nie resetuje się połączenie ethernet ale też nie ma komunikacji (po ustawieniu IP, interfejs nie odpowiada).

    Proszę o pomoc. Próbowałem w Propoxie - ale przez ostatnie pół roku mimo olbrzymiego zaangażowania ze strony Propoxu pozostajemy przy swoich opiniach: w propoxie działa - u mnie nie.

    Proszę o pomoc.

    pozdrawiam,
    G.

    0 13
  • #2 14 Gru 2009 14:59
    nenpa8lo
    Poziom 17  

    Zaglądnij do pliku semaphore.c w kodzie FreeRTOS i będziesz wiedzieć dlaczego semafor nie jest zainicjalizowany (z głowy nie pamiętam).

    0
  • #3 14 Gru 2009 15:10
    nyxnyx
    Poziom 9  

    Nie znalazłem pliku o którym piszesz w źródłach FreeRTOS.

    Semafor jest tworzony przez funkcję prvSetupEMACInterrupt(void):

    Code:

    static void prvSetupEMACInterrupt( void )
    {
       /* Create the semaphore used to trigger the EMAC task. */
       vSemaphoreCreateBinary( xSemaphore );
       if( xSemaphore )
       {
          /* We start by 'taking' the semaphore so the ISR can 'give' it when the
          first interrupt occurs. */
          xSemaphoreTake( xSemaphore, emacNO_DELAY );
          portENTER_CRITICAL();
          {
             /* We want to interrupt on Rx and Tx events. */
             AT91C_BASE_EMAC->EMAC_IER = AT91C_EMAC_RCOMP | AT91C_EMAC_TCOMP;

             /* Enable the interrupts in the AIC. */
             AT91F_AIC_ConfigureIt( AT91C_ID_EMAC, emacINTERRUPT_LEVEL, AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL, ( void (*)( void ) ) vEMACISR );
                AT91C_BASE_AIC->AIC_IECR = 0x1 << AT91C_ID_EMAC;
          }
          portEXIT_CRITICAL();
       }
    }


    vSemaphoreCreateBinary to makro zdefiniowane w źródłach FreeRTOS w pliku semphr.h:

    Code:

    #define vSemaphoreCreateBinary( xSemaphore ) \
    { \
       xSemaphore = xQueueCreate( ( unsigned portCHAR ) 1, semSEMAPHORE_QUEUE_ITEM_LENGTH ); \
       if( xSemaphore != NULL ) \
       { \
          xSemaphoreGive( xSemaphore ); \
       } \
    }


    Patrząc do kodu xQueueCreate - nie widzę bezpośredniej przyczyny poza brakiem zaalokowania wystarczającej ilości pamięci.

    Dodam że:
    1. znam dobrze C
    2. trochę znam mikrokontrolery - właściwie nie znam
    3. nie jestem pewien postawionej przeze mnie diagnozy
    4. nie wiem jak do końca zdiagnozować problem

    pozdr.
    G

    0
  • #4 15 Gru 2009 01:29
    nenpa8lo
    Poziom 17  

    We FreeRTOS jeżeli w czasie wykonywania kodu weźmiesz semafor nim go stworzysz to system się wysypuje (brak zabezpieczenia).
    Ja bym radził wstawienie breakpointu w xQueueCreate żeby sprawdzić czy semafor jest tworzony czy nie.
    A jak z RAM?

    Dodano po 24 [minuty]:

    Troszkę poszperałem na forum FreeRTOS i możliwe że interfejs pada, jeżeli nie masz dobrze skonfigurowanego kontrolera sieciowego.
    KLIK i KLIK.

    0
  • #5 15 Gru 2009 08:36
    nyxnyx
    Poziom 9  

    Dziękuję, sprawdzę wieczorem.
    Używam dema bez modyfikacji własnych - oryginalnego.
    Ale sprawdzę. Może w demie jest problem.

    pozdr.
    G

    0
  • #6 15 Gru 2009 10:32
    nenpa8lo
    Poziom 17  

    A jakiego środowiska używasz?

    0
  • #7 15 Gru 2009 11:06
    arrevalk
    Poziom 25  

    nyxnyx napisał:

    Proszę o pomoc. Próbowałem w Propoxie - ale przez ostatnie pół roku mimo olbrzymiego zaangażowania ze strony Propoxu pozostajemy przy swoich opiniach: w propoxie działa - u mnie nie.

    Jeżeli korzystacie z tej samej wersji freeRTOS to może problem leży w sprzęcie (np zimny lut). Popros propox niech przyślą Ci binarkę do zaprogramowania procka, i nią sprawdź swoją płytkę.

    0
  • #8 15 Gru 2009 11:16
    nyxnyx
    Poziom 9  

    Przesłali.
    Efekt ten sam.
    Zimny lut to brak kontaktu (lub słaby) między elementami.
    Moduł propoxu to samodzielny układ, wystarczy podać zasilanie 3.3V i wszystko powinno działać. Tak też robię. Działa USB (tzn. moduł przy odpowiednim wkładzie melduje się w windowsach jako odpowiednie urządzenie) natomiast nie działa ethernet na module zgodnie z opisem w pierwszym poście.

    pozdr.
    G.

    Dodano po 58 [sekundy]:

    Co do środowiska: GCC z WinARM. Dodatkowo binarka od propoxu.

    0
  • #9 15 Gru 2009 13:55
    nenpa8lo
    Poziom 17  

    Próbowałeś innego modułu? I jak z tym xQueueCreate?

    0
  • #10 16 Gru 2009 10:23
    nyxnyx
    Poziom 9  

    Nie mogę dojść do ładu z JTAGiem - ładuje masakrycznie długo. Breaka ustawiam w main i nie zdążyłem wczoraj w nocy tego zmienić.
    JTAG_khz mam na 5 więc pewnie dlatego.

    Nie próbowałem z innym modułem - mimo odesłania do propoxu z informacją że niedziała - przesłali z powrotem ten sam z informacją że u nich działa :)

    Od pół roku walczę z ethernetem bez skutku.

    Zastanawiam się nad innymi rozwiązaniami:
    1. MMlpc2368 z propoxu
    2. mniejsze procesory - PIC18F67J60

    Całość urządzenia ma za zadanie:
    1. zbierać eventy z 2 - 5 wejść
    2. przesyłać po tcp / ip do centralnego sterownika - albo PC - chciałem zaimplementować protokół DCP (http://dcp.chrisarmbruster.com/Introduction.html) stąd potrzeba mocnych procków
    3. odebrać informację o konfiracji wyjść
    4. odpowiednio ustawić wyjścia

    pozdr.
    G

    Dodano po 2 [minuty]:

    Dodam jeszcze że wczoraj wgrałem z przykładów atmela demo basic web server dla ich demo boardu at91sam7x256-ek - efekt ten sam.
    Z tego co wiem, to tam jest również davicom.

    0
  • #11 16 Gru 2009 10:52
    nenpa8lo
    Poziom 17  

    U propoxu twoja płyta działa. Następnie wysyłają ci tą płytę i binarkę która u nich działała. Więc dla mnie to mogło by coś być z kablem (eth), lub np twój JTAG wysypuje wszystko (robi reset itd.).
    Czy próbowałeś załadować program, który by tylko migał diodą?

    0
  • #12 16 Gru 2009 15:37
    nyxnyx
    Poziom 9  

    Sprawa jest o wiele prostsza:
    Kabel ethernet:
    1. podłączałem do switcha wypinając kabel z działającej bramki VoIP Skype - efekt jak w pierwszym poście
    2. kupiłem nowy kabel cross i podłączyłem bezpośrednio do komputera - efekt jak w pierwszym poście
    3. moduł podłączony do prądu z wsadem z propoxu oraz atmela oraz freertos dla eclipse - efekt ten sam
    4. moduł z wkładem chibios - efekt poprawny (w sensie diód - świecą cały czas, zielona w gniazdku mruga gdy jest ruch na kablu) brak komunikacji z modułem
    4a. po podłączeniu bezpośrednio do komputera, przy odpowienim ustawieniu ip (kompupter 10.0.0.1, chibios 10.0.0.20) - diody mrugają poprawnie - ale brak komunikacji

    Wszystko działa tak samo, niezależnie czy jest podłączony JTAG czy nie.

    Wnioski:
    1. w sensie kabla ethernetowego, switcha i innych "moich" device jest ok
    2. coś jest nie tak z modułem propoxu:
    2a. źle inicjowany w freertos bo w chibios diody świecą poprawnie, ale nie ma komunikacji
    2b. moduł uszkodzony - mało prawdopodobne
    2c. inna przyczyna którą próbuję znaleźć od pół roku bez skutku.

    Pytanie: czy znacie kogoś kto uruchomił ten moduł z wkładem chibios / ecos / innym obsługującym ethernet i może mi udostępnić:
    1. skompilowany wkład
    2. źródła
    ?

    pozdr.
    G

    Dodano po 3 [godziny] 20 [minuty]:

    Co do programu który miga diodą, to tak, ładowałem Freertos z USB CDC i odpowiednie urządzenie rejestrowało się w windowsach bez restartu. W tym zakresie działa bezbłędnie przy jednoczesnym braku komunikacji po ethernecie (jest CDC na USB, nie ma komunikacji / ciągły restart interfejsu ethernet)

    0
  • #13 19 Sie 2010 21:03
    kapw
    Poziom 12  

    Witam,
    czy ktoś zwalczył w końcu ten problem?

    0
  • #14 01 Kwi 2011 09:37
    nyxnyx
    Poziom 9  

    Sprawa rozwiązana.
    Problem leżał w tym, że mój program który "mrugał diodą" używał tego samego pinu, który był używany przez moduł ethernet. Echh głupi błąd ale zawsze trzeba sprawdzać dokumentację hardware.

    pozdrawiam,
    Grzegorz

    0