Lpc2000

At 10:08 AM 7/29/04 +0000, you wrote:
>Robert, thanks for your ideas.
>Alas... "Houston..we have a problem". :-)
>I have found out that I can service only INT of TIMER0, and not TIMER1
>and UART0_THRE. It appears, the problem might be somewhere else
>(ivt.s -> linking?).
>In the polled Tx_ing there is no problem, I got 115200 out okay.
>FIFO is okay, but I want to buffer it w/128 bytes and INT.
>Is it foolish?

Should be quite doable.  The FIFO just lowers the number of interrupts you 
need to respond to.

>Page 89 looks (Oct 02, '03 specs) great, I have not study it until
>today on a train.
>I think FIFO/U0THR needs to be "primed", as you have hinted y'day.

As do most UART transmit interrupts (at least the ones I've dealt with).


>Summary:
>my_debug_ability = 0;
>JTAG_access=0;
>ddd_or_insight=0;
>GNUARM+=cygwin;
>Olimex = 0x01;
>
>Does this snippet look okay (for IRQ ints)?
>
>           NOP
>           LDR PC, [PC, #-0xFF0] <---- what happens here?
>           LDR PC, FIQ_Addr
>
>Undefined_Addr: .word Undefined_Handler
>SWI_Addr:       .word SWI_Handler
>Prefetch_Addr:  .word Prefetch_Handler
>Abort_Addr:     .word Abort_Handler
>FIQ_Addr:       .word FIQ_Handler

The ldr PC, {pc, #-0FF0] is just an indirect jump using the vector provided 
by the VIC.

Given that only one interrupt is responding I'm wondering about your 
interrupt acknowledgement.  Do you have an interrupt acknowledge sequence 
at the end of the interrupt response routines to inform the VIC that you 
have finished with the interrupt?

         ldr     r0, =VICVectAddrRead    /*  Let VIC know we are done.   */
         str     r0,[r0]

Without something like the above the VIC will never know you are done with 
the interrupt.

Robert

" '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