Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

Interrupt problem with UART0

Interrupt problem with UART0

2005-08-31 by xjag74

Hi,

I currently try my interrupt controlled UART0 communication (only TX 
for the beginning) to get startet. The problem I have is that the 
interrupts work really sporadicly after an reset or an breakpoint for 
one or two seconds or not. When I halt the LPC2210 by an breakpoint
and rerun the communication (TX), the ARM shows the same behaviour as
after an reset.
I compile using GCC.
Has anyone an idea for that behaviour?
My debugger brings me not further on that point.

Thanks
regards
Detlef

Re: Interrupt problem with UART0

2005-08-31 by xjag74

Hello,

it seems to be a problem with long called functions and/or global 
variables.
I use long calls between functions that run in internal RAM at
address 
0x40000000 and functions in external Flash at 0x80000000. Now I pay 
with the time waste of some extra probs realizing long calls for the 
performance advantage that the internal memory brings.

regards
Detlef

--- In lpc2000@yahoogroups.com, "xjag74" <detlef.weidner@w...> wrote:
> Hi,
> 
> I currently try my interrupt controlled UART0 communication (only
TX 
> for the beginning) to get startet. The problem I have is that the 
> interrupts work really sporadicly after an reset or an breakpoint
for 
> one or two seconds or not. When I halt the LPC2210 by an breakpoint
> and rerun the communication (TX), the ARM shows the same behaviour
as
Show quoted textHide quoted text
> after an reset.
> I compile using GCC.
> Has anyone an idea for that behaviour?
> My debugger brings me not further on that point.
> 
> Thanks
> regards
> Detlef

Re: [lpc2000] Re: Interrupt problem with UART0

2005-08-31 by Karsten Weiss

Hi Detlef,
propably, this might be a problem with sporadic interrupts mentioned in 
the LPC22xx user's manual. Have you set up the default interrupt 
handler?  If not, just define an empty interrupt routine and assign it 
to the default interrupt address. This will catch every sporadic 
interrupt and your system keeps running.

Karsten

xjag74 schrieb:
Show quoted textHide quoted text
>Hello,
>
>it seems to be a problem with long called functions and/or global 
>variables.
>I use long calls between functions that run in internal RAM at
>address 
>0x40000000 and functions in external Flash at 0x80000000. Now I pay 
>with the time waste of some extra probs realizing long calls for the 
>performance advantage that the internal memory brings.
>
>regards
>Detlef
>
>--- In lpc2000@yahoogroups.com, "xjag74" <detlef.weidner@w...> wrote:
>  
>
>>Hi,
>>
>>I currently try my interrupt controlled UART0 communication (only
>>    
>>
>TX 
>  
>
>>for the beginning) to get startet. The problem I have is that the 
>>interrupts work really sporadicly after an reset or an breakpoint
>>    
>>
>for 
>  
>
>>one or two seconds or not. When I halt the LPC2210 by an breakpoint
>>and rerun the communication (TX), the ARM shows the same behaviour
>>    
>>
>as
>  
>
>>after an reset.
>>I compile using GCC.
>>Has anyone an idea for that behaviour?
>>My debugger brings me not further on that point.
>>
>>Thanks
>>regards
>>Detlef
>>    
>>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>

Re: Interrupt problem with UART0

2005-08-31 by xjag74

Hi Karsten,

yes I have a default handler, that is not the cause.
In the meanwhile I learned that it isn't really an interrupt problem.
I have a function which is called by a timer-ISR. That function 
starts the UART transmission by writing the first byte to the THR. 
The UART-ISR should then do the rest. The problem is that the 
function called by the timer-ISR isn't really always called. When I 
put an additional function call (something different for debug 
issues) then the function will be called savely every time.
The problem is not the timer-ISR (I observed this with an osci and a 
toggled debug-pin). I think there is a coherence with the long calls 
I use or with globals or with the optimization levels or all these 
things together. I guess I have to observe some more things tomorrow. 
The debugger isn't very helpful cause I experienced that it affects 
the behaviour of that things...

Thats all I have now
regards
Detlef


--- In lpc2000@yahoogroups.com, Karsten Weiss <lpc2000@w...> wrote:
> Hi Detlef,
> propably, this might be a problem with sporadic interrupts 
mentioned in 
> the LPC22xx user's manual. Have you set up the default interrupt 
> handler?  If not, just define an empty interrupt routine and assign 
it 
> to the default interrupt address. This will catch every sporadic 
> interrupt and your system keeps running.
> 
> Karsten
> 
> xjag74 schrieb:
> 
> >Hello,
> >
> >it seems to be a problem with long called functions and/or global 
> >variables.
> >I use long calls between functions that run in internal RAM at
> >address 
> >0x40000000 and functions in external Flash at 0x80000000. Now I 
pay 
> >with the time waste of some extra probs realizing long calls for 
the 
> >performance advantage that the internal memory brings.
> >
> >regards
> >Detlef
> >
> >--- In lpc2000@yahoogroups.com, "xjag74" <detlef.weidner@w...> 
wrote:
> >  
> >
> >>Hi,
> >>
> >>I currently try my interrupt controlled UART0 communication (only
> >>    
> >>
> >TX 
> >  
> >
> >>for the beginning) to get startet. The problem I have is that the 
> >>interrupts work really sporadicly after an reset or an breakpoint
> >>    
> >>
> >for 
> >  
> >
> >>one or two seconds or not. When I halt the LPC2210 by an 
breakpoint
Show quoted textHide quoted text
> >>and rerun the communication (TX), the ARM shows the same behaviour
> >>    
> >>
> >as
> >  
> >
> >>after an reset.
> >>I compile using GCC.
> >>Has anyone an idea for that behaviour?
> >>My debugger brings me not further on that point.
> >>
> >>Thanks
> >>regards
> >>Detlef
> >>    
> >>
> >
> >
> >
> >
> >
> > 
> >Yahoo! Groups Links
> >
> >
> >
> > 
> >
> >
> >
> >
> >
> >  
> >

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.