No it's not necessary.
You can write on the information memory while the code with the writing instructions is executed from flash. Not only the information memory, but the whole flash (except the code section which actually writes the flash) can be written from flash.
Actually the flash controller of the MSP430 handles it quite intelligently, while it states in big scary sentences that:
Reading from or writing to flash memory while it is being programmed
or erased is prohibited. If CPU execution is required during the write
or erase, the code to be executed must be in RAM.
This sounds a bit intimidating at first, but if you read through the whole chapter (highly recommended) you will stumble upon information which tells you, that while the flash controller is busy, a read from the CPU will return 0x3FFF which turns out to be the opcode for JUMP PC (jump to the program counter) which will just stall the CPU until the flash controller is finished doing it's thing. (2)
The block write mode is not supported from flash, so you won't be able to get the fastest write times if you execute your write from flash. I'd say if you just want to write some calibration values or serial numbers, it won't matter much. If you try to implement your own bootloader to flash the whole device, you better run it from RAM and use the block write mode to gain speed.
Just be careful with the erase instruction first to actually delete only the stuff you need to delete, I accidentally lost all calibration information once because I wasn't.
Yes. Obviously you can send multiple packets.
There is a tradeoff between efficiency, and the cost of getting a packet wrong. With small packets, there is more total overhead for the amount of data actually delivered. However, if there is a error, less data will have to be re-sent.
That all said, data errors are, or at least should be, rare. Generally you send maximum-size packets until there is less than a full packet of data left.
Their checksum algorithm is rather a joke, let's say "primitive" at best. Smaller packets have more checksum protection because there are effectively more checksum bits per data bit.
Of course you aren't stuck with this bootloader. You can write one that does whatever you want. See this question for more information on bootloaders in general.
More on verification
As Peter pointed out in a comment, data correctness is essential in a bootloader.
That is a good argument for ditching this bootloader and it's ridiculously naïve checksum algorithm. What I usually do is not even attempt to checksum individual packets. I design the protocol for reasonable efficiency, but add a good checksum to the whole image.
Communicating the data from the host to the device is only one part of the problem. It then has to be written correctly to the non-volatile memory. That's actually much more likely to fail. A power glitch, or the user hitting the reset button at a bad time can cause corruption, for example.
My strategy is generally not to worry about the possible errors in individual steps of the process, but to verify the final result. I usually put something like a 24 or 32 bit CRC checksum at the end of the uploaded image. Before the bootloader runs the main app, it verifies the checksum. If it fails, it requests a new image, runs the previous image, signals error, or something. Never ever run a corrupted image.
From a comment:
The binary file contains a Firmware (some .c and .h and libraries generated with an embedded IDE like Keil) .. How to add this checksum to the image itself? Is it safe to modify such a file?
No, the binary file doesn't contain any .c and .h files. It's a binary file. You need to step back and learn what the compiler, librarian, and linker each do, and what kind of information is in the various file types. You can't go about developing code where you're close to the hardware without understanding these things.
Adding the checksum to the binary file (often in Intel Hex format) is one way to
add a checksum to the image. You could write a separate tool that runs after the linker. This tool reads the image, computes the checksum, and embeds it back into the image at a known place.
Another way is to have the uploader program add the checksum on the fly. The uploader reads the unmodified binary file, and adds the checksum at the known locations, usually the last few bytes of the image. This modified image is then sent to the bootloader, but the binary file is never altered.
Best Answer
If you are using less than 50% of your internal flash (and the new SW is also < 50%) then you could load the new software into the upper part of that memory, test it runs and then copy into the lower half once you're happy.
You would need some sort of bootloader to do this however, I'm sure there are plenty of STM32 guides on how to do this. Your approach of using the external flash memory is fine too, and would allow you to perform a CRC on the new SW image data once it has been transferred over before copying it into your internal flash. I'm not sure if the STM32 will allow you to execute code from the external flash though.
A bootloader is usually a small section of the internal flash which is written to handle all this, but this code needs to be well tested as you can usually only update it back at base (physical connection to a programmer) and not usually OTA.
Guide here
STM guide: STM