next topic »

[Reply #30 on:]

Ok, esattamente quindi nel mio caso il bootloader è stato riservato da 2k word, quindi il suo address è $3800 che equivale esattamente a 0x7000 hex (in byte)
Ora c'è da capire se ASM VOLATILE (" JMP 0x7000") effettua effettivamente un salto alla locazione 0x7000(in byte) o se tenta di cercarla a 0x7000 word ( ) e non trovandola punta a 0x00;

[Reply #31 on:]

giusto per ridurre l'entropia
io farei una function softreset con dentro la prepare_for_softreset
dove ti crei il contesto sotto controllo

magari il codice prima ha fatto porcate varie e farcite, e valle a trovare
col rischio che aggiustandole propaghi problemi altrove =P

Code:

void softreset(uint32_t time)
{
    prepare_for_softreset();
    wdt_enable(time)
        {
        /* waiting for wdt event  */;
        }
}

Si mi sembra la cosa giusta, ed è quello a cui avevo pensato anche io, ma cosa fare dentro prepare_for_softreset()??
Magari chiudere la connessione ethernet e seriale (ma si può???) un clear interrupt ... ma poi cos'altro?

[Reply #32 on:]

edit: come non detto, ho controllato ed a 0 ci sta la prima istruzione del programma... l'unica pare essere il watchdog o un minimo di circuiteria, anche se un tizo dice che con un PWM a low sul reset riesce a fare un reset senza problemi: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1250663814/

L'auto-reset è stato detto più volte che può non funzionare correttamente, il segnale di reset deve essere tenuto basso per un certo periodo altrimenti il reset non funziona correttamente. Nel momento in cui arriva il segnale low sul pin di reset parte il reset ma ciò interrompe il segnale Pwm. Atmel suggerisce sempre di usare un circuito esterno per il reset. Anche nel link da te citato viene riferito questo.

mai detto che non possa dare problemi, ma c'è da indagare per chi avesse un oscilloscopio

Hi,
Quote:
I found by tying a PWM pin to the reset pin, you can just do an analogWrite(RESET, LOW); where RESET is your PWM pin.  It's been doing a hard reset for me, working great.

Fine it works for you, but others may be warned:
Atmel the maker of the ATMega's discourages this. Because of timing issues it can lead to situations where the ATMega goes into an endless reset-loop.

Eberhard

[Reply #33 on:]

mai detto che non possa dare problemi, ma c'è da indagare per chi avesse un oscilloscopio

A suo tempo mi pare che astrobeed lo fece.

[Reply #34 on:]

Ok, esattamente quindi nel mio caso il bootloader è stato riservato da 2k word, quindi il suo address è $3800 che equivale esattamente a 0x7000 hex (in byte)
Ora c'è da capire se ASM VOLATILE (" JMP 0x7000") effettua effettivamente un salto alla locazione 0x7000(in byte) o se tenta di cercarla a 0x7000 word ( ) e non trovandola punta a 0x00;

Basta guardare il codce dell'Optiboot. Siccome a priori non sai se c'è lo spazio riservato per il bootloader ed a quanto ammonta, l'Optiboot esegue un'operazione di "fino": carica nel vettore del watchdog i vettori di start del codice che vengono memorizzati in base alla presenza o meno dell'area riservata al bootloader e poi fa eseguire il reset al watchdog:

Code:

      if ((uint16_t)(void*)address == 0) {
        // This is the reset vector page. We need to live-patch the code so the
        // bootloader runs.
        //
        // Move RESET vector to WDT vector
        uint16_t vect = buff[0] | (buff[1]<<8);
        rstVect = vect;
        wdtVect = buff[8] | (buff[9]<<8);
        vect -= 4; // Instruction is a relative jump (rjmp), so recalculate.
        buff[8] = vect & 0xff;
        buff[9] = vect >> 8;

        // Add jump to bootloader at RESET vector
        buff[0] = 0x7f;
        buff[1] = 0xce; // rjmp 0x1d00 instruction
      }

e poi chiamando il watchdog:

Code:

void watchdogReset() {
  __asm__ __volatile__ (
    "wdr\n"
  );
}

[Reply #35 on:]

Basta guardare il codce dell'Optiboot. Siccome a priori non sai se c'è lo spazio riservato per il bootloader ed a quanto ammonta, l'Optiboot esegue un'operazione di "fino": carica nel vettore del watchdog i vettori di start del codice che vengono memorizzati in base alla presenza o meno dell'area riservata al bootloader e poi fa eseguire il reset al watchdog:

???

Non capisco in che contesto applicare quello che hai scritto leo...

Di sicuro sò che c'è il bootloader caricato, sò dove stà (sta a 0x7000) e sò che non è optiboot (ma è un bootloader per caricare da sd).
Come ho già scritto alcuni post prima, utilizzando la JMP 0x7000 il codice riparte (ho una pagina web che mi mostra il valore di millis()) ma non sò per quale motivo non esegue l'upload del codice caricato nella sd.

[Reply #36 on:]

Hai scritto che non capivi come fare per implementare il JMP al bootloader.
Io ti ho spiegato che puoi valutare anche il caso che il bootloader sia di dimensioni diverse e fare tutto a runtime usando il codice dell'Optiboot.

Sul fatto che il tuo bootloader non carichi lo sketch non so, bisognerebbe capire dal codice se esegue qualche check particolare

[Reply #37 on:]

Ah, ora è chiaro....

Per un attimo avevo pensato di cambiare strategia, rimettere l'optiboot originale e implementare il flash del nuovo codice da programma principale , ma penso che sia molto più laborioso...

[Reply #38 on:]

Alla fine ci sono riuscito!

Ho deciso che per forza di cose l'unica modalità sufficientemente affidabile era il watchdog, pertanto armato di santa pazienza ho fatto alcune prove.
Diagnosticato ad oltranza che il problema non poteva essere lato applicazione (programma principale) ho preso in mano il codice sorgente del bootloader.
Per prima cosa ho fatto in modo che compilandolo ne avessi una versione che perlomeno funzionasse come quello precedente (cosa che in automatico non era possibile in quanto chi aveva fatto il fork aveva 'smanettato' nel frattempo e non si ricordava bene cosa e dove!)
Una volta ottenuto il bootloader SD funzionante da mia compilazione avevo finalmente una buona base di partenza per risolvere il problema.
Mi sono messo alla ricerca del probabile problema, che altro non poteva essere se non il watchdog , in quanto se non lo usavo non avevo alcun problema!
A seguito di fortuna,ma sicuramente anche di tanta pazienza e audacia, mi sono imbattuto in una interessante lettura inerente i cani da guardia :

http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html

Dove ad un certo punto si legge chiaramente :

'Note that for newer devices (ATmega88 and newer, effectively any AVR that has the option to also generate interrupts), the watchdog timer remains active even after a system reset (except a power-on condition), using the fastest prescaler value (approximately 15 ms)'

Mi si è accesa subito una lampadina, e ho pensato , vuoi vedere che porca di quella miniotta il watchdog rimane attivo (a velocità pazzesca mi permetto di aggiungere) e mi va in loop subito dopo il caricamento delle prime righe del main del bootloader??
Riarmato di santa pazienza e energizzato da una scarica di ave marie che la metà basta e avanza ho analizzato bene la lettura che mi ha portato alla deduzione e ho partorito una serie di modifiche al bootloader che alla fine mi hanno dato ragione e regalato finalmente il mio obbiettivo finale:

Avere un webserver su ArduinoEthernet con la quale interagire le funzionalità della scheda e dal quale ho la possibilità di aggiornare da web anche il suo stesso firmware senza avere alcun tipo di accesso fisico alla scheda.

Sono contento,perchè oltre ad averne veramente bisogno sul campo , ora posso dedicarmi ad un altra cosa molto interessante che ho iniziato a vedere oggi... ma questa è un altra storia e ve la racconto un altro giorno!

Per stasera vado a dormire... me lo sono meritato!

[Reply #39 on:]

*cough* mi pare che l'ultima versione di boot-loader abbia già risolto il poblema *cough*

[Reply #40 on:]

Sì, l'Optiboot risolve il problema del watchdog. Il watchdog, una volta attivato, resta attivo anche dopo un reset. E la prima operazione da fare nel bootloader è sempre quella di modificare il watchdog. Nell'Optiboot infatti tra le prime istruzioni c'è proprio quella di configurare il watchdog ad 1 secondo di timeout e, prima di lasciare il controllo allo sketch dell'utente, lo disattiva del tutto.

[Reply #41 on:]

Il punto non è tanto che il wd  rimane attivo, ma che viene messo automaticamente  a 15ms 

infatti una prova fatta in precedenza consisteva nei mettere il wd a 4S per fare in modo che anche se fosse rimasto attivo eventualmente sarebbe stato triggerato dopo il caricamento del bl  .
È un di quelle cose che o la sai o ci sbatti un bel po per capire cosa accade!

[Reply #42 on:]

Sarà il caldo ma.... non ho capito se hai risolto oppure no 

[Reply #43 on:]

Si,leggi 2 post miei sopra.

http://arduino.cc/forum/index.php/topic,113049.msg903214.html#msg903214

[Reply #44 on:]

Si,leggi 2 post miei sopra.

http://arduino.cc/forum/index.php/topic,113049.msg903214.html#msg903214

Ok, credevo che con l'ultimo tuo post avessi manifestato l'insorgere di un nuovo problema