Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: [lpc2000] UART TX FIFO and INTs problem - SOLVED

2004-02-22 by Robert Adsett

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, III

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.