[ECOS] FLASH and disabling interrupts

["Doyle, Patrick" <WPD at dtccom dot com>]

While tracking down a memory corruption problem, I have gotten to the point
where I see inconsistent state in the bowels of the eCos interrupt handling
code (dsr_list is NULL, but the dsr_count for the clock DSR is non-zero).  I
see this when an interrupt occurs while my code is in the midst of a call to
'flash_dev_query()'.  Looking at flash.h, I see in the comments

// Both implementations must be called with interrupts disabled.

Basically, what I think is happening is that, in the midst of syncing and
invalidating the cache, I get an interrupt, which accesses 'dsr_list' in the
cache right before we shut off the cache.  This must be a recognized issue,
or else Gary wouldn't have put that comment in the code.

So, here are my questions...

Who is responsible for making sure that interrupts are disabled?  Should
'flash_dev_query()' be patched to ensure that interrupts are disabled?
'flash_dev_query()' is called from within my flash driver.  Should my flash
driver disable interrupts before calling 'flash_dev_query()'?  My flash
driver is called by 'flash_init()'.  Should 'flash_init()' disable
interrupts before calling into my driver?  I'm the one who calls
'flash_init()' from my application.  Should I disable interrupts in my
application before calling 'flash_init()'?  I'll stop here :-)

In the short term, I'm going to disable interrupts in my application around
the call to 'flash_init()'.  In the long term, it would be nice if there
were at least a comment somewhere near 'flash_init()' that indicated that
interrupts should be disabled when calling it.

Perhaps a related question would be, do I need to call 'flash_init()'?  I
only call it because I copied code from elsewhere that calls it.  But, all I
want to do is to make some CYGACC_CALL_IF_FLASH_FIS_OP calls to get the base
address and length of some data stored in files in the FIS.  I could try
things once without the call to 'flash_init()', but after the time I've
spent tracking down this particular Heisenbug (in which minor changes to the
code resulted in making the problem disappear and reappear, most likely
related to where things lined up in the cache relative to the timing of the
interrupt while flushing the cache), I am loathe to just make a change, see
that things work, and decide I've fixed this.

--wpd
Patrick Doyle
DSP Design Engineer
(603) 546-2179

 

This communication is from DTC Communications, Inc. and is intended to be
confidential and solely for the use of the persons or entities addressed
above.  If you are not an intended recipient, be aware that the information
contained herein may be protected from unauthorized use by privilege or law,
and any copying, distribution, disclosure, or other use of this information
is prohibited.  If you have received this communication in error, please
contact the sender by return e-mail or telephone the above number
immediately and delete or destroy all copies.  Thank you for your
cooperation.

 


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