cancel
Showing results for 
Search instead for 
Did you mean: 

UART overrun when Erasing Flash Page

tellis
Associate
Posted on February 23, 2010 at 22:22

UART overrun when Erasing Flash Page

3 REPLIES 3
Posted on May 17, 2011 at 13:41

>>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.

-Clive
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
picguy2
Associate II
Posted on May 17, 2011 at 13:41

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

....

tellis
Associate
Posted on May 17, 2011 at 13:41

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!