Ethernet hang

Salve a tutti, in questi giorni sto provando a svilppare un semplice prototipo con arduino ethernet rev.3 con ide 1.04 per OSX.
Il problema che sto incontrando e' che la parte ethernet a volte si blocca. Oltre alle verifiche dell'occupazione della SRAM ho provato ad effettuare gli stessi test con lo sketch di esempio presente nell'ide (file->esempio->ethernet->webserver) con gli stessi risultati :-(.

Per riprodurre l'errore ho utilizzato la seguente script da bash shell:
while(true); do date >> wget.out; wget 192.168.1.14:8000/ -o wget.log -O - >> wget.out;echo "####" >> wget.out; done

La connessione si blocca dopo un numero di volte apparentemente random, ad esempio 100, 200, 400 connessini consecutive senza problemi. Dal terminale unix la parte socket sembra funzionare bene, posso infatti vedere 3 socket nello stato di TIMEWAIT e un socket attivo corrispondente proprio alle specifiche del chip W5100 che ne prevede un massimo di 4. Sempre alla script di sopra ho inserito uno sleep di 10, 20 e 30 secondi ma il problema rimane. Quando la connessione si blocca il socket rimane nello stato di ESTABLISHED in modo indefinito, questo l'ho potuto verificare sia da terminale che dallo sketch accendeno un led (porta digitale 7) nella fase in cui Arduino effettua un send dei dati verso il client. Raggiunto lo stato di blocco arduino risponde al ping regolarmente mentre la parte TCP rimane bloccata. Se effettuo un reset software (da monitor seriale dell'ide, il problema persiste evidentemente perche' il chip w5100 non viene resettato e sono quindi costretto a spegnere e riaccendere la scheda (stile windows)).
Non so se questo sia dovuto a un bug del chip o della libreria, prima di procedere alla parte di debug di piu' basso livello chiedo qualcuno ha avuto lo stesso problema (ho visto che ci sono alcuni post relativi a questo problema ma non sono riuiscito individuare possibili soluzioni gia' postate.)
Siccome uno dei prerequisiti fondamentali del prototipo e' la stabilita' del sistema di connessione di rete che non deve prevedere problemi di blocco con conseguenti riavvi della scheda tutto cio' condiziona la prosecuzione dello sviluppo.

Riguardo al chip w5100 ho visto che c'e' un indicazione ufficiale relativa ad un problema di connessione con protocollo UDP per il resto non ho trovato nulla.

Saluti

Giovanni

Benvenuto nel club.
Ci sono utenti che ci stanno sbattendo la testa da mesi ad altri che non hanno avuto nessun problema.
Purtroppo non si riesce a fare una casistica dei blocchi :frowning: perchè se si cerca di testare un qualcosa ad uno si blocca e all'altro no.
Mistero di Arduino. :cold_sweat:

Io penso invece che non ci sia unione in questo, bastava suddividere i test e le parti da analizzare in più utenti partendo da un programma uguale per tutti, ciò provato più di una volta, ma evidentemente non è così di grande interesse. Alla fine lo farà qualcuno per conto suo senza condividere ... è un po' diciamo che ci sta bene :slight_smile: (se non lo ha già fatto)

Perche' non provare a fare dei test insieme: per lo sketch si potrebbe utilizzare quello di esempio webserver e questo non e' un problema, dovremmo dividerci i compiti riguardo alla libreria ethernet e alla parte w5100. Credo che per provare a recuperare informazioni dal chip w5100 bisogna vedere come inviare i comandi nel formato SPI e quindi bisogna fare una gran parte del lavoro a basso livello. Sicuramente chi ha un po' di esperienza potrebbe dare un contributo maggiore...
Comuque se qualcuno fosse interessato potrei cercare di dare contribuire per quanto mi e' possibile.

Saluti

Giovanni

La connessione si blocca dopo un numero di volte apparentemente random, ad esempio 100, 200, 400 connessini consecutive senza problemi.

quanto è lo spazio di tempo 1 ora, 1 giorno, 10 giorni?

ciao

Il tempo in cui si blocca e' variabile: 1 ora, 2 ore, 20 minuti ecc.. Ora provero' a scrivere un client in C estremamente semplice in modo da testare una connessione tcp/ip senza l'utilizzo del protocollo applicativo http. Nei prossimi giorni vi aggiornero' sull'esito dei test.

Giovanni

ok, aspettiamo ....

nel frattempo imposta i pin 4 e 10 in OUT e mettili in HIGH e riferisci (per favore) se si ripete ancora in un tempo così breve

ciao

ok, provero' senz'altro!
Se ho ben capito (correggetimi se sbaglio sono nuovo in questo ambiente e se dico stupidaggini abbiate pazienza ) i pin 4 e 10 servono pe poter far utilizzare il canale SPI in configurazione master (arduino) e slave rispettivamente la sd card e la parte ethernet. Ponendo entrambi i pin nello stato di HIGH entrambi i dispositivi verrebbero disconnessi dal bus.

Saluti

Giovanni

i pin 4 e 10 servono pe poter far utilizzare il canale SPI in configurazione master (arduino) e slave rispettivamente la sd card e la parte ethernet. Ponendo entrambi i pin nello stato di HIGH entrambi i dispositivi verrebbero disconnessi dal bus.

esatto, abilitati alternativamente (così dovrebbe essere da librerie) singolarmente quando necessari, altrimenti rimarrebbero appesi in stato flottante, potrebbero assumere valori 1/0 casualmente creando problemi. Questa non è una soluzione, ma un punto credo importante.

saluti
Paolo

OK, posso collegare due led sui pin 4 e 10 in modo da poter controllare cosa succede quando si blocca la connessione?

Ho visto che esiste la libreria webduino, faro' un test anche con quella per vedere se si verificano gli stessi problemi di connessione.

A presto

Giovanni

posso collegare due led sui pin 4 e 10 in modo da poter controllare cosa succede quando si blocca la connessione?

Si lo avevo fatto, ma non è indicativo secondo me, i led li troverai sempre entrambi accesi, si affievoliscono leggermente a seconda di quello vai ad usare (sd o eth). Lo sketch può piantarsi prima che venga eseguita la chiusura del "canale" e trovarlo spento

OK, e' inutile che provo anch'io, probabilmente la frequenza non permette di cogliere visivamente il cambiamento degli stati.

Girando sulla rete ho trovato questa libreria beerduino/libraries/ethernet2 at master · SR-G/beerduino · GitHub il readme sembra interessante. Oggi la provo e vi faccio sapere.

... non supporta il chip w5100 :frowning:

Oggi pomeriggio ho effetutato il seguente test:

Ho modificato il file ..../Ethernet/utility/socket.cpp aggiungendo il seguente codice estrapolato dal primo link:

        Serial.print("send.3, SnSR=0x");
        Serial.print(W5100.readSnSR(s),HEX);
        Serial.print(", SnIR=0x");
        Serial.print(W5100.readSnIR(s),HEX);
        Serial.print(", TX_WR=0x");
        Serial.print(W5100.readSnTX_WR(s));
        Serial.print(", TX_RD=0x");
        Serial.print(W5100.readSnTX_RD(s));
        Serial.println(".");

W5100.execCmdSn(s, Sock_SEND);

Il blocco della scheda si verifica quando viene eseguito il metodo W5100.execCmdSn(s, Sock_SEND); I valori dei registri W5100.readSnTX_RD(s) e W5100.readSnTX_WR(s) sono sempre uguali tranne nel caso in cui si verifica il blocco e questo avvalora quanto specificato nel secondo link anche se in quel caso si parla di UDP.

prima di W5100.execCmdSn(s, Sock_SEND); ho inserito la seguente verifica

if (W5100.readSnTX_RD(s) != W5100.readSnTX_WR(s))
  {
      Serial.println("!!!!!!!!!!!!!!!!!");
      close(s);
      return 0;

  }

La chiusura del socket sembra impedire il blocco della scheda anche se ovviamente la trasmissione dei dati del socket chiuso sara' errata. Devo comunque fare altri test come ad esempio capire se il return 0 e' corretto.

Sembra non bloccarsi, dico sembra perche' devo fare ovviamente altre prove.
Vi terro' aggiornati sugli eventi.

Saluti

Giovanni

I blocchi del codice racchiudili con gli appositi tag CODE (pulsante # sopra le faccine), il post diventa più leggibile.
Puoi modificare i post precedenti premendo modify, in alto a destra del post stesso.

La modifica sopra riportata non e' stata risolutiva. =(

Ho effettuato altri test.
Nel metodo write definito in EthernetClient.cpp ho aggiunto il delay(20) che ovviamente rallenta la velocita' con cui
i dati vengono inviati al client con il vantaggio di una maggiore stabilita'.

Con questa modifica, sempre con la script gia' citata, ho effettuato 155.000 connessioni consecutive senza problemi.

 size_t EthernetClient::write(const uint8_t *buf, size_t size) {
delay(20);

  if (_sock == MAX_SOCK_NUM) {
    setWriteError();
    return 0;
  }
  if (!send(_sock, buf, size)) {
    setWriteError();
    return 0;
  }
  return size;
}

Andrebbe approfondito se il delay e' necessario per limiti del chip w5100 oppure per qualche bug della libreria.

Saluti

Giovanni

Hai provato a fare qualche prova con delay minori per vedere fino a quanto si può diminuire senza perdere stabilità?

No, non ho provato.
Il delay l'ho calcolato basandomi sul tempo necessario impiegato per stampare una stinga tramite un Serial.println che inizialmente avevo messo al posto del delay come DEBUG (15 caratteri /9600 *10 -> circa 15 ms).

Nella documentazione del chip w5100 ho visto che c'e' del codice di esempio per la gestione delle connessioni, andrebbe fatta una verifica con quanto implementato nella libreria in modo da capire se il problema di stabilita' e' dovuto al chip o a qualche bug.

Giovanni

Hai provato ad impostare il pin 4 come output e forzarlo high? Io tanti problemi li ho risolti con quello.