At 08:07 AM 2/23/04 +1100, you wrote:
>I must assume that Bill Knight's original speculation that direct writes to
>eg. UxIER still
>*can* cause "spurious interrupts" is correct.
>There must be a mechanism where the write instruction is still be in
>execution unit while a
>vectored INT request decodes in the VIC.
That triggers a thought. There is a writeback cache on the LPC. It's only
a single entry and I thought it was only for the SRAM but maybe it's more
universal than I remember. There was a note in the User manual saying that
if a write to ram (?) absolutely had to be there a second write was
required. It also appeared to be the case that a write followed by a read
to the same location would work though since it would read out of the
cache. In fact I thought reading through it that the only place this could
be an issue is if you wanted the written value to get through a
reset. It's a bit of a stretch but it might be worth checking the user manual.
>In any case, I presume that the best prottection is to have it in a separate
>function....?
>I found that calling a function that explicitly Disables IRQ Global,
>sets/clears THRE,
>then re-Enables IRQ Global, then returns makes all the permuations of
>previous code now
>behave as I expected it to, regardless of the method of doing the TX buffer
>write and update
>of the pointer, and regardless of how I set the optimisation.
>
>This to me implies that the instruction sequences indeed are being changed.
>I've been stepping around in ASM, but it is _very_ time consuming, it
>started to annoy me :-)
gcc -S -Os is very enlightening. Definitely not a simple mapping.
>I do intend to fully get to the bottom of this, as I want to know what on
>earth was causing these
>bizarre behaviours, it seems that it's compiler reordering, I will revisit
>this later.
>I'm writing 2 functions set_int() and clr_int() that take a register and a
>bit number, and then
>Enable/Disable individual INTs.
>
>Does that seem like a plausible scenario ????
Sounds good. I'd expand those functions a bit and have them return the
previous interrupt state so you could do something like;
pre_int = DisableINT( INT_BLAH);
blah blah;
RestoreINT( pre_int);
That allows things like nested disable/enables to work.
>Best regards,
>Kris
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
" 'Freedom' has no meaning of itself. There are always restrictions,
be they legal, genetic, or physical. If you don't believe me, try to
chew a radio signal. "
Kelvin Throop, IIIMessage
Re: [lpc2000] UART TX FIFO and INTs problem - SOLVED
2004-02-22 by Robert Adsett
Attachments
- No local attachments were found for this message.