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

[Iris Lindner <ilindner at logopak dot de>]

Dear Stanislav, dear Bart, dear Paul,
thank you very much for your detailed and helpful response!

> I have no problems writing in a jffs2 filesystem on
> a Dataflash device while processing interrupts from
> timer, network card, CAN controller, so I suppose
> the V2 API is pretty safe.

That's good to hear. =) Currently I try to update our existing configuration. 
I removed the old API ("Flash device drivers" in config tool) and the device 
dirver itself ("AMD AM29XXXXX FLASH memory support"). After inserting the new 
packages and updating ecos.db I could change our template and so insert the 
new device driver and API into the configuration. Unfortunately I can't 
compile yet, first error is:
../cyg/io/am29xxxxx_dev.h:81: Fehler: Fehler beim Parsen vor "cyg_flashaddr_t"
(error parsing before "cyg_flashaddr_t")
Still investigating...

> I'd check the following first:
>
> - I don't know the flash chip - what driver are you using?
>   Are there time-critical tasks that can't be interrupted?
>   What driver model - nearly everything in ISR, or does DSR
>   take care of the transfers? Interrupt-driven or polled?
We used the old V.1 API and driver ("AMD AM29XXXXX FLASH memory support") eCos 
packages. Except from the flash update operations (see also Bart's response) 
no more non-interruptable operations as far as I can see (using interrupts 
and their ISRs).

> - Check the math - time to transfer data to flash or to check
>   whether the flash completed writing versus shortest CAN frame,
>   CAN bus speed and buffer depth of your controller. Shortest CAN
>   frame at 1 Mbit takes tens of microseconds, how much time
>   does transfer of a data page to your flash take (here
>   the interrupts normally have to be disabled)?
Our shortest CAN frame has 58 bits, the baudrate is 125 kBit. 
The device is only able to store one frame - so at least every 464 us the 
CAN-interrupt must be able to be executed.
Sometimes it is necessary to transfer bigger files (up to 3 MB) to flash which 
takes several seconds. (But I haven't measured time yet for transferring a 
data page...*to do*)

> - Are you accessing the flash from several threads?
>   Especially triggered by reception of a CAN frame?
>   The link to crashes are not necessarily the enabled
>   interrupts per se, maybe they are just triggering something
>   else.
No, normally everything _should_ be fine... Every task could access flash but 
only via the same interface where we have locking/semaphores. A CAN frame 
cannot trigger anything which leads to flash access (in theory).

Am Mittwoch, 7. Oktober 2009 18:55:40 schrieben Sie:
>
> 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.
Ah, that's valuable to know! I think all these three cases do not match at our 
system but I'll dig deeper into it to become sure.

> 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.
Ok, so that would probably be the same behaviour as with our old driver where 
disabling interrupts has manually been inserted. As result we get stable 
flash behaviour but that frame loss phenomenon which results in a disabled 
can bus...

> 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.
I couldn't find disabling of cache in sources or chip documentation.

> 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.
So I think I could try to use the driver with interrupts left enabled and 
making sure that flash is not accessed from somewhere else, right? But when 
the machine is running it is absolutely necessary to keep the can bus 
working. Anything which has to do with flash (transferring a new file e.g.) 
is of lower priority, so your last proposition of the advanced AMD V2 driver 
sounds like a good solution, especially with using suspend/resume 
functionality. (Does one have to purchase it from eCosCentric?)

Thank you very much again!
Kind Regards,
Iris

-- 
Iris Lindner
Software Development

Industrial Print and Apply Labelling

www.Logopak.com

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