buckeyes1997 wrote:
> I have made everything volatile now!!! same
problem.
Did you also try taking away the ADDR check from the timer irq handler
and leave the START bits zero?
Do you use MAM. It was reported in the past that there were hardware
bugs which caused intermittent problems in some controllers.
I would devote one LED for each function. One led would be turned on at
the start of timer irq and off at the end. Another led would be devoted
to main loop and yet another to uart irq. That way you would see (at
least with a scope) exactly which one was stuck.
There have been errors in header files so I would check register
definitions against UM.
After those, I'm afraid I'm running out of ideas...
--
Timo
Strange Problem with Interrupts on LPC2119
Started by ●December 14, 2009
Reply by ●December 15, 20092009-12-15
Reply by ●December 15, 20092009-12-15
buckeyes1997 wrote:
> I added some debugging to the other vectors and it never gets to any of
> them. At least it never prints the string to the serial port. It turns
> my two LEDS on and it just sits there.
Have you set up stacks for those vectors? If not, it would simply crash
without any output.
> It has to be getting to one of those conditions because if I setup the
> vectors in the startup.s to all be Reset_Handler then it never has the
> problem but randomly resets the board instead of locking up. It then
> continues running fine until the next hiccup.
Then you could try one at a time and work out exactly which one it is.
--
Timo
> I added some debugging to the other vectors and it never gets to any of
> them. At least it never prints the string to the serial port. It turns
> my two LEDS on and it just sits there.
Have you set up stacks for those vectors? If not, it would simply crash
without any output.
> It has to be getting to one of those conditions because if I setup the
> vectors in the startup.s to all be Reset_Handler then it never has the
> problem but randomly resets the board instead of locking up. It then
> continues running fine until the next hiccup.
Then you could try one at a time and work out exactly which one it is.
--
Timo
Reply by ●December 15, 20092009-12-15
Tim
Thanks a lot for your responses thus far. I appreciate all the help from this group. I thought my vectors would jump to the c routines I specified in the post above. All the vectors have a branch to a c function which basically sends the ID over serial and then clears the interrupt.....or so I thought. It never gets into any of them for some reason.
I think my UART0 interrupt is not handling all the error conditions properly. I check for character ready interrupt and then if the interrupt doesnt have a character ready I assume error happened and try to clear all errors and return from interrupt. ???
Matt
--- In l..., Timo wrote:
>
> buckeyes1997 wrote:
> > I added some debugging to the other vectors and it never gets to any of
> > them. At least it never prints the string to the serial port. It turns
> > my two LEDS on and it just sits there.
>
> Have you set up stacks for those vectors? If not, it would simply crash
> without any output.
>
> > It has to be getting to one of those conditions because if I setup the
> > vectors in the startup.s to all be Reset_Handler then it never has the
> > problem but randomly resets the board instead of locking up. It then
> > continues running fine until the next hiccup.
>
> Then you could try one at a time and work out exactly which one it is.
>
> --
>
> Timo
>
Thanks a lot for your responses thus far. I appreciate all the help from this group. I thought my vectors would jump to the c routines I specified in the post above. All the vectors have a branch to a c function which basically sends the ID over serial and then clears the interrupt.....or so I thought. It never gets into any of them for some reason.
I think my UART0 interrupt is not handling all the error conditions properly. I check for character ready interrupt and then if the interrupt doesnt have a character ready I assume error happened and try to clear all errors and return from interrupt. ???
Matt
--- In l..., Timo wrote:
>
> buckeyes1997 wrote:
> > I added some debugging to the other vectors and it never gets to any of
> > them. At least it never prints the string to the serial port. It turns
> > my two LEDS on and it just sits there.
>
> Have you set up stacks for those vectors? If not, it would simply crash
> without any output.
>
> > It has to be getting to one of those conditions because if I setup the
> > vectors in the startup.s to all be Reset_Handler then it never has the
> > problem but randomly resets the board instead of locking up. It then
> > continues running fine until the next hiccup.
>
> Then you could try one at a time and work out exactly which one it is.
>
> --
>
> Timo
>
Reply by ●December 15, 20092009-12-15
I will try commenting out the line "while ((val & 0x80000000) == 0);"
I am not sure what the START bit is as this code was taken from an example that "just worked". I will look at the UM and try to figure out the START bit and BURST mode tomorrow.
I believe I have the MAM setup per the examples that came with my ET-ARM board.
I have LEDs that turns on when it goes into the timer interrupt and a second LED that turns on when it enters the UART0 interrupt and all LEDS are cleared in the main loop. They twinkle when it works well but when it fails both lights actually go on and stay on....strange. Thats why I thought perhaps it was in the UART0 interrupt and then gets a timer0 interrupt and it screws up leaving both lights lit as it never returns to main???
--- In l..., Timo wrote:
>
> buckeyes1997 wrote:
> > I have made everything volatile now!!! same problem.
>
> Did you also try taking away the ADDR check from the timer irq handler
> and leave the START bits zero?
>
> Do you use MAM. It was reported in the past that there were hardware
> bugs which caused intermittent problems in some controllers.
>
> I would devote one LED for each function. One led would be turned on at
> the start of timer irq and off at the end. Another led would be devoted
> to main loop and yet another to uart irq. That way you would see (at
> least with a scope) exactly which one was stuck.
>
> There have been errors in header files so I would check register
> definitions against UM.
>
> After those, I'm afraid I'm running out of ideas...
>
> --
>
> Timo
>
I am not sure what the START bit is as this code was taken from an example that "just worked". I will look at the UM and try to figure out the START bit and BURST mode tomorrow.
I believe I have the MAM setup per the examples that came with my ET-ARM board.
I have LEDs that turns on when it goes into the timer interrupt and a second LED that turns on when it enters the UART0 interrupt and all LEDS are cleared in the main loop. They twinkle when it works well but when it fails both lights actually go on and stay on....strange. Thats why I thought perhaps it was in the UART0 interrupt and then gets a timer0 interrupt and it screws up leaving both lights lit as it never returns to main???
--- In l..., Timo wrote:
>
> buckeyes1997 wrote:
> > I have made everything volatile now!!! same problem.
>
> Did you also try taking away the ADDR check from the timer irq handler
> and leave the START bits zero?
>
> Do you use MAM. It was reported in the past that there were hardware
> bugs which caused intermittent problems in some controllers.
>
> I would devote one LED for each function. One led would be turned on at
> the start of timer irq and off at the end. Another led would be devoted
> to main loop and yet another to uart irq. That way you would see (at
> least with a scope) exactly which one was stuck.
>
> There have been errors in header files so I would check register
> definitions against UM.
>
> After those, I'm afraid I'm running out of ideas...
>
> --
>
> Timo
>
Reply by ●December 16, 20092009-12-16
I had topic here about nested interrupts(LPC2478). You need to add interrupt
handler to startup code. Also all ISR should be defined without any attribute
and without VicVectAddr=0;. If you use secondary bootloader then it is bit
complicated but I got it working.
Reply by ●December 16, 20092009-12-16
m...@ymail.com wrote:
> I had topic here about nested interrupts(LPC2478). You need to add
> interrupt handler to startup code. Also all ISR should be defined
> without any attribute and without VicVectAddr=0;. If you use secondary
> bootloader then it is bit complicated but I got it working.
Why do you think he is using nested interrupts or that he should use nesting? I
think it is better to get normal interrupts working and only after that think
about whether nesting is necessary.
--
Timo
> I had topic here about nested interrupts(LPC2478). You need to add
> interrupt handler to startup code. Also all ISR should be defined
> without any attribute and without VicVectAddr=0;. If you use secondary
> bootloader then it is bit complicated but I got it working.
Why do you think he is using nested interrupts or that he should use nesting? I
think it is better to get normal interrupts working and only after that think
about whether nesting is necessary.
--
Timo
Reply by ●December 16, 20092009-12-16
For debugging(Maybe avoid future problems).
One interrupt freeze. Others work.
For fast interrupt FIQ.
One interrupt freeze. Others work.
For fast interrupt FIQ.
Reply by ●December 17, 20092009-12-17
I tried commenting out the entire ADC read section and let it pass values of
0.00 for the analog and it still locked up.
--- In l..., "buckeyes1997" wrote:
>
> I will try commenting out the line "while ((val & 0x80000000) == 0);"
> I am not sure what the START bit is as this code was taken from an example that "just worked". I will look at the UM and try to figure out the START bit and BURST mode tomorrow.
>
> I believe I have the MAM setup per the examples that came with my ET-ARM board.
>
> I have LEDs that turns on when it goes into the timer interrupt and a second LED that turns on when it enters the UART0 interrupt and all LEDS are cleared in the main loop. They twinkle when it works well but when it fails both lights actually go on and stay on....strange. Thats why I thought perhaps it was in the UART0 interrupt and then gets a timer0 interrupt and it screws up leaving both lights lit as it never returns to main???
> --- In l..., Timo wrote:
> >
> > buckeyes1997 wrote:
> > > I have made everything volatile now!!! same problem.
> >
> > Did you also try taking away the ADDR check from the timer irq handler
> > and leave the START bits zero?
> >
> > Do you use MAM. It was reported in the past that there were hardware
> > bugs which caused intermittent problems in some controllers.
> >
> > I would devote one LED for each function. One led would be turned on at
> > the start of timer irq and off at the end. Another led would be devoted
> > to main loop and yet another to uart irq. That way you would see (at
> > least with a scope) exactly which one was stuck.
> >
> > There have been errors in header files so I would check register
> > definitions against UM.
> >
> > After those, I'm afraid I'm running out of ideas...
> >
> > --
> >
> > Timo
>
--- In l..., "buckeyes1997" wrote:
>
> I will try commenting out the line "while ((val & 0x80000000) == 0);"
> I am not sure what the START bit is as this code was taken from an example that "just worked". I will look at the UM and try to figure out the START bit and BURST mode tomorrow.
>
> I believe I have the MAM setup per the examples that came with my ET-ARM board.
>
> I have LEDs that turns on when it goes into the timer interrupt and a second LED that turns on when it enters the UART0 interrupt and all LEDS are cleared in the main loop. They twinkle when it works well but when it fails both lights actually go on and stay on....strange. Thats why I thought perhaps it was in the UART0 interrupt and then gets a timer0 interrupt and it screws up leaving both lights lit as it never returns to main???
> --- In l..., Timo wrote:
> >
> > buckeyes1997 wrote:
> > > I have made everything volatile now!!! same problem.
> >
> > Did you also try taking away the ADDR check from the timer irq handler
> > and leave the START bits zero?
> >
> > Do you use MAM. It was reported in the past that there were hardware
> > bugs which caused intermittent problems in some controllers.
> >
> > I would devote one LED for each function. One led would be turned on at
> > the start of timer irq and off at the end. Another led would be devoted
> > to main loop and yet another to uart irq. That way you would see (at
> > least with a scope) exactly which one was stuck.
> >
> > There have been errors in header files so I would check register
> > definitions against UM.
> >
> > After those, I'm afraid I'm running out of ideas...
> >
> > --
> >
> > Timo
>
Reply by ●December 17, 20092009-12-17
After much debugging I seem to be chasing two issues that may or may not be
related. The first issue is that 'as is' it locks up periodically
with the two LED's on. If I change the PAbt_Addr in the startup.s file to
point to the Reset_Handler instead of the PAbt_Handler then the board resets
periodically. I also can get it to work without locking up if I basically
bypass all the UART0 interrupt function and just return from the interrupt.
I still cannot write a C function for the PAbt_Handler defined in the startup.s and have it actually jump there and run the code. I think I must be missing something.
I tried the following to send it to a C function in main.c but the compiler errors out.
------------modified startup.s for PAbt_Handler to C function-------
.text
.arm
.global PAbt_Function <------saw this with FIQ example
.global _startup
.func _startup
_startup:
# Exception Vectors
# Mapped to Address 0.
# Absolute addressing mode must be used.
# Dummy Handlers are implemented as infinite loops which can be modified.
Vectors: LDR PC, Reset_Addr
LDR PC, Undef_Addr
LDR PC, SWI_Addr
LDR PC, PAbt_Addr
LDR PC, DAbt_Addr
NOP /* Reserved Vector */
LDR PC, [PC, #-0xFF0]
LDR PC, FIQ_Addr
Reset_Addr: .word Reset_Handler
Undef_Addr: .word Reset_Handler
SWI_Addr: .word SWI_Handler
PAbt_Addr: .word PAbt_Function <---as done in FIQ example
DAbt_Addr: .word Reset_Handler
.word 0 /* Reserved Address */
IRQ_Addr: .word IRQ_Handler
FIQ_Addr: .word FIQ_Handler
Undef_Handler: B Undef_Handler
SWI_Handler: B SWI_Handler
PAbt_Handler: SUBS PC,LR,#4 /*B PAbt_Handler */
DAbt_Handler: SUBS PC,LR,#8 /* B DAbt_Handler */
IRQ_Handler: B IRQ_Handler
FIQ_Handler: B FIQ_Handler
----------compiler error
Build target 'Target 1'
compiling Syscalls.c...
compiling main.c...
compiling serial0.c...
assembling Startup.s...
linking...
startup.o(.text+0x2c): In function `PAbt_Addr':
: undefined reference to `PAbt_Function'
collect2: ld returned 1 exit status
Target not created
--- In l..., "buckeyes1997" wrote:
>
> Tim
>
> Thanks a lot for your responses thus far. I appreciate all the help from this group. I thought my vectors would jump to the c routines I specified in the post above. All the vectors have a branch to a c function which basically sends the ID over serial and then clears the interrupt.....or so I thought. It never gets into any of them for some reason.
>
> I think my UART0 interrupt is not handling all the error conditions properly. I check for character ready interrupt and then if the interrupt doesnt have a character ready I assume error happened and try to clear all errors and return from interrupt. ???
>
> Matt
> --- In l..., Timo wrote:
> >
> > buckeyes1997 wrote:
> > > I added some debugging to the other vectors and it never gets to any of
> > > them. At least it never prints the string to the serial port. It turns
> > > my two LEDS on and it just sits there.
> >
> > Have you set up stacks for those vectors? If not, it would simply crash
> > without any output.
> >
> > > It has to be getting to one of those conditions because if I setup the
> > > vectors in the startup.s to all be Reset_Handler then it never has the
> > > problem but randomly resets the board instead of locking up. It then
> > > continues running fine until the next hiccup.
> >
> > Then you could try one at a time and work out exactly which one it is.
> >
> > --
> >
> > Timo
>
I still cannot write a C function for the PAbt_Handler defined in the startup.s and have it actually jump there and run the code. I think I must be missing something.
I tried the following to send it to a C function in main.c but the compiler errors out.
------------modified startup.s for PAbt_Handler to C function-------
.text
.arm
.global PAbt_Function <------saw this with FIQ example
.global _startup
.func _startup
_startup:
# Exception Vectors
# Mapped to Address 0.
# Absolute addressing mode must be used.
# Dummy Handlers are implemented as infinite loops which can be modified.
Vectors: LDR PC, Reset_Addr
LDR PC, Undef_Addr
LDR PC, SWI_Addr
LDR PC, PAbt_Addr
LDR PC, DAbt_Addr
NOP /* Reserved Vector */
LDR PC, [PC, #-0xFF0]
LDR PC, FIQ_Addr
Reset_Addr: .word Reset_Handler
Undef_Addr: .word Reset_Handler
SWI_Addr: .word SWI_Handler
PAbt_Addr: .word PAbt_Function <---as done in FIQ example
DAbt_Addr: .word Reset_Handler
.word 0 /* Reserved Address */
IRQ_Addr: .word IRQ_Handler
FIQ_Addr: .word FIQ_Handler
Undef_Handler: B Undef_Handler
SWI_Handler: B SWI_Handler
PAbt_Handler: SUBS PC,LR,#4 /*B PAbt_Handler */
DAbt_Handler: SUBS PC,LR,#8 /* B DAbt_Handler */
IRQ_Handler: B IRQ_Handler
FIQ_Handler: B FIQ_Handler
----------compiler error
Build target 'Target 1'
compiling Syscalls.c...
compiling main.c...
compiling serial0.c...
assembling Startup.s...
linking...
startup.o(.text+0x2c): In function `PAbt_Addr':
: undefined reference to `PAbt_Function'
collect2: ld returned 1 exit status
Target not created
--- In l..., "buckeyes1997" wrote:
>
> Tim
>
> Thanks a lot for your responses thus far. I appreciate all the help from this group. I thought my vectors would jump to the c routines I specified in the post above. All the vectors have a branch to a c function which basically sends the ID over serial and then clears the interrupt.....or so I thought. It never gets into any of them for some reason.
>
> I think my UART0 interrupt is not handling all the error conditions properly. I check for character ready interrupt and then if the interrupt doesnt have a character ready I assume error happened and try to clear all errors and return from interrupt. ???
>
> Matt
> --- In l..., Timo wrote:
> >
> > buckeyes1997 wrote:
> > > I added some debugging to the other vectors and it never gets to any of
> > > them. At least it never prints the string to the serial port. It turns
> > > my two LEDS on and it just sits there.
> >
> > Have you set up stacks for those vectors? If not, it would simply crash
> > without any output.
> >
> > > It has to be getting to one of those conditions because if I setup the
> > > vectors in the startup.s to all be Reset_Handler then it never has the
> > > problem but randomly resets the board instead of locking up. It then
> > > continues running fine until the next hiccup.
> >
> > Then you could try one at a time and work out exactly which one it is.
> >
> > --
> >
> > Timo
>
Reply by ●December 17, 20092009-12-17
Quoting buckeyes1997 :
Do you have a default vector set up? Sometimes the serial interrupts,
depending on how they are handled can cause spurious interrupts to occur,
and the default vector is required to handle these.
Mike
> After much debugging I seem to be chasing two issues that may or may
> not be related. The first issue is that 'as is' it locks up
> periodically with the two LED's on. If I change the PAbt_Addr in
> the startup.s file to point to the Reset_Handler instead of the
> PAbt_Handler then the board resets periodically. I also can get it
> to work without locking up if I basically bypass all the UART0
> interrupt function and just return from the interrupt.
>
> I still cannot write a C function for the PAbt_Handler defined in
> the startup.s and have it actually jump there and run the code. I
> think I must be missing something.
> I tried the following to send it to a C function in main.c but the
> compiler errors out.
>
> ------------modified startup.s for PAbt_Handler to C function-------
> .text
> .arm
> .global PAbt_Function <------saw this with FIQ example
> .global _startup
> .func _startup
> _startup:
> # Exception Vectors
> # Mapped to Address 0.
> # Absolute addressing mode must be used.
> # Dummy Handlers are implemented as infinite loops which can be modified.
>
> Vectors: LDR PC, Reset_Addr
> LDR PC, Undef_Addr
> LDR PC, SWI_Addr
> LDR PC, PAbt_Addr
> LDR PC, DAbt_Addr
> NOP /* Reserved Vector */
> LDR PC, [PC, #-0xFF0]
> LDR PC, FIQ_Addr
>
> Reset_Addr: .word Reset_Handler
> Undef_Addr: .word Reset_Handler
> SWI_Addr: .word SWI_Handler
> PAbt_Addr: .word PAbt_Function <---as done in FIQ example
> DAbt_Addr: .word Reset_Handler
> .word 0 /* Reserved Address */
> IRQ_Addr: .word IRQ_Handler
> FIQ_Addr: .word FIQ_Handler
>
> Undef_Handler: B Undef_Handler
> SWI_Handler: B SWI_Handler
> PAbt_Handler: SUBS PC,LR,#4 /*B PAbt_Handler */
> DAbt_Handler: SUBS PC,LR,#8 /* B DAbt_Handler */
> IRQ_Handler: B IRQ_Handler
> FIQ_Handler: B FIQ_Handler
> ----------compiler error
> Build target 'Target 1'
> compiling Syscalls.c...
> compiling main.c...
> compiling serial0.c...
> assembling Startup.s...
> linking...
> startup.o(.text+0x2c): In function `PAbt_Addr':
> : undefined reference to `PAbt_Function'
> collect2: ld returned 1 exit status
> Target not created
>
> --- In l..., "buckeyes1997" wrote:
>>
>> Tim
>>
>> Thanks a lot for your responses thus far. I appreciate all the
>> help from this group. I thought my vectors would jump to the c
>> routines I specified in the post above. All the vectors have a
>> branch to a c function which basically sends the ID over serial and
>> then clears the interrupt.....or so I thought. It never gets into
>> any of them for some reason.
>>
>> I think my UART0 interrupt is not handling all the error conditions
>> properly. I check for character ready interrupt and then if the
>> interrupt doesnt have a character ready I assume error happened and
>> try to clear all errors and return from interrupt. ???
>>
>> Matt
>> --- In l..., Timo wrote:
>> >
>> > buckeyes1997 wrote:
>> > > I added some debugging to the other vectors and it never gets to any of
>> > > them. At least it never prints the string to the serial port. It turns
>> > > my two LEDS on and it just sits there.
>> >
>> > Have you set up stacks for those vectors? If not, it would simply crash
>> > without any output.
>> >
>> > > It has to be getting to one of those conditions because if I setup the
>> > > vectors in the startup.s to all be Reset_Handler then it never has the
>> > > problem but randomly resets the board instead of locking up. It then
>> > > continues running fine until the next hiccup.
>> >
>> > Then you could try one at a time and work out exactly which one it is.
>> >
>> > --
>> >
>> > Timo
>> >
>>
>
Do you have a default vector set up? Sometimes the serial interrupts,
depending on how they are handled can cause spurious interrupts to occur,
and the default vector is required to handle these.
Mike
> After much debugging I seem to be chasing two issues that may or may
> not be related. The first issue is that 'as is' it locks up
> periodically with the two LED's on. If I change the PAbt_Addr in
> the startup.s file to point to the Reset_Handler instead of the
> PAbt_Handler then the board resets periodically. I also can get it
> to work without locking up if I basically bypass all the UART0
> interrupt function and just return from the interrupt.
>
> I still cannot write a C function for the PAbt_Handler defined in
> the startup.s and have it actually jump there and run the code. I
> think I must be missing something.
> I tried the following to send it to a C function in main.c but the
> compiler errors out.
>
> ------------modified startup.s for PAbt_Handler to C function-------
> .text
> .arm
> .global PAbt_Function <------saw this with FIQ example
> .global _startup
> .func _startup
> _startup:
> # Exception Vectors
> # Mapped to Address 0.
> # Absolute addressing mode must be used.
> # Dummy Handlers are implemented as infinite loops which can be modified.
>
> Vectors: LDR PC, Reset_Addr
> LDR PC, Undef_Addr
> LDR PC, SWI_Addr
> LDR PC, PAbt_Addr
> LDR PC, DAbt_Addr
> NOP /* Reserved Vector */
> LDR PC, [PC, #-0xFF0]
> LDR PC, FIQ_Addr
>
> Reset_Addr: .word Reset_Handler
> Undef_Addr: .word Reset_Handler
> SWI_Addr: .word SWI_Handler
> PAbt_Addr: .word PAbt_Function <---as done in FIQ example
> DAbt_Addr: .word Reset_Handler
> .word 0 /* Reserved Address */
> IRQ_Addr: .word IRQ_Handler
> FIQ_Addr: .word FIQ_Handler
>
> Undef_Handler: B Undef_Handler
> SWI_Handler: B SWI_Handler
> PAbt_Handler: SUBS PC,LR,#4 /*B PAbt_Handler */
> DAbt_Handler: SUBS PC,LR,#8 /* B DAbt_Handler */
> IRQ_Handler: B IRQ_Handler
> FIQ_Handler: B FIQ_Handler
> ----------compiler error
> Build target 'Target 1'
> compiling Syscalls.c...
> compiling main.c...
> compiling serial0.c...
> assembling Startup.s...
> linking...
> startup.o(.text+0x2c): In function `PAbt_Addr':
> : undefined reference to `PAbt_Function'
> collect2: ld returned 1 exit status
> Target not created
>
> --- In l..., "buckeyes1997" wrote:
>>
>> Tim
>>
>> Thanks a lot for your responses thus far. I appreciate all the
>> help from this group. I thought my vectors would jump to the c
>> routines I specified in the post above. All the vectors have a
>> branch to a c function which basically sends the ID over serial and
>> then clears the interrupt.....or so I thought. It never gets into
>> any of them for some reason.
>>
>> I think my UART0 interrupt is not handling all the error conditions
>> properly. I check for character ready interrupt and then if the
>> interrupt doesnt have a character ready I assume error happened and
>> try to clear all errors and return from interrupt. ???
>>
>> Matt
>> --- In l..., Timo wrote:
>> >
>> > buckeyes1997 wrote:
>> > > I added some debugging to the other vectors and it never gets to any of
>> > > them. At least it never prints the string to the serial port. It turns
>> > > my two LEDS on and it just sits there.
>> >
>> > Have you set up stacks for those vectors? If not, it would simply crash
>> > without any output.
>> >
>> > > It has to be getting to one of those conditions because if I setup the
>> > > vectors in the startup.s to all be Reset_Handler then it never has the
>> > > problem but randomly resets the board instead of locking up. It then
>> > > continues running fine until the next hiccup.
>> >
>> > Then you could try one at a time and work out exactly which one it is.
>> >
>> > --
>> >
>> > Timo
>> >
>>
>
