No, I still think we need to leave that code in. It's a peculiarity with the NXP flash process, rather than how EBlink handles the buffer.
If I have a file to flash that is 1032 bytes long, that will be one full flash sector of 1024 bytes and only the first 8 bytes of the second sector. Flashing the first sector is no issue. Flashing the second sector is a problem. The flash routines on the chip cannot flash only 8 bytes. I'm forced to flash at least 64 bytes at a time. So I have to flash 8 bytes of data and 56 bytes of blank. If I do not include the above code that fills the on chip RAM buffer with those 56 blank bytes, it will program whatever is in the RAM at the time of the call to the flash routine. That is a failure state.
If I have a file to flash that is 1032 bytes long, that will be one full flash sector of 1024 bytes and only the first 8 bytes of the second sector. Flashing the first sector is no issue. Flashing the second sector is a problem. The flash routines on the chip cannot flash only 8 bytes. I'm forced to flash at least 64 bytes at a time. So I have to flash 8 bytes of data and 56 bytes of blank. If I do not include the above code that fills the on chip RAM buffer with those 56 blank bytes, it will program whatever is in the RAM at the time of the call to the flash routine. That is a failure state.