Re: [ECOS] FLASH API v.2 and interrupts

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Iris" == Iris Lindner <ilindner@logopak.de> writes:

    Iris> Hi everyone,
    Iris> (Please excuse if I have overlooked a solution to our
    Iris> problem in mailing lists for example.)

    Iris> we have the following problem with our system (using redboot
    Iris> romram mode): We can't properly harmonize flash operations
    Iris> and interrupt handling. There are regularly frames coming in
    Iris> on CAN bus (lifesign signals of the nodes) which have to be
    Iris> treated.

    Iris> We use Version 1 eCos FLASH API (chip: Spansion S29GL256P)
    Iris> and get terrible crashes (including completely empty flash
    Iris> afterwards) when interrupts are NOT disabled and flash is
    Iris> programmed for example when meanwhile CAN bus traffic is
    Iris> increased.

    Iris> If we disable interrupts on device driver level
    Iris> (HAL_[DISABLE| RESTORE]_INTERRUPTS()) flash operations all
    Iris> work fine but CAN frames get lost and the task goes offline
    Iris> (-> whole machine no longer able to work).

    Iris> Could Version 2 of eCos FLASH API solve the problem? (It is
    Iris> interrupt safe now, isn't it?) Do you need more information
    Iris> about our system/configuration (I'm not sure about what
    Iris> details are useful to know)?

    Iris> Thank you very much in advance for your help, I'm looking
    Iris> forward to any comment!

As a general rule, interrupts and updating NOR flash do not mix. While
a flash erase or program operation is taking place the flash is
unusable for anything else (there are complications with some flash
chips supporting multiple banks, but I don't want to get into all the
unpleasant details). If an interrupt occurs during this time and the
interrupt handling code needs to access the flash, you are in trouble.
If an interrupt results in a context switch to another thread and that
thread needs to access the flash, you are also in trouble. If the
application is being debugged via a ROM RedBoot executing from flash
then hitting a breakpoint or calling printf() or diag_printf() will
call into that ROM RedBoot, which means code trying to execute from
flash.

By default the anoncvs AMD V2 driver (which I think is what you would
want for that Spansion chip) avoids crashes by completely disabling
interrupts around the program and erase operations. Hence it is safe,
but interrupts can remain disabled for a long time.

On some hardware there will be an active configuration option
CYGIMP_DEVS_FLASH_AMD_AM29XXXXX_V2_LEAVE_INTERRUPTS_ENABLED, which is
off by default. Toggling this option means that the flash driver will
no longer disable interrupts. However, you are responsible for making
sure that nothing else will access the flash while an erase or program
operation is happening. That means appropriate locking within your
application, not debugging via a ROM RedBoot, and quite possibly other
complications depending on your hardware. It is a lot easier for
something like dataflash rather than NOR flash: the dataflash is not
directly accessible to the cpu so you will never have RedBoot
executing out of it.

On other hardware the flash driver has to disable the cache before it
can talk directly to the flash chip. You do not want interrupts or
context switches while the cache is disabled, the resulting system
performance would be terrible. The LEAVE_INTERRUPTS_ENABLED option is
not available on hardware like this.

So, switching to the V2 API would prevent the crashes. It would no
longer be necessary to disable interrupts in your own code, instead
that happens in the driver. However, a switch would not address the
performance problems unless the hardware supports
LEAVE_INTERRUPTS_ENABLED and you can guarantee that its requirements
are satisfied.

There is a more advanced version of the AMD V2 driver which disables
interrupts for shorter periods of time. Writes happen in burst with
interrupts briefly reenabled between bursts. Similarly erases happen
in bursts, using the erase suspend/resume facilities available in most
NOR chips. Interrupt latency is much improved but still not great - if
the erase bursts are too short then the chip may never make any
progress. The details vary between flash chips. This more advanced
driver is currently only available from eCosCentric.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
       >>>> Visit us at ESC-UK  http://www.embedded.co.uk <<<<
       >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<<

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss