Lpc2000

Did you enable interrupts in the CPU core too?

With ARM parts the core is considered different to the peripherals and the 
VIC is a peripheral.

You therefore need to emable interrupts in the VIC and the ARM core.

-- CHarles

On Thursday 28 October 2004 04:02, you wrote:
> Hello all,
>
> After trying to figur out what the heck is going on for over a day, I
> decided to throw the question in this group.
>
> Just sending out a string through the UART1 of a LPC2294 is not
> working. Hope someone can give me the obvious solution to our
> problems.
>
> The following components are used :
> - Phytec demoboard with philips LPC2294
> - Debug with amontec chamelion (Mcgraigor clone) on parallel port
> - devlopment on IAR IDE for ARM
>
> Software does the following :
>
> - Initialising VIC :
>    + Set default vector to dummy routine that does nothing, but
> returning
>    + Set VICVectAddr 5 to int service routine for UART1
>    + Set VICVectCtrl 5 to 0x27 (2 to enable int and 7 for UART1)
>    + set UART 1 to IRQ (not FIQ in VIC Int Select register)
>    + Enable the seventh bit of VICIntEnable (results in value
> 0x00000080)
>    + No other interrupts are enabled
>
> - Initialise UART1 :
>    + Set baudrate
>    + set word length
>    + set parity
>    + set stop bit
>    + flush fifo s by setting RFR and TFR bits in U1FCR and enable FIFO
>    + set queue length
>    + set pins of UART1 to TX and RX
>
> - Send a string :
>    + Copy string to output buffer (Somewhere in RAM)
>    + Disable all interrupts
>    + IF  transmit interrupt is not enabled (in UART1 register U1IER)
>         THEN  Enable transmit interrupt (transmision was not busy)
>               send first byte to UART1
>         ELSE  Do nothing, transmission is busy, int will handle the
> rest
>    + Enable interrupts again.
>
> What happens, the first byte is send correct and received with
> terminal program. Next I see in the VIC registers the interrupt for
> the UART1 is pending, but the service routine is never called.
> I even saw the int vector apearing in the VICVectAddr register, but
> the int is never serviced! Is there a global interrupt enable bit
> that I'm missing???
>
> I had a breakpoint in the IRQ handling routine, but this was never
> called. Most is copied from a working demo. The only difference is
> that I do not wait for the byte to be transmitted. This is done in
> int.
>
> the VIC init routine is the following :
> ========================================
>
> tpVoid LPC210xInitVIC()
> {
>   // Setup interrupt controller.
>   VICProtection = 0;
>   // Disable all interrupts but the one used for the ROM monitor
>   OSDisableInterrupts();
>   VICDefVectAddr = (unsigned int)&DefaultInterrupt;
>   VICVectAddr = 0x00;
> }
>
> //Dummy interrupt handler, called as default in irqHandler() if no
> other
> //vectored interrupt is called.
> tpVoid DefaultInterrupt()
> {}
>
> the int service routine is the following :
> ==========================================
>
> // IRQ exception handler. Calls the interrupt handlers.
> __irq __arm void irq_handler(void)
> {
>   void (*interrupt_function)();
>   unsigned int vector;
>
>   vector = VICVectAddr;   // Get interrupt vector.
>   interrupt_function = (void(*)())vector;
>   (*interrupt_function)();  // Call vectored interrupt function.
>
>   VICVectAddr = 0;        // Clear interrupt in VIC.
> }
>
>
> The vector in the vector space of the IRQ (on address 0x18) is
> actualy a call of this routine. Checked with memory dump via J-tag.
>
>
> Is there something we are missing.
>
> Sorry to say but the documentation from Philips is not so clear on
> the use of the VIC nor the UART.
>
> Thanks for your time,
>
> Didier
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>