Forums

LPC2106 Problem: Conflict between uart1 and timer1

Started by voltz56 April 18, 2010
For some reason using timer1 causes uart1 not to work.
Everything runs fine in the software debugger but not on the chip.
Once I comment out the init_timer1_irq(), all is fine. Im sure it must
be something obvious that I doing wrong in my timer initialization
function but I dont see it.

here is a snippet of the code
http://pastebin.com/rztBnuzP

Regards,
J

An Engineer's Guide to the LPC2100 Series

--- In l..., "voltz56" wrote:
>
> For some reason using timer1 causes uart1 not to work.
> Everything runs fine in the software debugger but not on the chip.
> Once I comment out the init_timer1_irq(), all is fine. Im sure it must
> be something obvious that I doing wrong in my timer initialization
> function but I dont see it.
>
> here is a snippet of the code
> http://pastebin.com/rztBnuzP Regards,
> J
>

Some startup files contain an interrupt 'wrapper' and I think Keil has this feature in some cases. I know that I am using one with GCC that was posted by one of the group members.

There is a serious problem with the attribute approach to interrupt handlers and, by the nature of the code, it doesn't allow nested interrupts. What good is a priority interrupt scheme if nested interrupts aren't allowed?

So, you need to post your startup code so someone can see if the wrapper is included. If it is, all of your interrupt functions should be standard C functions with NO attributes. Just void MyIntFunc(void)

A 1 uSec interrupt rate is a little impractical. I haven't added it up but I seriously doubt that your interrupt handler can be executed in 1 uSec. I don't think I would want to spend more than 10% of the processor time in a timer interrupt handler. Probably MUCH less.

Richard

--- In l..., "voltz56" wrote:
>
> For some reason using timer1 causes uart1 not to work.
> Everything runs fine in the software debugger but not on the chip.
> Once I comment out the init_timer1_irq(), all is fine. Im sure it must
> be something obvious that I doing wrong in my timer initialization
> function but I dont see it.
>
> here is a snippet of the code
> http://pastebin.com/rztBnuzP Regards,
> J
>

Nevermind if solved the problem by reordering the init_timer1_irq() like so

void init_timer1_irq()
{
PCB_PINSEL0 |= (0x2 << 20); //config P0.10 as Capture 1.0 input
T1_TCR = 0x03; //Reset counter and prescaler
T1_PR = 0; //set prescaler to 0
T1_IR = 0x11; //Reset timer1 interrupt
T1_MCR = 0x03; //interrupt and reset on MR0
T1_MR0 = 0x030; //match 1usec formula --> toHex(1usec/(1/pclk))
T1_CCR = 0x05; //capture on rising edge, interrupt on capture
T1_CR1 = (1 << 4); //Reset interrupt for capture 1.0
VICVectCntl1 = 0x00000025; //use it for Timer 1 Interrupt
VICVectAddr1 = (unsigned)timer1_irq_handler; //set interrupt vector 1
VICIntEnable |= 0x00000020; //enable TIMER1 interrupT
T1_TCR = 0x01; //enable Timer1

}/* end init_timer0_irq() */

I find it strange though that it works fine in the keil debugger the other way, not the first time though Ive noticed this kind of behaviour!

--- In l..., "rtstofer" wrote:
>
> --- In l..., "voltz56" vltzzzzzzz@ wrote:
> >
> > For some reason using timer1 causes uart1 not to work.
> > Everything runs fine in the software debugger but not on the chip.
> > Once I comment out the init_timer1_irq(), all is fine. Im sure it
must
> > be something obvious that I doing wrong in my timer initialization
> > function but I dont see it.
> >
> > here is a snippet of the code
> > http://pastebin.com/rztBnuzP
> >
> > Regards,
> > J
> > Some startup files contain an interrupt 'wrapper' and I think Keil has
this feature in some cases. I know that I am using one with GCC that
was posted by one of the group members.
>
> There is a serious problem with the attribute approach to interrupt
handlers and, by the nature of the code, it doesn't allow nested
interrupts. What good is a priority interrupt scheme if nested
interrupts aren't allowed?
>
> So, you need to post your startup code so someone can see if the
wrapper is included. If it is, all of your interrupt functions should
be standard C functions with NO attributes. Just void MyIntFunc(void)

Im using the codesourcery gnu tool chain in keil, so I dont think keil
startup files apply.

http://pastebin.com/NPXSWwH1

I really need to learn how they work. They seem to be the source of alot
of my problems. I think I need to change something in mine for malloc to
work, but I cant seem to find any of examples of what.

> A 1 uSec interrupt rate is a little impractical. I haven't added it
up but I seriously doubt that your interrupt handler can be executed in
1 uSec. I don't think I would want to spend more than 10% of the
processor time in a timer interrupt handler. Probably MUCH less.
>

Yes your right a 1 usec rate is far from ideal. I havent got around to
tweaking yet. I really probably only need a 1 second rate.

Regards,
J
--- In l..., "rtstofer" wrote:
>
> --- In l..., "voltz56" wrote:
>
> >
> > Im using the codesourcery gnu tool chain in keil, so I dont think keil
> > startup files apply.
> >
> > http://pastebin.com/NPXSWwH1 No wrapper included which means you do need to use the attributes and nested interrupts won't work.
>
> >
> > I really need to learn how they work. They seem to be the source of alot
> > of my problems. I think I need to change something in mine for malloc to
> > work, but I cant seem to find any of examples of what.
>
> You don't want to use malloc() anyway. Get out of the library stuff and use your own code or a printf() that doesn't require the heap. Search for rprintf().

I guess use of malloc is dangerous on memory constrained systems.

> If you want to stay with malloc(), you need to implement sbrk(), You can find a demo of this in www.jcwren.com/arm Look at syscalls.c in the newlib folder.
>
> For most embedded programming, you can create library functions from the code in "The C Programming Language" and "Software Tools". Using newlib, in its' entirety, is a problem.
>

I wanted to use malloc for a getstring function, I ended up using a global string array, not most elegant or efficent solution, just a quick workaround, -its only to get short commands from a terminal emulator.

Thanks again,
J

--- In l..., "voltz56" wrote:

>
> Im using the codesourcery gnu tool chain in keil, so I dont think keil
> startup files apply.
>
> http://pastebin.com/NPXSWwH1

No wrapper included which means you do need to use the attributes and nested interrupts won't work.

>
> I really need to learn how they work. They seem to be the source of alot
> of my problems. I think I need to change something in mine for malloc to
> work, but I cant seem to find any of examples of what.

You don't want to use malloc() anyway. Get out of the library stuff and use your own code or a printf() that doesn't require the heap. Search for rprintf().

If you want to stay with malloc(), you need to implement sbrk(), You can find a demo of this in www.jcwren.com/arm Look at syscalls.c in the newlib folder.

For most embedded programming, you can create library functions from the code in "The C Programming Language" and "Software Tools". Using newlib, in its' entirety, is a problem.
>
> > A 1 uSec interrupt rate is a little impractical. I haven't added it
> up but I seriously doubt that your interrupt handler can be executed in
> 1 uSec. I don't think I would want to spend more than 10% of the
> processor time in a timer interrupt handler. Probably MUCH less.
> > Yes your right a 1 usec rate is far from ideal. I havent got around to
> tweaking yet. I really probably only need a 1 second rate.
I doubt that you ever get out of the interrupt routine. Well, you do return but not for long! At, say, 20 nS per instruction, you only have 50 instructions including the preamble and postamble before you run out of time.

Richard