2010-02-23 01:22 PM
UART overrun when Erasing Flash Page
2011-05-17 04:41 AM
>>Has anyone run into this symptom?
Yes, it will be a problem writing or erasing flash. Increasing the clock speed will mitigate this somewhat, as will using flow control on the serial port. I have observed this problem writing to flash using a wireless modem and HTTP. Access to the flash is slowed when the flash controller is active. Pushing the interrupt vectors, and code into RAM might also solve this, but if you run subroutines in FLASH it will again stall the servicing of the USART sufficiently to get receiver overruns. The USART desperately needs a FIFO behind it. You could also do Receive DMA, but the code to do this with for random streams of incoming data is a bit awkward, and you could still get data loss unless it was in circular mode. -Clive2011-05-17 04:41 AM
The simple answer is to 100% stop using flash when updating flash. I.e. process or buffer everything in RAM. If it were me I would poll UARTs during this time as one would do on a CPU without interrupts. Or move vectors to RAM or (my way) disable interrupts totally.
Join the chorus: We need EEPROM We want EEPROM ....2011-05-17 04:41 AM
Thanks for the input!
Fortunately out communication is such that we send a response to any command sent, and no more characters are received until we send this response. Moving my flash update work into the code before we send the response, rather than signaling an asynchronous update task should work for me. Being aware of this behavior when writing to flash should be helpful to avoid future problems. Thanks again!