Writing to flash or sd card on power loss

Status
Not open for further replies.

warpigs330

Active member
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.
 
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.
 
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.
 
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?
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
Status
Not open for further replies.
Back
Top