Writing to Flash and FPGA

As I am collecting the statistic of how the TCP receiver buffer size affects the speed of downloading, I found that the time it takes to download the firmware topped at around 11.6 seconds with 512byte of receiver buffer size, which is in fact very slow, further increase of receiver buffer size will not increase the speed anymore. Then I try to change the buffer size of each Net_Pres_SocketRead along with the receiver buffer size, turns out the time it takes cut down to a minimum of 1.5 seconds. Hence this is the bottleneck when the receiver buffer size is large enough.
The configuration data stored in FPGA is volatile, which means we will lose it after the power is off because the memory unit of FPGA is SRAM.  Therefore my next objective is to write the firmware from the web server into the flash memory of pic32 first, instead of directly into the FPGA so that the firmware can stay after power off, and then reboot itself from the flash after the power is on again. Keeping a copy of PUT request (including the firmware) in the flash also help us to deal with computing checksum and the parsing of PUT request header.
As Dr. Shawn said, any reading from the network is not guaranteed, Net_Pres_SocketRead() may not return the exact amount of data I requested if the network is somehow intervened. Previously as we write directly into the FPGA this is okay because we write to FPGA bit by bit, so if the Net_Pres_SocketRead returns less byte, then we simply write less byte to FPGA and then the next write will still continue. The problem of writing to flash memory is that the minimum write to flash is a word long (4 bytes), and the flash write function will ignore the last two bit of the destination address (which means the same thing, each address point to one byte of data so two bit is 4byte). Hence, if the Net_Pres_SocketRead return less byte and I still feed that into flash, then I can not start the next write from the address it left off, and skipping just one bit of address meaning the whole 144byte of firmware is corrupted and useless. So what I do is I allocate a 2kB buffer (a row of flash memory is 2kB), read from Net_Pres_Socket into the buffer, get a pointer to point to where it left off and append the buffer until I fill up full 2kB while it is still in the SRAM, and then perform a flash row write so that none address is skipped.
Afterward, I wrote a function to configure the FPGA from the flash memory, and call it in system initialization so that FPGA will be configured everytime the system started. But then I realize the data is corrupted, and I thought my manipulation of pointer has bug. I spent almost two days to debug but found nothing, my code is alright. Finally, I “desperately” try to change the flash row writing function to quad-word writing 128 times (a row is 2kbyte, a quad-word is 16 byte) and it worked, the done bit of FPGA is set meaning the firmware is intact. Turns out the flash row writing function is faulty, yet it is definitely my bad to try this after 2 days and get behind schedule. Obviously, I am in lack of a hell lot of experience, good news is that lesson is learned.