Re: ISR / DSR debugging

[gmail <jjdebarros@xxxxxxxxx>]

On 8/25/2011 1:18 AM, Stanislav Meduna wrote:
> On 25.08.2011 03:07, gmail wrote:
>
> > I have a setup where I am loading my application onto a board that has
> > Redboot, via gdb over the ethernet connection.
> >
> > When the application starts up:
> >
> > I have a diag_printf() in the hal_IRQ_handler() and can see that the
> > clock tick ISR is working fine.
> Uhh, diag_printf in an interrupt handler output via gdb over
> ethernet is a bit heavy - I am quite surprised this works
> at all.
>
> I usually flip some hardware bit for this kind of debugging,
> or you can set some global variables in the debugged code
> path etc.
>
> >      cyg_vector_t int1_vector = CYGNUM_HAL_INTERRUPT_GPIO;
> I don't know your platform, but sometimes the vector
> and interrupt number are not the same. This can be confusing,
> as the thing called 'vector' in eCos is not necessarily
> what a 'vector' in the MCU documentation refers to.
>
> E.g. in my Cortex-M3 based environment INT_GPIOA is defined
> as 16, but it has to be specified as 1 to cyg_interrupt_*
>
> Regards
Thanks!
Your comment on "vector and interrupt number are not always the same" 
got me looking in the right direction.

As it turns out CYGNUM_HAL_ISR_COUNT was less than the GPIO interrupt 
number. This is due to:
- the CYGNUM_HAL_ISR_COUNT is the max - min
- the min starts at 2
-  the GPIO is one less than max

This resulted in the hal_interrupt_handlers[]  not getting initialized / 
set to the default_isr for the last 2 interrupts locations.

It also helped by enabling the asserts (learned something new today), 
the cyg_interrupt_attach() was failing with an assert indicating that 
the "Interrupt vector not free."

More importantly, I need to get to where I can have gdb running with my app.

That will be my next email to this list...

Thanks again!

--JJ--

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss