next topic »

[Reply #405 on:]

//reset the MCU
void leOS2::reset(void) {
    wdt_disable();
    //wdt_enable(WDTO_30MS);  //riga originale blocco
    //wdt_enable(WDTO_4S); //blocco 2560
    //wdt_enable(WDTO_2S); //blocco 2560
    //wdt_enable(WDTO_1S); //blocco 2560
    //wdt_enable(WDTO_500MS); //blocco 2560
    //wdt_enable(WDTO_250MS); //blocco 2560
    while(1){}; //wait for reset

chiaramente chiudendo e riaprendo a ogni cambiamento l'IDE, la prima volta lo scrive, poi non riesco più a caricare nulla se non riaccendendo arduino tenendo premuto il reset ecc ecc

[Reply #406 on:]

//reset the MCU
void leOS2::reset(void) {
    wdt_disable();
    //wdt_enable(WDTO_30MS);  //riga originale blocco
    //wdt_enable(WDTO_4S); //blocco 2560
    //wdt_enable(WDTO_2S); //blocco 2560
    //wdt_enable(WDTO_1S); //blocco 2560
    //wdt_enable(WDTO_500MS); //blocco 2560
    //wdt_enable(WDTO_250MS); //blocco 2560
    while(1){}; //wait for reset

chiaramente chiudendo e riaprendo a ogni cambiamento l'IDE, la prima volta lo scrive, poi non riesco più a caricare nulla se non riaccendendo arduino tenendo premuto il reset ecc ecc

Allora il problema è il bootloader, come temevo, che non usando il WDT, lo lascia attivo.
La cosa che mi fa pensare è qui:
http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html
si legge:

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). It is therefore required to turn off the watchdog early during program startup

Quello che ti ho chiesto di fare è appunto di impostare un tempo superiore ai 15 ms, che doveva escludere il problema del watchdog che restava attivo. Ma così però non è.

[Reply #407 on:]

Pablos, prova la versione allegata.
Ho riveduto la lib un po', aggiungendo maggiori setup per rendere l'operazione di disattivazione del WDT quanto più uguale a quanto scritto sul datasheet.

Se anche così non va, senza una MEGA in mano non so. L'unica alternativa che posso provare è la sostituzione della funzione di reset che ho scritto con il classico jump $0000 però preferivo il reset col WDT, perché è fatto a livello HW e quindi sicuramente più efficace di un semplice salto alla 1a istruzione del codice.

PS:
questa stessa versione funziona sulla Leonardo, che ha un bootloader che attende ben 8s prima di proseguire ma anche in questo caso viene resettato il watchdog subito.

[Reply #408 on:]

Questo non lo inchioda subito, il pin 13 lampeggia per un po' 5-6 secondi poi si ferma rimane fisso e da li in poi si blocca, entro quei secondi però riesco a riscrivere lo sketch, immagino che poi faccia il reset e non si rianima più

Se non hai la scheda capisco che sia difficile ... bhe ci hai provato, grazie lo stesso


PS Ma per fare un reset ci vogliono tutte quelle istruzioni?  .... 

ciao 

[Reply #409 on:]

Questo non lo inchioda subito, il pin 13 lampeggia per un po' 5-6 secondi poi si ferma rimane fisso e da li in poi si blocca, entro quei secondi però riesco a riscrivere lo sketch, immagino che poi faccia il reset e non si rianima più

Non so le tempistiche del bootloader della MEGA. Comunque, se con questa versione la scheda non si inchioda subito allora prova ad aumentare nella ruotine reset() il tempo di attesa con wdt_enable(WDTO_4S) oppure WDTO_8S) per esempio.

PS Ma per fare un reset ci vogliono tutte quelle istruzioni?  .... 

Tutte quelle istruzioni ci vogliono per poter modificare i parametri del watchdog: 1) in maniera tale che le modifiche siano prese (per alterare il WDT, devi prima scrivere ad uno logico 2 particolari bit del suo registro, dopodiché entro 4 cicli di clock modificare i bit che vuoi alterare); 2)senza che questo venga alterato in un modo tale che poi si metta a resettare la scheda di continuo il micro.

Poi, ripeto. Si può anche mettere un jmp$0000 e via, ma così non si ha un vero reset HW.
Cmq se puoi fare la prova che ti ho suggerito, mi faresti un piacere.

[Reply #410 on:]

No niente nemmeno con quei 2 valori  wdt_enable(WDTO_4S) oppure WDTO_8S, si inchioda esattamente dopo 10 secondi penso a causa  questa linea

myOS.addTask(reset, myOS.convertMs(10000)); //add a task to be executed after 10 seconds

[Reply #411 on:]

Che il wdt_enable(WDTO_4S); non funzionasse sulla mega già lo avevi affrontato ti ricordi di questa discussione?
http://arduino.cc/forum/index.php?topic=108620.0, magari c'e' qualche link che può servirti, sembrerebbe che bisogna caricare un altro bootloader
Comunque da quando leggo in giro, nessuno è riuscito a fare sto benedetto reset usando WDT sul 2560, senza toccare il bootloader

ciao

[Reply #412 on:]

Che il wdt_enable(WDTO_4S); non funzionasse sulla mega già lo avevi affrontato ti ricordi di questa discussione?
http://arduino.cc/forum/index.php?topic=108620.0

Non mi ricordavo di questo bug. Non avendo la MEGA, era una problematica affrontata in quella discussione e poi scordata del tutto.

magari c'e' qualche link che può servirti, sembrerebbe che bisogna caricare un altro bootloader
Comunque da quando leggo in giro, nessuno è riuscito a fare sto benedetto reset usando WDT sul 2560, senza toccare il bootloader

Sì, esatto. Ma di questo me n'ero accorto anch'io. Ti avevo infatti già detto che una delle differenze del bootloader della MEGA rispetto all'Optiboot stesse proprio nel fatto che l'Optiboot resetta il Watchdog di suo perché poi lo usa come timeout.
Ad abbondanza, ho trovato anche un'altra discussione su un altro forum in cui si parla di un problema identico al tuo:
http://www.electroyou.it/phpBB2/viewtopic.php?f=17&t=32610
Usando una 2009 la scheda non si resetta ma va in blocco proprio quando dovrebbe venir resettata dal WDT. Questo mi fa pensare che questa caratteristica non possa essere usata su chip dove c'è un bootloader che non prevede la disabilitazione del watchdog al suo riavvio. Per contro, un chip standalone senza bootloader non soffre di questi problemi (vedi il mio test con un Tiny85) né l'Arduino UNO né la LEONARDO per via del fatto che i loro bootloader resettano il watchdog.

Quindi con la MEGA devo per forza usare il jmp $0000 al posto del watchdog per resettare la scheda.

[Reply #413 on:]

Prova la versione allegata.
E' la 2.1.3. Ho inserito un check per cui se trova un certo #define, sa di avere a che fare con una Arduino MEGA e dovrebbe usare il jmp $0000 al posto del reset HW. Non è un reset HW , quindi al micro non viene mandato il segnale di reset ma viene fatta ripartire l'esecuzione del programma in memoria (bootloader compreso).
Per far ciò inserisci questa riga:

Code:

#define ARDUINO_MEGA

prima dell'inclusione della leOS2.

Quindi lo sketch di test "leOS2_reset_after_timeout" deve iniziare così:

Code:

#define ARDUINO_MEGA
#include "leOS2.h" //include the scheduler
leOS2 myOS; //create a new istance

Fammi sapere.

[Reply #414 on:]

Ho cambiato la CPP e aggiunto la riga #define ARDUINO_MEGA, compila, tutto ok ma mi addolora dirtelo si inchioda ancora dopo il 3 lampeggio. 

ho visto che hai aggiunto questo

#ifdef ARDUINO_MEGA
   __asm__ __volatile__ ("jmp 0x0000");

ma con il jump a 0x0000 dici al micro di ricaricare il boot dalla posiz di memoria 0?

ciao

[Reply #415 on:]

ma con il jump a 0x0000 dici al micro di ricaricare il boot dalla posiz di memoria 0?

Dico al micro di riavviare il programma. Siccome nella locazione $0000 c'è il jump all'inizio del codice eseguibile (allo sketch se non c'è il bootloader, a quest'ultimo se invece esso è presente) in pratica dovrei riavviare l'esecuzione del firmware. Se mi dici che non va, sono ad un vicolo cieco.... 

[Reply #416 on:]

Mi puoi fare un ultimo tentativo col file .cpp allegato?

[Reply #417 on:]

Fatto, mi spiace, non va neanche questo. Meno male che la manovra di emergenza va quasi sempre alla prima.  

Lascia stare Leo anche se ormai mi sa che per te è diventata una questione personale e di completezza . Purtroppo non so come aiutarti non conosco i micro così nel dettaglio.

ciao


PS.

Ho cercato un po' qua e la "mega 2560 WDTO reset" e sono capiato qui http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=7318&start=0

in fondo c'e' un pezzetto di sketch

e ho messo su questo velocemente che funziona ... fa il reset della Mega 2560 quando chiamo la reset(), non credo proprio faccia il controllo del blocco tramite watchdog.
non è la stessa cosa di quella che hai fatto tu, ma potrebbero esserci dati che possono indirizzarti o adattarlo alla tua lib, ad esempio perchè usa  0x000000 invece di 0x0000 non so se cambia molto

oppure cos'è quell EIND=0  (che ho provato a levarlo e resetta lo stesso )

Code:

//#include <io.h>
const byte LED = 40;

void setup() {
    delay(1000);
    Serial.begin(9600);
    Serial.println("Sono nel void setup");
    pinMode(LED, OUTPUT); //pin as output  
    blink3times();  
}

void blink3times() {
    for (byte i=0; i<3; i++)
    {
        digitalWrite(LED, HIGH);
        delay(250);
        digitalWrite(LED, LOW);
        delay(250);
        Serial.println((String)i);
    }
      reset();
}

void loop() {
}

void reset( void )
{
  Serial.println("Sono nel void reset");
  delay(500);
  //EIND = 0;
  ((void (*)())0x000000)();
  Serial.println("Non dovrebbe stampare niente"); //infatti di qui non ci passa .. non stampa
}

wow FUNZIONA!!
Ho pasticciato un po' la tua lib cercando quale riga dava noia, nostante abbia messo #define ARDUINO_MEGA nello sketch ho come l'impressione che passasse lo stesso da quel #else che è messo per gli altri arduini, mi si inchiodava sempre. Però e tardino, ci ripasso domani.

Code:

//reset the MCU
void leOS2::reset(void) {

SREG &= ~(1<<SREG_I);
//wdt_reset(); //<<<<<<<<<<<<<<<<<<<<QUESTA lo fa schiantare
    wdt_disable();
    
    //for the Arduino MEGA 2560 we must use a software reset
    //because its bootloader leads to a board freeze!
//#ifdef ARDUINO_MEGA
__asm__ __volatile__ ("jmp 0x000000"); //<<<<<<<<<<<<<<< ho aggiunto 2 zeri
  
//#else
    //wdt_enable(WDTO_1S);
    //SREG |= (1<<SREG_I);
    //while(1){}; //wait for reset
//#endif
}

fa 3 lampeggi, attende 10 secondi e si resetta!!!! E' quello che volevi no?
Ma questo reset lo dovrebbe fare anche se si inchioda l'MCU per i fatti suoi usando l'interrupt del watchdog ?

Riciao

[Reply #418 on:]

ma con il jump a 0x0000 dici al micro di ricaricare il boot dalla posiz di memoria 0?

Dico al micro di riavviare il programma. Siccome nella locazione $0000 c'è il jump all'inizio del codice eseguibile (allo sketch se non c'è il bootloader, a quest'ultimo se invece esso è presente) in pratica dovrei riavviare l'esecuzione del firmware. Se mi dici che non va, sono ad un vicolo cieco.... 

dovrebbe essere corretto, ma se è una limitazione del boot-loader la vedo grigia, e mi sembra strano che non sia stato patchato (però comunque significa che in molti casi va aggiornato il boot-loader)

[Reply #419 on:]

ma con il jump a 0x0000 dici al micro di ricaricare il boot dalla posiz di memoria 0?

Dico al micro di riavviare il programma. Siccome nella locazione $0000 c'è il jump all'inizio del codice eseguibile (allo sketch se non c'è il bootloader, a quest'ultimo se invece esso è presente) in pratica dovrei riavviare l'esecuzione del firmware. Se mi dici che non va, sono ad un vicolo cieco.... 

dovrebbe essere corretto, ma se è una limitazione del boot-loader la vedo grigia, e mi sembra strano che non sia stato patchato (però comunque significa che in molti casi va aggiornato il boot-loader)

Il problema è certamente del bootloader. Quello della MEGA è l'unico del "vecchio tipo", per capirsi della famiglia della 2009. Da quando è arrivato l'Optiboot le cose sono cambiate (in meglio) ed il watchdog è resettato nel bootloader. Il problema è che il bootloader della MEGA emula un programmatore (l'STK500v2) differente da quello emulato dall'Optiboot (STK500v1); inoltre è molto grande ed emula anche un terminale (se non ho capito male) in cui puoi entrarci mandando 3 caratteri "!" quando si avvia. Credo che alla fine lo abbiano tenuto per una questione di retrocompatibilità ma forse sarebbe il caso, prima o poi, di aggiornarlo.

Tornando alla leOS2, la soluzione certa è la modifica del bootloader: ma è un'operazione che non voglio far fare perché forse l'1% degli utenti è disposto/capace a metter mani ad una cosa del genere.

@pablos:
la soluzione che hai messo tu è abbastanza semplice. Si tratta di creare un puntatore ad una funzione con indirizzo $0000. Chiamandola altro non fa il compilatore che creare un jump alla prima locazione di memoria. Devo ora capire perché $0000 non funziona e $000000 sì.

EIND è l'Extended Indirect Register, un registro usato in combinazione con altri 2 per i salti indiretti.