Lpc2000

> ==========================================================================
> This problem shows up on the Coldfire list every so often.  It MAY not be
> a problem on the ARM.  The idea is that the interrupt is recognized by the
> hardware and scheduled to execute at the end of the instruction that is
> modifying the register.  When the instruction has completed, the interrupt
> is no longer there.  As I write this I relize it is less likey a problem
> considering the mask being changed is in the UART while the vector being
> processed is in the VIC (in hardware, after the signal coming from the
> UART). The problem on the ColdFire was the mask bit was effectively in
> its "VIC".  So I'm guessing that simply writing the register would also
> fix the problem.
>
> -Bill

Hi Bill et al,

In light of the previous revelations, I tried what I described before.
Does anyone know what is going on here ?

Outputting a character into circular buffer works fine like this :
=======================================
UINT temp;

/* Handle TX buffer wrap */
temp = (tx_head+1)%RS232_SIZE;

/* Disable TX interrupts */
U0IER = 0x01;

/* Circ buffer not empty ? */
if (comm_tx_running)
    {
    comm_tx[tx_head] = (UCHAR)ch;
    tx_head = temp;
    }
else
    {
    comm_tx_running = 1;
    U0THR = ch;
    }

/* Reenable TX interrupts */
U0IER = 0x03;
return (ch);


But doing a write to the TX buffer with post increment also causes Default
IRQs :
====================================================

/* Disable TX interrupts */
U0IER = 0x01;

/* Circ buffer not empty ? */
if (comm_tx_running)
    {
    comm_tx[tx_head++] = (UCHAR)ch;
    tx_head %= RS232_SIZE;
    }
else
    {
    comm_tx_running = 1;
    U0THR = ch;
    }

/* Reenable TX interrupts */
U0IER = 0x03;
return (ch);

-------------------------------------------------------

Could this have to do with optimisation ?
I have to honestly volunteer I'm stumped with that one.

-- Kris