Zdravko,

You hit the nail on the head. Reading U1IIR in the main loop was
causing the interrupt not to fire. Thanks a lot.

Sutton
--- In l..., 3gpabko wrote:
> --- Sutton Mehaffey wrote:
>
> > - I have an infinite loop (main) printing out U1IIR
> > which is always
> > 0xc1 as soon as everything is setup. I don't think
> > this is correct
> > (pending interrupt).
>
> U1IIR value 0x31 does not mean that you have pending
> irq. Bit 0 in UxIIR is high if you don't have irq and
> is active low if you have irq.
>
> I think that you make a mistake putting read of U1IIR
> in the main loop. Because reading U1IIR clears the irq
> flags. Perhaps this is confusing the VIC and it can
> not determine the source of irq.
>
> Calling a function from inside the ISR demands that
> you have setup properly the irq stack in the startup
> code.
>
> Don't look for CPSR description in the NXP user
> manual. Instead find "ARM Architecture Reference
> Manual" from ARM.
> Regards
> Zdravko Dimitrov
>
> Знанието е
лично
преживяна
истина.
>
> __________________________________________________ Start a New Thread

--- In l..., "Sutton Mehaffey" wrote:
>
> Anybody know where the decription of the CPSR register (for global
> interrupts) is. I can't seem to find it in the user's manual. I
> think it is being set in startup, because my other interrupts work,
> and there is no mention in any of my code. I apologize if it is plain
> daylight, but I can't find it. :(
>
> Sutton
>
The "Current Program Status Register" (CPSR) is not documented in an
LPC manual because it is part of the ARM processor. It is accessed by
the MRS and MSR assembly language instructions.

***************Quoted from the ARM Architecture Reference Manual*****
The CPSR holds:
4 condition code flags (Negative, Zero, Carry and oVerflow)
2 interrupt disable bits, one for each type of interrupt
5 bits which encode the current processor mode
1 bit which encodes whether ARM or Thumb instructions are being
executed.
*************END Quote from the ARM Architecture Reference Manual***** Start a New Thread

--- Sutton Mehaffey wrote:

> - I have an infinite loop (main) printing out U1IIR
> which is always
> 0xc1 as soon as everything is setup. I don't think
> this is correct
> (pending interrupt).

U1IIR value 0x31 does not mean that you have pending
irq. Bit 0 in UxIIR is high if you don't have irq and
is active low if you have irq.

I think that you make a mistake putting read of U1IIR
in the main loop. Because reading U1IIR clears the irq
flags. Perhaps this is confusing the VIC and it can
not determine the source of irq.

Calling a function from inside the ISR demands that
you have setup properly the irq stack in the startup
code.

Don't look for CPSR description in the NXP user
manual. Instead find "ARM Architecture Reference
Manual" from ARM.
Regards
Zdravko Dimitrov

Знанието е лично преживяна истина.

__________________________________________________ Start a New Thread

OK, thanks. That makes more sense.

--- In l..., "Michael Anton" wrote:
>
> > -----Original Message-----
> > From: l...
> > [mailto:l...]On Behalf
> > Of Sutton Mehaffey
> > Sent: Tuesday, January 09, 2007 3:41 PM
> > To: l...
> > Subject: [lpc2000] Re: UART1 RX LPC2148
> >
> >
> > Anybody know where the decription of the CPSR register (for global
> > interrupts) is. I can't seem to find it in the user's manual. I
> > think it is being set in startup, because my other interrupts work,
> > and there is no mention in any of my code. I apologize if it is plain
> > daylight, but I can't find it. :(
> >
> > Sutton
> >
> > Since the CPSR is an ARM register, not a peripheral register, probably
> it could be found in one of the ARM reference manuals. Though, I
> haven't looked for it.
>
> Mike
> Start a New Thread

> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of Sutton Mehaffey
> Sent: Tuesday, January 09, 2007 3:41 PM
> To: l...
> Subject: [lpc2000] Re: UART1 RX LPC2148
> Anybody know where the decription of the CPSR register (for global
> interrupts) is. I can't seem to find it in the user's manual. I
> think it is being set in startup, because my other interrupts work,
> and there is no mention in any of my code. I apologize if it is plain
> daylight, but I can't find it. :(
>
> Sutton

Since the CPSR is an ARM register, not a peripheral register, probably
it could be found in one of the ARM reference manuals. Though, I
haven't looked for it.

Mike Start a New Thread

Anybody know where the decription of the CPSR register (for global
interrupts) is. I can't seem to find it in the user's manual. I
think it is being set in startup, because my other interrupts work,
and there is no mention in any of my code. I apologize if it is plain
daylight, but I can't find it. :(

Sutton

--- In l..., "Michael Anton" wrote:
>
> > -----Original Message-----
> > From: l...
> > [mailto:l...]On Behalf
> > Of Sutton Mehaffey
> > Sent: Tuesday, January 09, 2007 1:40 PM
> > To: l...
> > Subject: [lpc2000] Re: UART1 RX LPC2148
> >
> >
> > Yes. I have Timer 0 working as an interrupt.
> >
> > I have been trying to look at the LPC2148 UART example in the Files
> > section to see if I could find the source of my problem. I don't see
> > any mention of CSPR in that example. No, I'm not doing anything with
> > that register. I don't see what that has anything to do with this
> > UART1 interrupt, as it is a Code Security register. If it does,
> > educate me please.
> >
> > Sutton
> > CPSR contains the global IRQ enable mask. It may be set by your
> startup code, but interrupts need to be enabled here for them to
> work.
>
> I have had difficulties in calling functions from inside an interrupt
> handler. I'm not exactly sure what my issue is, but I understand that
> there may be a special assembler stub required to get this to work. So,
> you might want to verify that calling functions inside your handler
> works correctly.
>
> As near as I can tell you have everything set appropriatly, so it
> should work as written, but I haven't inspected in detail to make
> sure all of the bits you have set are correct. The comments in
> your code seem to indicate that you are doing things correctly.
>
> Mike
> Start a New Thread

I understand your answer. However, there is another underlying
problem, because I am not getting any interrupts to fire. Under your
scenario, I should be getting TX interrupts continuous. I wish I
were, but I'm not getting any interrupts whatsoever.

I've even typed in line for line the UART0 example from the Files
section and changed UART0 to UART1. Still no interrupts. I can still
TX out using no interrupts.

Sutton

--- In l..., "suvidhk" wrote:
>
> The Thing is that u will be getting an xmit interrupt you wont be
> looking at it and it wont be cleared unless u write data to xmitter
> FIFO.Once your data is transmitted the transmitter int. will be
> generated again and again as u are not handling it. You need to
> disable it in the interrupt if their is no data to write and reenable
> when you have some data to write in FIFO.
> In your case u can continuously disable xmit interrupt and check.
> ~~~~~~~ The transmit int. is cleared when u write data to xmitter fifo
> ~~~~~~
> Suvidh
> --- In l..., "Sutton Mehaffey" wrote:
> >
> > I have UART1 disabled in DUART_Write_Str for this test and then
> reenabled.
> >
> > Can't I have the TX interrupt enabled and just ignore it? Even if it
> > was causing continuous TX interrupts, that's not a problem for this
> > test. Because, I'm not even getting one interrupt. Besides, I'm not
> > tranmitting any data, only receiving for this test.
> >
> > Basically, what I am doing is async typing in chars from a WYSE
> > terminal (trying to receive them over UART1 RX) and 'echo' them out to
> > my display (connected via DUAL UART chip). So, I'm not transmitting
> > anything out over UART1 (yet).
> >
> > Sutton
> >
> >
> >
> >
> > --- In l..., "suvidhk" wrote:
> > >
> > >
> > > The function DUART_Write_Str() is been called from the main loop and
> > > the interrupt. Is the function written to handle the calls from int?
> > >
> > > You may not enable the Transmitter Interrupt as you are not
checking
> > > for it in your IRQ.
> > >
> > > suvidh
> > >
> > > --- In l..., Mike Harrison wrote:
> > > >
> > > > On Tue, 09 Jan 2007 19:30:47 -0000, you wrote:
> > > >
> > > > >I have a problem where my code locks up on receiving a RX
> > interrupt on
> > > > >UART1. I have been transmitting data to a serial display with no
> > > > >problems, although with interrupts disabled. Anybody see any
> > > > >omissions or problems with this? I didn't include code such
as PLL
> > > > >setup, because a lot of other features work. But if anyone
> needs it,
> > > > >I'll post it. Thanks.
> > > > >
> > > >
> > > > Don't know if it applies to the 2148, but I had a problem on a
2103,
> > > where setting the fifo control
> > > > reg to an invalid value (fifo off) caused a continuous RX
interrupt
> > > even with no data.
> > > > Reason was the fifo control register is a write-only register
but I
> > > was using a bitfield-defined
> > > > SFR to set it up, so a subsequent read-modify-write operation
> > > overwrote the intended value.
> > > >
> > > >
> > > > >Sutton - dodge55
> > > > >
> > > > >
> > > > >Notes on code operation:
> > > > >- DUART_Write_xxx - I have moved my display to utilize a Dual
UART
> > > > >chip instead of UART1 (which printed fine without interrupts ON)
> > > > >- I have an infinite loop (main) printing out U1IIR which is
always
> > > > >0xc1 as soon as everything is setup. I don't think this is
correct
> > > > >(pending interrupt).
> > > > >- I have a dumb terminal (WYSE) connected directly to UART1,
> running
> > > > >at 19200. As soon as I press any key on the WYSE, the code stops
> > (and
> > > > >'INT' is never printed.
> > > > >- I have verified that loopback works fine on the WYSE.
> > > > >- If I print something out of UART1 to the WYSE, it works fine
> > > > >(without interrupts).
> > > > >
> > > > >
> > > > >void uart1_read(void) __irq
> > > > >{
> > > > > DUART_Write_Str("INT");
> > > > >
> > > > > if (U1IIR & 0x04 != 0)
> > > > > {
> > > > > DUART_Write_Char(U1RBR);
> > > > > }
> > > > > VICVectAddr = 0; // Acknowledge interrupt
> > > > >}
> > > > >
> > > > >
> > > > >void set_up_uart1(unsigned int baudrate)
> > > > >{
> > > > > PINSEL0 |= 0x00050000; // TX1 and RX1 on P0.8 and P0.9
> > > > > PCONP |= 0x00000010;
> > > > >
> > > > > U1LCR |= 0x80; // enable access to Divisor Latches,
DLAB = 1
> > > > >
> > > > > switch(baudrate)
> > > > > {
> > > > > case 9600:
> > > > > U1FDR = 0x0000009A; // MULVAL = 9, DIVVAL = 10
> > > > > U1DLM = 0; // (12000000 / 9600 / 16) * (9/19) = 37 > > 0x25
> > > > > U1DLL = 0x25; // 9601.71 baud, at 12Mhz
> > > > > break;
> > > > >
> > > > > case 19200:
> > > > > U1FDR = 0x000000A7; // MULVAL = 10, DIVVAL = 7
> > > > > U1DLM = 0; // (12000000 / 19200 / 16) * (10/17) = 23 > > 0x17
> > > > > U1DLL = 0x17; // 19181.585 baud, at 12Mhz
> > > > > break;
> > > > > }
> > > > >
> > > > > U1LCR = 0x03; // 8 bits, 1 stop, no parity, DLAB = 0
> > > > > U1FCR = 0x07;
> > > > >
> > > > > // set up UART1 as a vectored interrupt
> > > > >
> > > > > VICVectAddr1 = (unsigned long) uart1_read;
> > > > > VICVectCntl1 = 0x27; // IRQ 7 plus enable bit
>
> > > > > VICIntEnable |= 0x00000080; // enables the UART1 Interrupt
> > > > >
> > > > > U1IER = 7; // RBR, THRE, RLS interrupt enable
> > > > >}
> > > > >
> > > > >
> > > > >main()
> > > > >{
> > > > > set_up_uart1(19200);
> > > > >
> > > > > for(;;)
> > > > > {
> > > > > char tmp[3];
> > > > >
> > > > > sprintf(tmp,"%x ",U1IIR);
> > > > > DUART_Write_Str(tmp); // other supporting code exists
> > > > > delay(SECS,0.25); // other supporting code exists
> > > > > }
> > > > >}
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >Yahoo! Groups Links
> > > > >
> > > > >
> > > > >
> > > >
> > >
> Start a New Thread

The Thing is that u will be getting an xmit interrupt you wont be
looking at it and it wont be cleared unless u write data to xmitter
FIFO.Once your data is transmitted the transmitter int. will be
generated again and again as u are not handling it. You need to
disable it in the interrupt if their is no data to write and reenable
when you have some data to write in FIFO.
In your case u can continuously disable xmit interrupt and check.
~~~~~~~ The transmit int. is cleared when u write data to xmitter fifo
~~~~~~
Suvidh
--- In l..., "Sutton Mehaffey" wrote:
>
> I have UART1 disabled in DUART_Write_Str for this test and then
reenabled.
>
> Can't I have the TX interrupt enabled and just ignore it? Even if it
> was causing continuous TX interrupts, that's not a problem for this
> test. Because, I'm not even getting one interrupt. Besides, I'm not
> tranmitting any data, only receiving for this test.
>
> Basically, what I am doing is async typing in chars from a WYSE
> terminal (trying to receive them over UART1 RX) and 'echo' them out to
> my display (connected via DUAL UART chip). So, I'm not transmitting
> anything out over UART1 (yet).
>
> Sutton
> --- In l..., "suvidhk" wrote:
> >
> >
> > The function DUART_Write_Str() is been called from the main loop and
> > the interrupt. Is the function written to handle the calls from int?
> >
> > You may not enable the Transmitter Interrupt as you are not checking
> > for it in your IRQ.
> >
> > suvidh
> >
> > --- In l..., Mike Harrison wrote:
> > >
> > > On Tue, 09 Jan 2007 19:30:47 -0000, you wrote:
> > >
> > > >I have a problem where my code locks up on receiving a RX
> interrupt on
> > > >UART1. I have been transmitting data to a serial display with no
> > > >problems, although with interrupts disabled. Anybody see any
> > > >omissions or problems with this? I didn't include code such as PLL
> > > >setup, because a lot of other features work. But if anyone
needs it,
> > > >I'll post it. Thanks.
> > > >
> > >
> > > Don't know if it applies to the 2148, but I had a problem on a 2103,
> > where setting the fifo control
> > > reg to an invalid value (fifo off) caused a continuous RX interrupt
> > even with no data.
> > > Reason was the fifo control register is a write-only register but I
> > was using a bitfield-defined
> > > SFR to set it up, so a subsequent read-modify-write operation
> > overwrote the intended value.
> > >
> > >
> > > >Sutton - dodge55
> > > >
> > > >
> > > >Notes on code operation:
> > > >- DUART_Write_xxx - I have moved my display to utilize a Dual UART
> > > >chip instead of UART1 (which printed fine without interrupts ON)
> > > >- I have an infinite loop (main) printing out U1IIR which is always
> > > >0xc1 as soon as everything is setup. I don't think this is correct
> > > >(pending interrupt).
> > > >- I have a dumb terminal (WYSE) connected directly to UART1,
running
> > > >at 19200. As soon as I press any key on the WYSE, the code stops
> (and
> > > >'INT' is never printed.
> > > >- I have verified that loopback works fine on the WYSE.
> > > >- If I print something out of UART1 to the WYSE, it works fine
> > > >(without interrupts).
> > > >
> > > >
> > > >void uart1_read(void) __irq
> > > >{
> > > > DUART_Write_Str("INT");
> > > >
> > > > if (U1IIR & 0x04 != 0)
> > > > {
> > > > DUART_Write_Char(U1RBR);
> > > > }
> > > > VICVectAddr = 0; // Acknowledge interrupt
> > > >}
> > > >
> > > >
> > > >void set_up_uart1(unsigned int baudrate)
> > > >{
> > > > PINSEL0 |= 0x00050000; // TX1 and RX1 on P0.8 and P0.9
> > > > PCONP |= 0x00000010;
> > > >
> > > > U1LCR |= 0x80; // enable access to Divisor Latches, DLAB = 1
> > > >
> > > > switch(baudrate)
> > > > {
> > > > case 9600:
> > > > U1FDR = 0x0000009A; // MULVAL = 9, DIVVAL = 10
> > > > U1DLM = 0; // (12000000 / 9600 / 16) * (9/19) = 37 > 0x25
> > > > U1DLL = 0x25; // 9601.71 baud, at 12Mhz
> > > > break;
> > > >
> > > > case 19200:
> > > > U1FDR = 0x000000A7; // MULVAL = 10, DIVVAL = 7
> > > > U1DLM = 0; // (12000000 / 19200 / 16) * (10/17) = 23 > 0x17
> > > > U1DLL = 0x17; // 19181.585 baud, at 12Mhz
> > > > break;
> > > > }
> > > >
> > > > U1LCR = 0x03; // 8 bits, 1 stop, no parity, DLAB = 0
> > > > U1FCR = 0x07;
> > > >
> > > > // set up UART1 as a vectored interrupt
> > > >
> > > > VICVectAddr1 = (unsigned long) uart1_read;
> > > > VICVectCntl1 = 0x27; // IRQ 7 plus enable bit

> > > > VICIntEnable |= 0x00000080; // enables the UART1 Interrupt
> > > >
> > > > U1IER = 7; // RBR, THRE, RLS interrupt enable
> > > >}
> > > >
> > > >
> > > >main()
> > > >{
> > > > set_up_uart1(19200);
> > > >
> > > > for(;;)
> > > > {
> > > > char tmp[3];
> > > >
> > > > sprintf(tmp,"%x ",U1IIR);
> > > > DUART_Write_Str(tmp); // other supporting code exists
> > > > delay(SECS,0.25); // other supporting code exists
> > > > }
> > > >}
> > > >
> > > >
> > > >
> > > >
> > > >Yahoo! Groups Links
> > > >
> > > >
> > > >
> > >
> Start a New Thread

> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of Sutton Mehaffey
> Sent: Tuesday, January 09, 2007 1:40 PM
> To: l...
> Subject: [lpc2000] Re: UART1 RX LPC2148
> Yes. I have Timer 0 working as an interrupt.
>
> I have been trying to look at the LPC2148 UART example in the Files
> section to see if I could find the source of my problem. I don't see
> any mention of CSPR in that example. No, I'm not doing anything with
> that register. I don't see what that has anything to do with this
> UART1 interrupt, as it is a Code Security register. If it does,
> educate me please.
>
> Sutton
>

CPSR contains the global IRQ enable mask. It may be set by your
startup code, but interrupts need to be enabled here for them to
work.

I have had difficulties in calling functions from inside an interrupt
handler. I'm not exactly sure what my issue is, but I understand that
there may be a special assembler stub required to get this to work. So,
you might want to verify that calling functions inside your handler
works correctly.

As near as I can tell you have everything set appropriatly, so it
should work as written, but I haven't inspected in detail to make
sure all of the bits you have set are correct. The comments in
your code seem to indicate that you are doing things correctly.

Mike Start a New Thread

I have UART1 disabled in DUART_Write_Str for this test and then reenabled.

Can't I have the TX interrupt enabled and just ignore it? Even if it
was causing continuous TX interrupts, that's not a problem for this
test. Because, I'm not even getting one interrupt. Besides, I'm not
tranmitting any data, only receiving for this test.

Basically, what I am doing is async typing in chars from a WYSE
terminal (trying to receive them over UART1 RX) and 'echo' them out to
my display (connected via DUAL UART chip). So, I'm not transmitting
anything out over UART1 (yet).

Sutton

--- In l..., "suvidhk" wrote:
> The function DUART_Write_Str() is been called from the main loop and
> the interrupt. Is the function written to handle the calls from int?
>
> You may not enable the Transmitter Interrupt as you are not checking
> for it in your IRQ.
>
> suvidh
>
> --- In l..., Mike Harrison wrote:
> >
> > On Tue, 09 Jan 2007 19:30:47 -0000, you wrote:
> >
> > >I have a problem where my code locks up on receiving a RX
interrupt on
> > >UART1. I have been transmitting data to a serial display with no
> > >problems, although with interrupts disabled. Anybody see any
> > >omissions or problems with this? I didn't include code such as PLL
> > >setup, because a lot of other features work. But if anyone needs it,
> > >I'll post it. Thanks.
> > >
> >
> > Don't know if it applies to the 2148, but I had a problem on a 2103,
> where setting the fifo control
> > reg to an invalid value (fifo off) caused a continuous RX interrupt
> even with no data.
> > Reason was the fifo control register is a write-only register but I
> was using a bitfield-defined
> > SFR to set it up, so a subsequent read-modify-write operation
> overwrote the intended value.
> >
> >
> > >Sutton - dodge55
> > >
> > >
> > >Notes on code operation:
> > >- DUART_Write_xxx - I have moved my display to utilize a Dual UART
> > >chip instead of UART1 (which printed fine without interrupts ON)
> > >- I have an infinite loop (main) printing out U1IIR which is always
> > >0xc1 as soon as everything is setup. I don't think this is correct
> > >(pending interrupt).
> > >- I have a dumb terminal (WYSE) connected directly to UART1, running
> > >at 19200. As soon as I press any key on the WYSE, the code stops
(and
> > >'INT' is never printed.
> > >- I have verified that loopback works fine on the WYSE.
> > >- If I print something out of UART1 to the WYSE, it works fine
> > >(without interrupts).
> > >
> > >
> > >void uart1_read(void) __irq
> > >{
> > > DUART_Write_Str("INT");
> > >
> > > if (U1IIR & 0x04 != 0)
> > > {
> > > DUART_Write_Char(U1RBR);
> > > }
> > > VICVectAddr = 0; // Acknowledge interrupt
> > >}
> > >
> > >
> > >void set_up_uart1(unsigned int baudrate)
> > >{
> > > PINSEL0 |= 0x00050000; // TX1 and RX1 on P0.8 and P0.9
> > > PCONP |= 0x00000010;
> > >
> > > U1LCR |= 0x80; // enable access to Divisor Latches, DLAB = 1
> > >
> > > switch(baudrate)
> > > {
> > > case 9600:
> > > U1FDR = 0x0000009A; // MULVAL = 9, DIVVAL = 10
> > > U1DLM = 0; // (12000000 / 9600 / 16) * (9/19) = 37 0x25
> > > U1DLL = 0x25; // 9601.71 baud, at 12Mhz
> > > break;
> > >
> > > case 19200:
> > > U1FDR = 0x000000A7; // MULVAL = 10, DIVVAL = 7
> > > U1DLM = 0; // (12000000 / 19200 / 16) * (10/17) = 23 0x17
> > > U1DLL = 0x17; // 19181.585 baud, at 12Mhz
> > > break;
> > > }
> > >
> > > U1LCR = 0x03; // 8 bits, 1 stop, no parity, DLAB = 0
> > > U1FCR = 0x07;
> > >
> > > // set up UART1 as a vectored interrupt
> > >
> > > VICVectAddr1 = (unsigned long) uart1_read;
> > > VICVectCntl1 = 0x27; // IRQ 7 plus enable bit
> > > VICIntEnable |= 0x00000080; // enables the UART1 Interrupt
> > >
> > > U1IER = 7; // RBR, THRE, RLS interrupt enable
> > >}
> > >
> > >
> > >main()
> > >{
> > > set_up_uart1(19200);
> > >
> > > for(;;)
> > > {
> > > char tmp[3];
> > >
> > > sprintf(tmp,"%x ",U1IIR);
> > > DUART_Write_Str(tmp); // other supporting code exists
> > > delay(SECS,0.25); // other supporting code exists
> > > }
> > >}
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> Start a New Thread