Handling brownouts during external flash writes
I'd say it depends on the kind of data you are handling which kind of precautions you ought to take.

An important thing you might want to investigate beforehand is: what kind of failures will you encounter because of a brown out, depending on which operation is active (write or erase). Will just the page you are using be affected or might there be more pages affected and corrupted. I've seen wild things with ICs, so I won't make a prediction here.

Another important thing to think about is flash endurance. Flash cells only have a limited lifetime. So make sure that your flash is able to handle the amount of erase/write cycles you are expecting it to have. You might need some sort of rotation or a bigger flash for the rotation if it's too much. An EEPROM has higher endurance typically, so maybe change to that.



Critical data 

(i.e. the device is dead when the data gets corrupted)

For this kind of data, the first thing to do is to evaluate if it actually has to be written at any time during the device lifetime other than during calibration (for example) when the data is generated. During that time you should be able to provide a stable power source.

If critical data has to be written I'd go for several things:


Keep multiple (three or more) copies in different pages
the copies should be write-protect-able independent of each other to make sure an accidental delete is not likely
Make one copy the inverse of the data stored
each copy has it's own checksum (CRC-32 or something depending on the length of the data involved)
Choose an error correction algorithm suited for your application


Examples of algorithms you might choose:


The data includes a counter to indicate the version of the data, each data gets read and the one with the highest counter with a valid checksum gets chosen, the other copies get overwritten with that data.
All data gets read and a two out of three vote gets cast (two sets must be the same with a valid checksum) and the different data gets overwritten, consider what happens if you have one set written, one set deleted and one old set, so you might want to have four sets




Internally generated data

(i.e measurement data)

For this kind of data I'd choose a slightly different approach than the critical data route.

It's kind of like the first algorithm but a bit relaxed. If you have a new data set available, overwrite the oldest data set. It's like a rolling log. To get the correct set, just read the data sets and choose the one with the highest counter and a valid checksum.

Using the write protection intelligently and scattering the data (don't just increment the page with a new data set) will help to preserve the last data set.

Think about what happens if the counter overflows (0 can be larger than 255 in a way).



Received data

(i.e. firmware update)

For data which you are receiving, you need a protocol which supports resuming the transmission at any given point. Usually I'd go for checksums for each page written. If the outtakes are likely to happen frequently, maybe do two checksums per page.

Then to resume the operation, read the flash and check the checksums until it doesn't match anymore and tell the sender to resume transmission after the last valid byte.