This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FLASH API v.2 and interrupts


Iris Lindner wrote:

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

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.

I did have issues with locking the flash device
on the thread level, but I am on hardware that
is not really well thought out and shares a slow bus
for things with contradicting requirements.

> Do you need more information about our system/configuration (I'm not sure 
> about what details are useful to know)? 

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?

  Normally you disable the interrupts for shifting data
  to the chip, then leave it enabled and only check
  when the flash operation ends - periodically
  or interrupt-driven, again with interrupts disabled
  while the check operation itself.

- 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)?

  If the worst-case margin is too narrow, slow the CAN bus speed.

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

- Stack sizes. If processing of the CAN interrupt takes
  non-trivial amount of stack, this can have various
  effects.


Regards
-- 
                                     Stano

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]