is this the default vector you mention? I had this but it didnt seem to make any difference so I removed it. I sent it to the UART ISR which would clear all the serial flags and return from interrupt.

VICDefVectAddr=(unsigned)uart0_irq;

Matt

--- In l..., manton@... wrote:
>
> 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
> >> >
> >>
> >
> >
> >
> >
> >
> >
> > Start a New Thread

buckeyes1997 wrote:
> 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.

These all *may* be explained by a bad setup of exception stacks. What is
the Reset_Handler like?

> startup.o(.text+0x2c): In function `PAbt_Addr':
> : undefined reference to `PAbt_Function'

Maybe you have a typo in the name of the function in main.c.

--

Timo

Start a New Thread

PROBLEM SOLVED:

I used the default stack startup.s that came with my board and it was the problem. With my routines the depth of the stacks were not enough and it caused the pc to point somewhere bad thus the PAbt_Handler. Following changes fixed the issue.

/*
// Stack Configuration
// Top of Stack Address <0x0-0xFFFFFFFF>
// Stack Sizes (in Bytes)
// Undefined Mode <0x0-0xFFFFFFFF>
// Supervisor Mode <0x0-0xFFFFFFFF>
// Abort Mode <0x0-0xFFFFFFFF>
// Fast Interrupt Mode <0x0-0xFFFFFFFF>
// Interrupt Mode <0x0-0xFFFFFFFF>
// User/System Mode <0x0-0xFFFFFFFF>
//
//
*/

.equ Top_Stack, 0x40004000
.equ UND_Stack_Size, 0x00000004
.equ SVC_Stack_Size, 0x00000004
.equ ABT_Stack_Size, 0x00000040 <--changed from 0x00000004
.equ FIQ_Stack_Size, 0x00000004
.equ IRQ_Stack_Size, 0x00000100 <--changed from 0x00000040
.equ USR_Stack_Size, 0x00000400

-----------------------------

Anyone know how to actually calculate these rather than trial and error?

Thanks everyone for your help and motivation.

Matt

--- In l..., Timo wrote:
>
> buckeyes1997 wrote:
> > 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.
>
> These all *may* be explained by a bad setup of exception stacks. What is
> the Reset_Handler like?
>
> > startup.o(.text+0x2c): In function `PAbt_Addr':
> > : undefined reference to `PAbt_Function'
>
> Maybe you have a typo in the name of the function in main.c.
>
> --
>
> Timo
>

Start a New Thread