Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 14 of 14

Thread: Writing to flash or sd card on power loss

  1. #1
    Junior Member
    Join Date
    Oct 2020
    Posts
    14

    Writing to flash or sd card on power loss

    I am working on a project with the teensy 4.1 that I want to be able to detect a loss of power and save some things to flash or the sd card. I am looking at this circuit that provides a capacitor for a brief bit of power and a line that detects the state of the power input. https://i.stack.imgur.com/JyQtz.png

    My question is what size capacitor should I use/how long is needed to write the contents of the ram + add on psram to either the onboard flash or sd card? My project essentially takes a recording of an analog input and stores it in ram as an array. I want to save these arrays + a few variables so when power is lost the device can return to (more or less) the same state it shut down in. Thanks for any help you can provide.

  2. #2

    How about a separate battery instead?

    I have a similar requirement and am looking at using a miniature solid-state relay https://www.mouser.com/ProductDetail...gVIAtZ8A%3D%3D to switch over to a lithium button cell in the event of a power outage. Haven't tried it yet, just thought I'd mention it as a possible alternative. If you implement it I'd appreciate it if you'd post any lessons you learn.

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,118
    The answer depends on so many unknowns. Nobody could possibly give you a definitive answer. The best anyone can do is help you figure out which things you need to know, or just make up some numbers by sheer guesswork.

    The most important is how you detect power loss. The father "upstream" you can detect the power loss, the more time you have to react. The very best way, but also the most difficult in terms of circuitry, is detection of the actual AC waveform. If you have a linear power supply with access to the low voltage AC waveform, you might be able to use resistors to scale one or both sides of the transformer to a signal you can watch. If you can detect the AC peaks are over some threshold every 8.3 ms (or 10 ms if 50 Hz power), then you tell when power has been lost with only about 10 ms latency. That's the very best way, since you still have all the energy stored in the higher voltage capacitor before a 5V regulator.

    If you can only sense at the 5V power, you get much less time. By then the input to the 5V regulator has already fallen to the point it can no longer keep 5V regulated.

    Hypothetically, let's imagine you can't get access to monitor the AC waveform, so you detect when 5V has fallen to 4.5V. Teensy can keep its 3.3V regulated until the input drops to about 3.6V. So the voltage can drop about 0.9V from detection until you complete backing up data.

    The 2 other big unknowns are how long the backup takes, and how much extra power does the SD card or other hardware consume while writing. Let's just guess the SD card adds about 100mA extra current, so the total current draw will be 200mA during most of the time backing up. And lets guess the backup process takes 50ms.

    The capacitor question is i = C * dv/dt. If we treat dv and dt as delta voltage and delta time (horrific to mathematicians who love calculus but a reasonable approximation), then we just rearrage the equation to C = i * dt / dv. Plugging in i = 0.2, dt = 0.03, and dv = 0.9, the answer is C = 0.0067 farads. So it looks like the answer is you'll need a 6800 uF capacitor.... if all this guesswork is on point.

    Obviously if you can sense the AC waveform, the capacitor requirement gets easier. Then you're looking at the capacitor before the 5V regulator, which presumably can drop much more than 0.9V. And it's probably already big enough to last many milliseconds, because it needs to keep the voltage up for at least the 8.3 or 10ms between AC waveform peaks.

  4. #4
    Senior Member
    Join Date
    Jul 2020
    Posts
    985
    Switch-mode power supplies don't need such large capacitors as they can pull power from the waveform
    when its well below peak voltage, and thus don't have to store as much energy as a linear/transformer
    supply.

  5. #5
    Just started looking at this processor; I'm more familiar with the ATSAMD51 Cortex-M4 chip, which offers brownout detection and automatic switching to a backup power supply. Sadly, after a brief search through the Processor Reference Manual it doesn't appear that this processor has those features.

    Is that correct?

  6. #6
    Junior Member
    Join Date
    Oct 2020
    Posts
    14
    So this is for a eurorack module. Meaning that it gets +-12v into the module. I then use a 5v linear regulator to power the teensy. I basically can't expect to access the state of the power anywhere before the output +-12v power supply for the eurorack case.

    Basically the concept for the module is that you can record the movement of a slider and have it play back as modulation. Sort of like drawing your own LFO, or automation in a DAW. You press a button to start recording the position of a slide pot. When you stop pressing the button the recording is looped as CV. You can also adjust the speed of playback of the recording, and a few other small things.

    One of my favorite aspect of analog gear is that when you power it off and power it on again it is in the same state as you left it because it just depends on the position of the knobs. Because of this I want the module to power on in the same state it powered off in. (more or less, the same recorded loops at the same speed). I thought it would be cleanest (conceptually) to be able to detect a loss of power and backup my data. Another solution is to write to memory any time a new loop is recorded or a parameter is adjusted on an existing loop. I am worried about the frequency at which the memory is being written to in that case though.

    Do you think 50ms is about the amount of time to write around 8 MB to flash/SD card? Is there a way to tell when a file is finished writing? if so I could make a test and time the write speeds. Do I need to worry about constantly writing to the SD card or flash? Any suggestions for other ways to solve this problem? Thanks so much for all the help.

  7. #7
    Senior Member
    Join Date
    Jul 2020
    Posts
    985
    8MB? SDcard? No, that's going to take a while I think.

    You don't want to let that amount of data go without backup anyway, so why not flush it to backing store
    regularly so there's never that much to write in an emergency?

    After a certain period of idle you can just backup the working state anyway.

    Critical state I'd ping-pong between two files, and have a checksum. That way you can back-off to the previous state
    if the last one got corrupted.

  8. #8
    Senior Member fdaniels's Avatar
    Join Date
    Oct 2020
    Location
    Ostwestfalen, Germany
    Posts
    109
    What type of "knob" do you record for 8MB Data??!?!?!?

  9. #9
    Senior Member
    Join Date
    Jul 2014
    Posts
    3,156
    Quote Originally Posted by warpigs330 View Post
    Do you think 50ms is about the amount of time to write around 8 MB to flash/SD card?
    make the math: 8MB in 50 ms is 160 MB/s or 1.28GBit/s.

  10. #10

    Thoughts on using flash devices to store your data

    If there's an alternate way of representing your data that reduces its size, I'd use it.

    Any flash memory, including SD cards, has a life of approximately 100,000 write cycles. If you write to the same physical locations repeatedly, that's what you can expect. Backing up the working state periodically may get you to this limit faster than you'd like.

    Using a file system on an SD card will add overhead tasks (e.g., reading & writing directory entries, etc) that decrease throughput. For higher speed, go with raw writes to physical pages. Another advantage of this approach is that you can divide up the SD card into blocks of pages, with each block big enough to hold one backup. Start with the first block and proceed through them until you reach the end, then erase and start over. This will spread the wear across the entire chip, significantly extending your SD card's life.

    In order to avoid searching for the next unused block when time is short, I'd create my own custom "directory" section at the beginning of the SD card that identifies the next block available for writing (you can update a previously-modified page in flash as long as you write to values that haven't been previously written; each byte in an erased page will be set to all 1s - 0xFF. When you update a page, read the entire page into memory, modify the byte(s) you want to change then write the entire page back to flash). On startup, read this 'directory' to locate the next available block and store it in RAM so you don't have to figure it out as power fails.

    An alternate to the "directory" is to set the first byte of each "used" block to a value that isn't 0xFF. Then at startup you could walk through the blocks looking for the first one with a first byte = 0xFF.

    One last thought; you may want to consider soldering a PSRAM and QSPI flash chip to the back off your Teensy and using the faster QSPI interface instead of an SD card. Downside is it's not as easily removable.

  11. #11
    Senior Member
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    203
    You could consider one of these. It provides 5v (and 3.3v) for the Teensy. It is powered from a usb psu. You could solder a wire to the battery connection and shut down and save data to sd card, or whatever, when voltage gets down to about 3.5v. You may well find that given the capacity of a 18560 battery that you never have to save the data because the mains power comes back on long before the battery is getting near depleted.
    They only cost $4 and is a ready made solution.

  12. #12
    Senior Member
    Join Date
    Feb 2018
    Location
    Corvallis, OR
    Posts
    334
    Quote Originally Posted by SapientHetero View Post
    In order to avoid searching for the next unused block when time is short, I'd create my own custom "directory" section at the beginning of the SD card that identifies the next block available for writing (you can update a previously-modified page in flash as long as you write to values that haven't been previously written; each byte in an erased page will be set to all 1s - 0xFF. When you update a page, read the entire page into memory, modify the byte(s) you want to change then write the entire page back to flash). On startup, read this 'directory' to locate the next available block and store it in RAM so you don't have to figure it out as power fails.
    Or you could consider using an SD File that is pre-allocated. This avoids the necessity for the file system to scan the FAT to find the next file cluster.

  13. #13
    Member
    Join Date
    Jan 2020
    Location
    Port Elizabeth
    Posts
    71
    This is a fascinating question since most of us face the same problem, one way or another.
    I considered the big capacitor solution, liked it but had to discard it when I found there was not enough space on my board. Instead I do this.

    1) I use a FRAM instead of an SD card because I can write to it an almost infinite number of times and it is faster.
    2) Every second I write alternately to one of two configuration/state files and at the same time write a checksum.
    3) On power up I use the most recent file that has a correct checksum.
    4) I can detect a power outage during writing because the checksum will be incorrect.
    5) In that case I use the alternative configuration/state file which will be no more than one second out of date and at least one of the configuration/state files will have a good checksum.

    This has worked very well for me. I routinely switch off the board without any concerns for its state. My log files tell me that occasionally I had to use the backup, one second older state file, on startup. This strategy has never failed me. Potentially a double-dip power outage exactly one second apart at exactly the time I was writing the state file, could compromise both state files. This seems very unlikely. I have considered writing a third file so that I have three generations of state file, one second apart. I might still do that because recovering from a two seconds older state file has a negligible impact on my system.

  14. #14
    Junior Member
    Join Date
    Oct 2020
    Posts
    14
    Thanks for the ideas. That sounds like a good solution. Also it is not critical that I not lose data, just a user experience consideration.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •