La scrittura su SD non aggiorna la data del file

Ciao a tutti, sto implementando dei datalogger sulla base del progetto di Brunello, funziona tutto, ma stranamente la scrittura dei dati sulla SD non aggiorna la data del file, anzi, a dirla tutta, nonostante data e ora siano gestiti correttamente nella fase di logging, sia nel file sulla SD che sul monitor seriale, il file viene creato con la data 01/01/2000, e questa data la mantiene anche se all'interno i dati di logging riportano la data corretta.

Non sono riuscito a individuare il punto in cui questa data viene persa, e, d'altra parte, non capisco come si possa scrivere in un file senza che venga aggiornata la sua data sul FS.

Non allego lo script perchè è on line, uso un arduino pro mini a 3.3 e un rtc DS3231, se avete bisogno di altre info chiedete pure.

Grazie per l'aiuto.

gp

Ho la vaga idea che la libreria SD neanche la prenda in considerazione ... del resto, normalmente, un Arduino NON ha un RTC ed il fatto che uno lo aggiunga e lo usi non è cosa nota alla libreria SD ... ::slight_smile:

Guglielmo

Ora che me lo dici mi sembra quasi banale...

Ma come faccio a dire alla libreria SD che ore sono?

gporciello:
Ma come faccio a dire alla libreria SD che ore sono?

... credo che NON lo preveda proprio ::slight_smile:

Dovresti studiartela e metterci le mani dentro, ma ... non è cosa banale ...

Guglielmo

Puoi provare con la libreria SdFat: https://github.com/greiman/SdFat/blob/master/examples/Timestamp/Timestamp.ino

Ciao Sukko, ho provato a giocare un po' con la libreria che mi hai suggerito, ma non sono riuscito a capire come usarla, e in più adesso, pur tornando allo sketch originale, non riesco più a scrivere del tutto sulla SD...

Sono sceso fino alle demo base per controllare il tutto, e neanche "CARDINFO" vede la SD.

L'errore segnalato a monitor è questo:

Initializing SD card...Wiring is correct and a card is present.

Card type: SD2
Could not find FAT16/FAT32 partition.
Make sure you've formatted the card

è come se trovasse la card ma non riuscisse ad accederci. Inutile dire che la card è accessibilissima da PC, formattata FAT 32, è una 8 Gb in classe 4.

la parte di codice che fallisce è questa:

 // Now we will try to open the 'volume'/'partition' - it should be FAT16 or FAT32
  if (!volume.init(card)) {
    Serial.println("Could not find FAT16/FAT32 partition.\nMake sure you've formatted the card");
    return;
  }

La cosa che mi basisce è che funzionava tutto correttamente a parte la data del file, e adesso, non vede più la stessa card su cui prima scriveva senza problemi...

Avete qualche idea?

La libreria SdFat è completa di esempi, basta caricarli...

Hai riformattato la SD ultimamente? Sei sicuro che abbia una tabella delle partizioni stile MSDOS/mbr?

Le SD che sto usando (sono 3, tutte uguali) non le ho mai formattate, le ho trovate già FAT 32, e i tre datalogger che ho assemblato, non hanno avuto mai problemi a scriverci sopra, io mi sono sempre limitato a cancellare o rinominare i file da pc quando controllavo i risultati degli sviluppi.

PS: Per rispondere più precisamente, c'è sopra una unica partizione fat32 con 5 Mb non allocati all'inizio, su di una ho provato a spostare la partizione a partire dal primo blocco ottenendo che la SD non viene più vista nemmeno dall'iniziazione, anche se il pc continua a gestirla correttamente, a quel punto, visto soprattutto che sulla schedine nuove non avevo mai avuto problemi, le altre le ho lasciate com'erano.

Molto strano allora, ricontrolla i collegamenti.

Uno dei datalogger l'ho completamete smontato e rimontato.

D'altra parte, un problema HW che compare contemporaneamente su tre dispositivi perfettamente funzionanti (tieni presente che sono inscatolati, non formato groviglio di fili sulla scrivania con piano in metallo...) dando esattamente lo stesso problema sarebbe veramente una coincidenza tipo asteroide che ti colpisce sulla soglia di casa, diciamo che io, nella mia ignoranza, voto per il problema software...

Adesso sto caricando sketch base per verificare che funzioni tutto, a partire da blink, ma pare vada tutto bene tranne l'accesso alla SD...

Esiste un modo per "azzerare" completamente un mini pro? Anche se mi sembra una domanda priva di senso visto che il loader funziona e riesco a caricarci sopra quello che voglio...

Non c'è niente da azzerare... Al limite se lo sketch usa la EEPROM puoi provare lo sketch eeprom_clear.

Ho provato ad accendere un led con i 4 pin conivolti nel collegamento con la sd (10, 11, 12, 13) e va tutto bene, il bus I2C è ok perchè RTC e sensore loggano tranquillamente a monitor, la SD viene inizializzata, ma arduino non riesce a scriverci, e nemmeno a leggerci per la verità, visto che falliscono sia CARDINFO che LISTFILES, tutti la inizializzano ma poi nessuno riesce a gestire la SD, questo è un log di esempio:

Partenza.
inizializzazione orologio.
Fatto.
Initializing SD card...initialization done.
Inizio loop.Humidity: 62.72 %	Temperature: 20.45 *C 
29/01/2018 13:27:52

allarme uno si e' attivato
29/01/2018 13:27:52

error opening Data0.csv
Inizio loop.Humidity: 62.64 %	Temperature: 20.47 *C 
29/01/2018 13:32:53

allarme uno si e' attivato
29/01/2018 13:32:53

error opening Data0.csv
Inizio loop.

Qui si vede chiaramente l'inizializzazione della SD, il funzionamento del bus, il funzionamento dei pin coinvolti nell'alimentazione, il tutto seguito dal fallimento della scrittura.

Vi viene in mente qualche test che possa aiutare a diagnosticare il problema?

Posso vedere la parte di codice dove apri il file?

Devo rettificare per quanto riguarda l'inizializzazione.

Lo sketch completo inizializza con questo codice:

Serial.print("Initializing SD card...");
  if (!SD.begin(SD_CS_PIN)) {                    //-------------------------------------
    Serial.println("initialization failed!");
    digitalWrite(pin_led, HIGH); // attiva led di allarme
    return;
  }
Serial.println("initialization done.");

con SD_CS_PIN = 10 e il messaggio a monitor da esito positivo.

la CARDINFO invece usa:

  if (!card.init(SPI_HALF_SPEED, chipSelect)) {
    Serial.println("initialization failed. Things to check:");
    Serial.println("* is a card inserted?");
    Serial.println("* is your wiring correct?");
    Serial.println("* did you change the chipSelect pin to match your shield or module?");
    return;
  } else {
    Serial.println("Wiring is correct and a card is present.");
  }

  // print the type of card
  Serial.print("\nCard type: ");
  switch (card.type()) {
    case SD_CARD_TYPE_SD1:
      Serial.println("SD1");
      break;
    case SD_CARD_TYPE_SD2:
      Serial.println("SD2");
      break;
    case SD_CARD_TYPE_SDHC:
      Serial.println("SDHC");
      break;
    default:
      Serial.println("Unknown");

  // Now we will try to open the 'volume'/'partition' - it should be FAT16 or FAT32
  if (!volume.init(card)) {
    Serial.println("Could not find FAT16/FAT32 partition.\nMake sure you've formatted the card");
    return;
  }

e logga questo:

Initializing SD card...Wiring is correct and a card is present.

Card type: SD2
Could not find FAT16/FAT32 partition.
Make sure you've formatted the card

Mentre la LISTFILES usa questo codice:

  Serial.print("Initializing SD card...");

  if (!SD.begin(10)) {
    Serial.println("initialization failed!");
    return;
  }
  Serial.println("initialization done.");

e al contrario delle altre FALLISCE già all'inizializzazione:

Initializing SD card...initialization failed!

Come posso interpretare queste differenze?

@STANDARDOIL:

Ecco, anche se gli sketch di demo falliscono prima ancora di scrivere:

myFile = SD.open("Data0.csv", FILE_WRITE);
  // if the file opened okay, write to it:
  if (myFile) {
    Serial.println("Writing to Data0.csv...");
    myFile.print(datestring);
    myFile.print("   ");
    myFile.print(h);
    myFile.print("   ");
    myFile.println(t);
    // close the file:
    myFile.close();
    Serial.println("done.");
  } else {
    // if the file didn't open, print an error:
    Serial.println("error opening Data0.csv");
    digitalWrite(pin_led, HIGH);  // attiva led di allarme
  }

gporciello:
@STANDARDOIL:

Ecco, anche se gli sketch di demo falliscono prima ancora di scrivere:

io intendevo la parte che andava e che adesso non va più, non il demo
Vedo un po' di confusione, se prima tre datalogger andavano, adesso, ricaricando lo stesso programma vanno ancora?
Poi, la parte di sketch completo che hai messo e la parte della LISTFILES sono uguali, come fa una ad andare a l'altra a fallire?

Standardoil:
io intendevo la parte che andava e che adesso non va più, non il demo

La parte che prima andava e adesso non va più è quella che ho postato prima, il post @STANDARDOIL per intenderci.

Standardoil:
Vedo un po' di confusione, se prima tre datalogger andavano, adesso, ricaricando lo stesso programma vanno ancora?

No, non vanno più, nessuno dei tre e tutti con lo stesso problema. Tutto è successo facendo due semplici operazioni partendo da tre datalogger che funzionavano ma non aggiornavano la data del file come spiegato nel primo post.

Come prima cosa ho settato tutti gli orologi che nella fase di test avevo lasciato a 1/1/2000, poi ho cercato di sostituire la SD con la SDFAT per ottenere la data del file corretta. Dopo qualche tentativo (fallito peraltro) sono tornato allo script originale e mi sono accorto che non loggava più, a quel punto mi sono un minimo impanicato e ho cominciato a sustituire le sd card provando a usare sketch standard per evitare problemi con il mio, poi non riuscendo ho pensato che fosse rotto l'arduino e sono passato al secondo ripetendo più o meno le stesse prove, e poi al terzo portandoli tutti alla situazione attuale.

Standardoil:
Poi, la parte di sketch completo che hai messo e la parte della LISTFILES sono uguali, come fa una ad andare a l'altra a fallire?

Questa è una bella domanda, ma è proprio così, la parte nello script completo segnala inizializzazione ok, quella di listfiles no, è per questo che ho postato i log, sembra incredibile anche a me...

Ulteriore aggiornamento.

Mi ha colpito un meteorite sulla soglia di casa...

Avevo un altro arduino completamente vergine e l'ho montato in uno dei datalogger, collego il tutto e... TATAAA! tutto funziona come prima, quindi il problema è hardware ed evidentemente tre arduini mi si sono fott..ti contemporaneamente allo stesso modo, evidentemente il famoso meteorite me lo sono chiamato io...

Adesso cercherò di capire di che si è trattato.

L'unica cosa che mi viene in mente è che avevo preparato una basetta di test a cui collegavo gli arduini per testarli e programmarli, e questa basetta li alimentava sul vcc con 3,3 v. Poi però, scordandomi che non erano alimentati sul raw, li ho testati sulla stessa basetta ma con una batteria al litio da 3,7v e li ho lasciati andare per qualche ora tutti, può essere stato questo a dargli questo comportamento un po' fuzzy?

Perchè è l'unica cosa hardware un po' fuori norma che hanno avuto in comune tutti nella fase di sviluppo e test, poi solo sketch caricati e ricaricati.

Nessun meteorite, il problema non è HW e dopo un po' di sbattimenti ho anche capito che cosa succede.

Il datalogger è basato come detto sul progetto di Brunello, e quindi l'alimentazione di SD e del sensore è controllata da un mosfet a canale P controllato da un pin di arduino, il pin è normalmente alto per risparmiare corrente e viene portato a basso in occasione delle misure alimentando il sensore e la schedina.

Il circuito è cablato in questo modo e finchè nel codice si gestisce il pin del mosfet va tutto bene, ma gli script che utilizzo per testare la SD e per settare il RTC ignorano completamente il mosfet lasciando SD e sensore non alimentati.

Chiaramente la SD non alimentata non può rispondere a nulla e questo spiega il fallimento di qualsiasi operazione di output, ma ancora non mi spiegavo il crash totale che avevo settando il RTC, finchè non mi sono ricordato che è collegato sul bus I2C in serie con il sensore, quindi ho pensato che il bus possa avere qualche problemino se uno dei componenti collegati non è alimentato e che arduino possa rispondere male a questa situazione.

Aggiungendo la gestione del pin del mosfet a tutti gli script che uso per settaggi e test ho risolto tutto, ma vorrei che qualcuno esperto sul bus I2C mi confermasse i sospetti sul malfunzionamento di arduino in caso in cui un dispositivo presente sul bus non sia alimentato.

A volte anche dover spiegare sul forum il problema aiuta a capire cosa succede, grazie a tutti per avermi fatto da spalla.

Risolti questi comportamenti fuzzy torno a fare esperimenti sulla SD FAT, tengo il 3D ancora aperto perchè sospetto di poter avere ancora bisogno di voi.

Grazie ancora.

gp

Quando c'è qualcosa di non alimentato su un bus comune è altamente probabile che crei casini, perché potrebbe comunque alimentarsi tramite le linee di segnale, ma non a sufficienza, e quindi potrebbe comportarsi in modo sufficientemente strano da rovinare i segnali sul bus. Quindi la cosa è relativamente prevedibile e da evitare.