RE: RFC - fix to at49xxxx crash during erase/program when interrupt happens

[Øyvind Harboe <oyvind dot harboe at zylin dot com>]

>I doubt that disabling interrrupts is a good solution, 
>because erasing flash blocks (especially bigger ones)
>can take rather long, so you will most likely loose some.

Given that todays behaviour isn't acceptable either, another
solution is required.

Perphaps using the "suspend erase" which is supported by the
at49xxxx?

Also the io/flash routines does not seem to provide a mechanism
that allows the driver to control how large blocks to program
at the time(while interrupts are disabled). The solution I
use today is to send small chunks to flash_program() from the
application, but I'd prefer this nastiness to be hidden in the
flash drivers.

If the io/flash left it to the low-level drivers to deal with
all the code between FLASH_Enable/FLASH_Disable(), I could 
more easily see how the driver could deal with these issues and
hide everything from the appliaction.

>Another solution that comes to my mind is to relocate interrrupt 
>handlers and DSRs to RAM using .2ram.* linker sections. This 
>would allow interrupts to continue while erasing flash blocks, 
>if the entire work is done in those handlers and no threads 
>are involved. This is still a severe limitation.

I like this solution(a slight ram cost), but how can you verify
(preferably at compile time) that all ISRs/DSRs in the universe 
follow this rule?

>If at all posssible, I would try to build an application 
>that needs to erase or reprogram flash memory using the 'RAM' 
>or 'ROMRAM' startup types. I think that everything else can 
>easily get messy.

I tried building a ROMRAM app for my eb40a application, but I
failed miserably(it didn't boot).

However, since my application is much bigger than the available RAM,
I have no choice but to run out of flash. Hence I didn't follow
up on the ROMRAM problems I ran into.

Øyvind