This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: FLASH API v.2 and interrupts
- From: Iris Lindner <ilindner at logopak dot de>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Fri, 23 Oct 2009 13:55:48 +0200
- Subject: [ECOS] Re: FLASH API v.2 and interrupts
Hi Bart,
here comes a small summary for we could finally solve our problem concerning
FLASH crashes and interrupt serving (for everyone who might come over similar
problems). Thank you very much again for your kind help!!
We stayed at V1 FLASH API but now we leave interrupts always enabled (just
commented out the approp. lines on API level). As consequence CAN interrupts
can always be served in time and the bus stays alive.
To prevent competing FLASH access we use a semaphore on next higher level. So
every routine which uses FLASH API _must_ obtain semaphore first or wait for
it if taken. Interrupts must not be disabled on higher level in relation to
FLASH operations.
These steps taken lead to positive tests without FLASH inconsistency or a
broken CAN bus anymore.
The reason for earlier problems was probably, as you suspected (or as you
warned against), that there were three program part accessing FLASH which was
not synchronized or organized with a mutex (I only knew one part for a long
time).
> Iris> As far as I understood the offsets are always added to the
> Iris> actual block address to be erased (addr). But in the chip
> Iris> documentation (we use a Spansion S29GL256P) it says that
> Iris> offsets have to be added to base address of flash range.
>
> That is strange. The current code works on numerous AMD (now Spansion)
> and compatible chips without problems. The datasheet will typically
> include something like the following, hidden away in a footnote:
>
> "Address bits AMAX:A16 are don't cares for unlock and command
> cycles, unless SA or PA required. (AMAX is the Highest Address
> pin.)."
I couldn't find a hint like that in data sheet for our chip, so this could be
one reason why V2 didn't work. But I must admit that I didn't dig deeper into
it for now... =)
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