Lpc2000

Hi Bill,

Thanks for the prompt response.
This has actually been my main problem.
It's not my "style" when I develop to just change my SW, and go
"oh, yeah, well it works like that but not like that, so what".
If I write code a particular way, then I expect it to work a particular way,
and if it doesn't - I want to know why !

Anywho, I'm glad I persisted with this.
I had indeed noticed that I didn't have this weird problems either when I
used
Gloabl enable/disable on IRQ. Bah,what a pain.

I'll use your workaround, it sounds plausible.
I can't believe that this problem didn't show up when just printing away
with printf(), but ONLY when running the BASIC interpreter, and with a
specific
program running !

Do you think I should maintain a Default_IRQ handler (I don't plan to use
non-vectored
INTs), case this happens again ?

I'm naturally concerned that if I write to ViCVectAddr at end of Default_IRQ
handler,
that I'll miss actual INTs, as opposed to spurious INTs.

Your summary must be dead-on, because I found that different optimisations
would
exhibit the problem or not.

Thanks a lot !
Kris



Bill wrote :

> Kris
>   Thanks for spotting this.  It's the old spurious interrupt problem.
> The fix is to disable global interrupts around the first read-modify-write
> instruction.  Doing the direct write (U0IER = xxx) can still allow the
problem
> to happen.  What happens is the interrupt occurs and is recognized while
> the masking instruction is executing but before it has completed.  Then
> when the instruction does complete, the interrupt can't find the vector
> so uses the default.  So to fix:
>
> Disable global interrupts
> mask interrupt
> Enable global interrupts
>
> do your stuff
> unmask interrupt
>
> NOTE: I don't think this last modification of the mask register needs
> protection.  Someone correct me if I am wrong.
>
>
> Regards
> -Bill Knight
> R O SoftWare
>
>
>
> On Mon, 23 Feb 2004 02:09:38 +1100, microbit wrote:
>
> Hi all,
>
> This s a hairy one - ARM Gurus, please read this !!!
> (Bill, this will cause a problem in your UART package too, since you
> set VicDefVectAddr to the Reset Vector, and you also use a RMW
> operation on UxIER)
>
> I figured out why I was getting "resets" while UART0 is TXing
> interrupt driven.
> The problem only occurs when I disable the THE interrupt by masking :
>
> U0IER &= ~ 0x02;    /* Disable THE */
> ......
> U0IER |= 0x02;
>
> When I disable and then re-enable THE interrupts with a direct write :
>
> U0IER = 0x01;        /* Disable THE, leave RDA enabled */
> .....
> U0IER = 0x03;        /* Reenable THE */
>
> I didn't get these "resets".
>
> This is the problem :
> -----------------------
>
> I didn't have VicDefVectAddr specified, so it was set to its default
0x00000000
> address. (All IRQs are disabled, except for VIC Channel # 6)
> While U0IER &= ~ 0x02 is executing, there MUST be a few cycles where the
THE
> is disabled, BUT the interrupt asserts at the right moment, hence causing
a non-vectored
> assertion.... (which of course vectors to 0x000000, and ultimately results
in a RESET)
> Is this a known problem on the VIC ?
> Is this normal on the VIC ?
>
> I put in a "dummy" function default_IRQ_handler() so I can break on it,
and when it hits
> that function, VicRawIntr reads 0x3008.
> If I merely indicate on a LED when that function is hit, but then return
from interrupt, the
> execution happpily picks up after the U0IER &=~0x02; statement, and things
run as good as gold.
> NO TX interrupts were missed by the looks of it, since the non-vectored
dummy function doesn't
> service or alter anything, the pending interrupt must be serviced when THE
is re-emabled.
>
> Are there any ARM gurus here that can shed some light on this ?
> I've been just about driven to tears over this problem.
> I can't just use a direct write (I have an interrupt on the other UART in
RX, and that operates on
> a CRC function, the RF transmit function needs to operate on the same CRC
function, so I need
> masking of the Interrupt Enables, rather than directly setting/clearing
all INT sources on UxIER)
>
> As far as I'm concerned this classifies as a silicon BUG, since UxIER bits
cannot assert themselves,
> and it is indeed a R/W register.
>
> BTW : How do I work out with VicRawIntr (0x3008 in my case) which Slot/Int
is asserted ?
> I can't find a bitmap on it.
>
> Best regards,
> Kris
>
>
>
>
>
>       Yahoo! Groups Sponsor
>             ADVERTISEMENT
>
>
>
>
>
> --------------------------------------------------------------------------
------
> Yahoo! Groups Links
>
>   a.. To visit your group on the web, go to:
>   http://groups.yahoo.com/group/lpc2000/
>
>   b.. To unsubscribe from this group, send an email to:
>   lpc2000-unsubscribe@yahoogroups.com
>
>   c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>