2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

As soon as I write a single character to the THRE, Transmit holding register empty flag in U1LSR is cleared. Either the FIFO is not enabled or is set to '1', or this is the normal operation (after all, the FIFO is not **empty**). In the latter case how do you know if there is still space in the FIFO to write data? BTW, while trying to resove this problem I came accross the following comment in the control register descriptions: 00: trigger level 0 (default='h1) 01: trigger level 1 (default='h4) 10: trigger level 2 (default='h8) 11: trigger level 3 (default='he) These two bits determine how many receiver UART1 FIFO characters must be written before an interrupt is activated. The four trigger levels are defined by the user at compilation allowing the user to tune the trigger levels to the FIFO depths chosen. 0 What exactly does it mean by defined at compile time? Perhaps if I knew where these levels were configured I would find the answer to my Tx FIFO problem ?!

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

hodgejackiehank wrote: > As soon as I write a single character to the THRE, Transmit holding > register empty flag in U1LSR is cleared. Either the FIFO is not > enabled or is set to '1', or this is the normal operation (after all, > the FIFO is not **empty**). > > In the latter case how do you know if there is still space in the FIFO > to write data? > > BTW, while trying to resove this problem I came accross the following > comment in the control register descriptions: > > 00: trigger level 0 (default='h1) > 01: trigger level 1 (default='h4) > 10: trigger level 2 (default='h8) > 11: trigger level 3 (default='he) > These two bits determine how many receiver UART1 FIFO characters must > be written > before an interrupt is activated. The four trigger levels are defined > by the user at > compilation allowing the user to tune the trigger levels to the FIFO > depths chosen. > 0 > > What exactly does it mean by defined at compile time? Perhaps if I > knew where these levels were configured I would find the answer to my > Tx FIFO problem ?! I also stumbled across this description. Obviously, this is a copy-and-paste from the description of the '550-UART IP-Core. So, 'compile time' means the time of the building of the chip, when all the hardware descriptions (in VHDL, Verilog or whatever) are translated and mapped onto the target technology and 'user' in this case is/are the chip designer(s). IIRC, somewhere in the user manual is explicitely said that the FIFO holds 16 byte with possible trigger levels being 1, 4, 8 or 14. Regards, Jens

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> I also stumbled across this description. Obviously, this is a copy-and-paste > from the description of the '550-UART IP-Core. I thought it might be something like that. So given that the FIFO is preconfigured, how do I know when the FIFO is full?

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

At 10:28 AM 7/6/04 +0000, you wrote: > > I also stumbled across this description. Obviously, this is a >copy-and-paste > > from the description of the '550-UART IP-Core. > >I thought it might be something like that. So given that the FIFO is >preconfigured, how do I know when the FIFO is full? In this respect, it behaves as all '550s. When the THRE interrupt fires the FIFO is empty and you can put up to 16 bytes into it. Something like case RECEIVE: for( i = 0; i <16; i++) { U0THR = buf[i]; } break; Oversimplified but it illustrates the point. AFAIR this is documented in all of a sentence or maybe two. BTW, I would be very interested if anyone else has run into the missing THRE interrupt symptoms I've seen. 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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> > In this respect, it behaves as all '550s. When the THRE interrupt fires > the FIFO is empty and you can put up to 16 bytes into it. Something like I would like to be able to "top up" the FIFO when possible so that I can have more time before the next interupt. Trouble is I am not sure if I am intepreting the flags correctly, the THRE flag appears to be set even if just 1 byte has been written, so it is no use for seeing if the FIFO may be topped up.

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

At 12:00 PM 7/6/04 +0000, you wrote: > > > > In this respect, it behaves as all '550s. When the THRE interrupt >fires > > the FIFO is empty and you can put up to 16 bytes into it. Something >like > > > >I would like to be able to "top up" the FIFO when possible so that I >can have more time before the next interupt. Trouble is I am not sure >if I am intepreting the flags correctly, the THRE flag appears to be >set even if just 1 byte has been written, so it is no use for seeing >if the FIFO may be topped up. There is no way to know when the transmit FIFO has been partially emptied (well you could time how long it was since it was last filled). The THRE flag does just that it flags when the transmitter holding register is empty. That means that there was nothing in the FIFO to re-fill it. I can see that a transmitter FIFO would be a useful additional source to increase the allowable interrupt response latency but there is nothing in the uart to give it to you. 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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

At 08:10 AM 7/6/04 -0400, you wrote: >I can see that a transmitter FIFO would be a useful additional source to >increase the allowable interrupt response latency but there is nothing in >the uart to give it to you. Oops, that should be I can see that a transmitter FIFO threshold interrupt would be .... 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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hello all, I am puzzled by perhaps similar thing re: missing THRE int., FIFO empty? Can anyone plese help me to see what I do incorrectly? Polled UART0 works, INT on THRE doesn't. Timer0 ISR works, though. The code (snippets below)never makes it to UART_THRE ISR. I am re-writing INT driven buffered Tx already implemented on another MCUs. BTW, I am a newbie on LPC2106, no flames please. --roger ---ivt.s---- LDR PC, [PC, #-0xFF0] @ load irq vector from vic LDR PC, FIQ_Addr -----main.c--- VICIntSelect = 0x0; /* ALL sources selected as IRQ */ VICIntEnable = 0x50; /* TIMER0 and UART0_THRE interrupts enabled */ /* Address of the ISR */ VICVectAddr0 = (unsigned long)IRQ_Timer0_Handler; VICVectCntl0 = 0x24; /* IRQ for channel 4: TIMER0 : 10 0100 */ VICVectAddr1 = (unsigned long)IRQ_UART0_Tx_Handler; VICVectCntl1 = 0x26; /* IRQ for channel 6: UART_THRE: 10 0110 */ . . . PINSEL0 = 0x05; // enable UART0 TxD/RxD UART0_FCR = 0x07; // enable and reset Tx and Rx FIFO UART0_LCR = 0x83; // 8N1; enable divisor latches access UART0_DLL = 0x20; // LSB divider for cclk/115200*16=0x20 UART0_DLM = 0x00; // MSB = 0 UART0_IER = 0x02; // enable THRE interrupt UART0_LCR = 0x03; // disable divisor latches void __attribute__((interrupt)) IRQ_UART0_Tx_Handler(void) { IOCLR =0x00000080; <----- LED, active low never turns ON ... etc. } --- In , Robert Adsett <subscriptions@a...> wrote: > At 10:28 AM 7/6/04 +0000, you wrote: > > > > I also stumbled across this description. Obviously, this is a > >copy-and-paste > > > from the description of the '550-UART IP-Core. > > > >I thought it might be something like that. So given that the FIFO is > >preconfigured, how do I know when the FIFO is full? > > In this respect, it behaves as all '550s. When the THRE interrupt fires > the FIFO is empty and you can put up to 16 bytes into it. Something like > > case RECEIVE: > for( i = 0; i <16; i++) { > U0THR = buf[i]; > } > break; > > Oversimplified but it illustrates the point. > > AFAIR this is documented in all of a sentence or maybe two. > > BTW, I would be very interested if anyone else has run into the missing > THRE interrupt symptoms I've seen. > > 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

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

At 01:46 PM 7/28/04 +0000, you wrote: >Hello all, > >I am puzzled by perhaps similar thing re: missing THRE int., FIFO empty? >Can anyone plese help me to see what I do incorrectly? > >Polled UART0 works, INT on THRE doesn't. >Timer0 ISR works, though. Just a quick question, are you are sending are byte directly by writing it to the THR before you expect to get a THRE interrupt (the transmission does need to be primed)? 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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

void tx(char c) { UART0_THR = c; } ..and then I expect INT (after the 8th bit is out). --- In , Robert Adsett <subscriptions@a...> wrote: > At 01:46 PM 7/28/04 +0000, you wrote: > Just a quick question, are you are sending are byte directly by writing it > to the THR before you expect to get a THRE interrupt (the transmission does > need to be primed)? > > 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

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I'm going to take a deeper look at this in a bit (when I get a break) but initially it looks OK. In the meantime, however, a couple of questions/suggestions. - Is anything happening at the receive side (Is the transmit looped back, is the receive getting info from somewhere) or is it transmit only? - How about putting in a check in the main body (IE non-interrupt) or the timer to check the THRE flag and set an LED if it is set? That way you should be able to tell if the flag has gone up but the interrupt has disappeared. Maybe you've found a way to harden what I've seen. At 02:40 PM 7/28/04 +0000, you wrote: >void tx(char c) >{ > UART0_THR = c; >} > >..and then I expect INT (after the 8th bit is out). I figured it was probably something like that. Just wanted to be sure of the obvious :) 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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

OK, I've been through it again. I didn't see anything obvious. Would I be correct in assuming you get one character out and then nothing? Robert At 02:40 PM 7/28/04 +0000, you wrote: >void tx(char c) >{ > UART0_THR = c; >} > >..and then I expect INT (after the 8th bit is out). " '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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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? 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. 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 Happy SW trails! --roger --- In , Robert Adsett <subscriptions@a...> wrote: > I'm going to take a deeper look at this in a bit (when I get a break) but > initially it looks OK. In the meantime, however, a couple of > questions/suggestions. > > - Is anything happening at the receive side (Is the transmit looped back, > is the receive getting info from somewhere) or is it transmit only? > - How about putting in a check in the main body (IE non-interrupt) or the > timer to check the THRE flag and set an LED if it is set? That way you > should be able to tell if the flag has gone up but the interrupt has > disappeared. Maybe you've found a way to harden what I've seen. > > At 02:40 PM 7/28/04 +0000, you wrote: > >void tx(char c) > >{ > > UART0_THR = c; > >} > > > >..and then I expect INT (after the 8th bit is out). > > I figured it was probably something like that. Just wanted to be sure of > the obvious :) > > 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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- roger_lynx <> wrote: > ...... > > 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 > > Happy SW trails! > > --roger > LDR PC, [PC, #-0xFF0] instruction is loacted at 0x00000018, which means the PC would have advanced to 0x00000020 this value offset -0x0FF0 would address the location at 0xFFFF F030, which is the address of VIC Vector Address Register. (Given in the User Manual) You should have your IRQHandler for UART0-THRE Address loaded into the VICVADDRx (x between 0 to 15) and correspondingly the VICCNTLx (corresponding to the VICVADDR - x) should be set to 0x26 (bit 5 = 1 indicates this Vectored IRQ slot is enabled, bit 4:0 has the value of 0b00110 indicates UART0 is enabled for this slot). This is explained in Philips AN10254. The instruction at 0x18 can handle all the interrupts that are enabled in VIC, by automatically jumping to the IRQ handler of the specific interrupt that took place. Hope this clarification (is correct!) and it helps you. Cia Mathew __________________________________

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

You might want to check my contribution to the files section on Yahoo. The descriptively titled 'UT040322A.zip', contains an interrupt or polled (your choice) UART driver, non-interrupt system timer, and a blinky lights program. It may be of help to you. Regards -Bill Knight the ARM Patch

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hello all, I'd like to thank all who suggested their solution(s) to my post. My error was that I was "enabling" THRE interrupt in U0IER reg. while DLAB was set. The said interrupt can be turned ON when DLAB=0 *ONLY*. <Duh>. Now all my three ints (TIMER0, TIMER1, UART_THRE)run okay. Thanks again. --roger --- In , Robert Adsett <subscriptions@a...> wrote: > >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). > 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.

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )