Unless I need to, I NEVER use a float. I would store the raw data and process it after pulling it from the MSP430. If you can trim the raw data to a byte rather than a 16-bit word, more space is available, as well. If you use float, you will have space for 48 readings (or 64 if you lose the factory calibration data). This is less than the 5 min you want, so is a bad move. When you pull the data from the device, then convert to actual voltage readings.
If you are certain about the range you need, and you don't need other features of the INA219 than voltage (I was figuring that you might also be monitoring current or needed full 12 bit resolution), the MSP430 10bit A/D will do the job. You might need the op amp, depending on supply voltage for the MSP430 and how you use the internal reference. If using the internal flash, you will need to maintain the minimum voltage needed to write, which is more than sufficient for the A/D and internal reference. The internal ref set to 1.5V gives a count of about 0x220 for 0.8V, which won't make it into a single byte. With it set to 2.5V, 0.8V gives a count of about 0x148, which is closer, but still misses, with a resolution of about 2.5mV. Divide the result by two and the resolution is just under 5mV. If this is good enough, I'd do that. Conversion from A/D count to voltage would need to be done as postprocessing, but you cound get 192 readings into the flash, for a time of 960sec (16 min) max at one reading per 5 seconds.
Is 4mV a hard requirement, or will a bit better than 5mV do it for you? If you must have 4mV resolution, than an external op amp would be my choice, with a gain of about 1.6, so that the resolution of the internal 10bit unit will be about 3.9mV. Then, just store the low order byte and you're good with a little margin for greater than 0.8V. If cutting off or shifting the readings to save memory, I would ABSOLUTELY test the data before, and if it is overrange, save the max legal value instead (0xFF) to avoid a step in scale. Or, if you are confident that the voltage won't change too much over the time scale, the step can actually extend the range -- a step from near max to near min indicates going to the next count on the high order byte... I have used this when monitoring armature speed for large motors, where the readings are close enough that a change in speed that could be confused for the scale shift would be easy to identify, as the machine would be damaged beyond oprertion by anything that could do it... you don't stop a 200kW DC prime mover tied to 2 or 300 tons of load in 100ms and not know it.
Just remember that, no matter what, you DO NOT want the input to have an applied potential greater than the supply of the MSP430.
The op amp lets you do a little scaling if needed to stretch the resolution or the range.
If you are just measuring voltage I am wondering why you would need the INA219. Another possible approach would be to use an op amp at a gain of 4 and feed it directly into the A/D of the 2553. Also, since you can have 256 values in a byte then your design requirement of 200 voltage values is achievable.
Flash will be retained after power down. You will also want to build in to you software the ability to read the flash data later. Simplest way is send it via serial.
I might structure things this way:
Initialize (clear) flash triggered by a pushbutton on one input. I would halt after this, so as to require reset before collecting data. This allows clear at the bench and autostartup in the field.
Default to monitoring on power up. Insure that the clear value can never be a valid data written to the flash (not a big deal.. the ina219 is 12 bit. you can easily insure that at least one bit of every 16 bits of used flash is set to 0) so that the powerup can scan memory to find the first unused memory cell for storing the readings. This protects against power failure to the device, allows stopping and restarting monitoring easily, and allows monitoring to go if the device is not properly cleared initially, as long as there is sufficient unused memory. This also insures that reconnecting to suck the data out won't start by overwriting. The monitoring routine should be careful not to overwrite the block used for calibration data, unless you - dont need the calibration, and b- are willing to recreate it if needed later if the processor is reused.
A different button press triggers data dump, or the software can monitor other means for data dump, such as a serial input line.
If you are planning on running for a long time and gathering more data (60 readings is 120 bytes.... can be stored onboard in two blocks of the flash '256 byte information memory', but not a lot more than that will fit), SD cards are a viable option. Search the archives for info. THere is a tutorial, and there is a lot of other info, as well. A bit more code to do it, but well withing the practical.