BOD to save sd file

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, 

 

I assembled a simple logger, that logs data to an sd card. At the very beginning of the program (in init) I open a file on SD card, in the while(1) loop I save data into it, and when I power off the device, a function closes this file. So far so good. 

Since this is working from battery, I set the brown-out detection fuses to 2.7V. I experienced, that when the battery is running low, the BOD performs a reset, which makes the unclosed file on the sd card corrupt. 

 

There is a LED, that lights up before the while(1) loop in the init section. I noticed, that after the BOD triggers, a reset is performed, and the LED illuminates as long as in normal operation. 

 

I wonder whether it is possible, to close the unclosed file after this reset, like this:

int main (void)
{
    if(MCSUCSR & (1 << BORF))
    {
        // Close the unclosed file
    }
    ...
    ...
}

 

Does anybody have experience with it?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Sure you can - you just have to make sure that the battery has enough life left at the point the BoD triggers to successfully complete the file write & close.

 

You might consider "flushing" (ie, making sure everything is actually written to disk) at regular intervals - to minimise loss from an unexpected restart or loss of power.

 

http://elm-chan.org/fsw/ff/doc/sync.html

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Unless you truly are writing continuously why don't you f_sync() after each substantial write. Or even f_close() then reopen the file in append mode before each write.

 

FAT is an inherently dangerous system when it comes to power fail. It has no mechanism to effect recovery (unlike other "journalling" file systems) so it is almost inevitable there will be corruption.

 

I used to work on a product that used Compact Flash cards with FAT format in a unit that would be placed in a retail space and the shop owners would just switch it off at any moment when the shop was being locked up at night. We used to get a constant stream of cards back so I looked at using jornalling filesystems but this was only possible as it was a Linux solution.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

yoman91 wrote:
Since this is working from battery, I set the brown-out detection fuses to 2.7V. I experienced, that when the battery is running low, the BOD performs a reset, which makes the unclosed file on the sd card corrupt. 
In lieu of an AVR BOD, an external supervisor can cycle power; some SD cards have a required, designed, tested, and demonstrated power failure recovery.

 

edit : one make of several

Industrial microSD H1-M - microSD - Industrial Card - SSD - Apacer for Industrial – Leader in industrial SSD and DRAM module

[datasheet, bottom of page 2]

‧Power Failure Management

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Nov 26, 2021 - 12:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
FAT is an inherently dangerous system when it comes to power fail.
Likewise exFAT.

Could attach an EERAM as a buffer; if not low battery then FAT open, copy from buffer, FAT close, empty buffer.

 

The Cons of exFAT | exFAT File System: Everything You Need To Know (2021) (MiniTool® Software)

Serial EERAM | Microchip Memory Link

AN3171 - Migrating from FRAM to EERAM | Application Note | Microchip Technology

8 - Most Brown-Out Reset Circuits Don't Work | Designing Hardware/Firmware for Low Power MCUs by Jack Ganssle

 

edit :

MiniTool Data Recovery Software for Windows & Mac | MiniTool® Software

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Nov 24, 2021 - 04:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Formerly, when I designed a GPS logger, I exactly did so. Opened the file in append mode, write the stuffs, and the close it. However I noticed that this open-close routine takes relativley long, and makes the sampling time lower. In this application I actually logging continuosly, and with the open-close routine the data that was logged was unusable.  

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using a 1.0F supercapacitor, I hope/guess it will be store enough battery life for this operation. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

With a 1F capacitor you could use the ADC or AC to check when the supply-voltage is getting low and then do a clean shutdown with an f_close()

You can use an approximation of t = ( C * dV ) / I to get a rough idea of how much hold-up time the capacitor will provide.
t time (seconds)
C the capacitor (Farads)
dV how much change in the capacitor voltage you can tolerate. (eg, maximum supply - BOD setting)
I Amps drawn from the capacitor. (Note that the SD card will draw a substantial current when writing and will need possibly tens of mlliseconds to complete)

Doing an f_sync() at regular intervals is a Good-Idea.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

yoman91 wrote:

Formerly, when I designed a GPS logger, I exactly did so. Opened the file in append mode, write the stuffs, and the close it. However I noticed that this open-close routine takes relativley long, and makes the sampling time lower. In this application I actually logging continuosly, and with the open-close routine the data that was logged was unusable.  

But as I say FAT was not designed for this. In fact, if you are old enough cast your mind bask to MS-DOS and using floppy disks. Do you remember how you were always having to run "chkdsk" and it would perennially report "orphaned links found" and create fileNNN.chk files on the disk with the "recovered" data? That was because there was no accepted shutdown process for PCs in those days. You just turned off the switch at the wall. If a (FAT format) disk was being accessed at the time the FAT system was (usually) corrupted.

 

The way to mitigate this is to flush or close/append regularly. Yes it may hit performance but if you are doing FAT in an environment where power fail is likely it's almost unavoidable.

 

I suppose you could devise a system where data is initially cached to some kind of non-volatile (maybe FRAM?) and then it is flushed from there to the disk separately but you still risk power fail during FRAM to SD transfer too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

clawson wrote:
FAT was not designed for this.

I believe there are (commercial?) embedded filesystems intended for this?

 

I suppose you could devise a system where data is initially cached to some kind of non-volatile (maybe FRAM?)

Or maybe the system should just use the non-volatile memory - and the data is only sent to the SD (or other collection means) when it is known that power is good & stable ... ?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

I just tried a google for "powefail safe filesystem for embedded" - some very interesting looking results !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

awneil wrote:
I believe there are (commercial?) embedded filesystems intended for this?
FAT with optional journaling :

https://github.com/weston-embedded/uC-FS/blob/develop/FAT/fs_fat_journal.h

 

Coffee File System has micro logs :

https://github.com/contiki-os/contiki/wiki/File-systems#coffee (in second paragraph)

 

Likely more file systems with 8-bit MCU RTOS.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using a 1.0F supercapacitor, I hope/guess 

 

Engineering isn't about hoping...

 

As Mikech provided, one can at least estimate the runtime post power loss.

 

And then one goes and measures it on their prototype on the bench!

 

Perhaps you already know this, but I'll mention it anyway.

 

You can use the ADC, or AC and a pin change interrupt, etc., to trigger the "I lost power" shut down sequence.

You can't, however, just put the SuperCap on the V+ rail and watch the V+ rail.

That is a poor approach to this problem.

 

An alternative approach is to feed the V+ supply through a schottky diode, (with a very low forward voltage drop).

 

The SuperCap sit on the far side of the diode, and that power rail powers the micro and the SD card.

Non-critical stuff, with which a power loss can be tolerated, is powered of the original supply.

These items therefore don't drain the SuperCap.

 

The micro monitors the supply voltage before the diode and SuperCap, so it can see when the power supply starts to fall.

 

This saves some additional time compared to when the SuperCap voltage starts to fall.

 

Often, in these setups, every mSec counts.

 

JC

 

Edit:  Remember, also, that the writing data current draw of the SD card may be significantly higher than the steady state current draw of the SD card.

Don't get surprised by this when the SD card draws more current during the shut down sequence than you expected.

 

JC 

 

Last Edited: Thu. Nov 25, 2021 - 11:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, you are right about the hoping, calculating the necessary capacity for the job would be the best solution, but since this project is done only for myself, I just grabbed one from my capacitor bag. 

 

Regarding the ADC, my first thought, that with this the on time will be shorter - define at which battery level stop the process and save the file. 
That's why I wanted to use the BOD, to give me extra time for the logging - even if it is just 5 minutes more. 

 

Now I have to admit that even if this solution can work, I will never be on the safe side.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
Don't get surprised by this when the SD card draws more current during the shut down sequence than you expected.

+1

 

and remember that this is happening when the battery is at its weakest ...

 

You can't, however, just put the SuperCap on the V+ rail

Indeed.

 

An alternative approach is to feed the V+ supply through a schottky diode

and, of course, there are chips specifically designed to manage supercaps as a "backup" supply ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yoman91 wrote:
this project is done only for myself

yoman91 also wrote:
Now I have to admit that even if this solution can work, I will never be on the safe side

So the question is: is just flushing the data to the SD Card good enough for this personal, 1-off application?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So the question is: is just flushing the data to the SD Card good enough for this personal, 1-off application?

 It will do it at the current project, but later I will consider all the comments I got on this topic. Maybe one thing I can do is to hook up the battery to the ADC. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yoman91 wrote:
hook up the battery to the ADC. 

But make sure that doesn't drain the battery!

 

You also need to think carefully about when you sample it ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's why I wanted to use the BOD, to give me extra time for the logging - even if it is just 5 minutes more. 

???

 

I think you might not understand how the BOD works.

 

When the V+ falls under the BOD threshold then the micro shuts down.

Right then!

You don't get the chance to run any code when the BOD fires.

 

This protects the micro's memory from corruption.

 

The concept is to use the ADC, (or AC), to let you know when the power supply is falling, but while you still have several mSec's of energy left with which to save the data.

 

The BOD is then still going to trigger, and formally shut down the micro, but hopefully not until you have already done your data storage, and are now just sitting in a Do (Nothing) Loop, or watching to see if the power suddenly comes back on.

 

JC  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think the approximate shape of a thing that would probably work is (1) charge a capacitor while power is high, (2) don't discharge it yet, (3) if you detect voltage going low, (4) now allow the capacitor to discharge and provide additional voltage, bringing your power supply back up enough long enough to let you cleanly shut down.

 

 

depending, you might want to have something where the writing is handled by a separate system that you control indirectly from your primary microcontroller. even then, it's still sorta potentially risky, and FAT is probably not the best choice.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Use Schottky diodes 1N5818 for D1 and D2.

 

 

Edit: I am using one pin of ATmega to detect power-off, and start housekeeping.

Last Edited: Sat. Nov 27, 2021 - 06:50 AM