[ECOS] ISR / DSR debugging

[ECOS] ISR / DSR debugging

[gmail]

I am trying to get an ISR+DSR working with no avail.

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.

When my interrupt occurs (via a pushbutton) I can see the vector # being 
returned in the hal_IRQ_handler() but I don't see the ISR or DSR 
diag_printf() getting called.
Also at this point the application locks up (I really don't know where 
it is as I don't have any debugging at this point).

It looks like the ISR / DSR that I've created and attached isn't getting 
called.

Any suggestions on how I should try and debug this?

Thanks!

Here are some code pieces for the ISR & DSR and initialization.

static cyg_interrupt int1;
static cyg_handle_t int1_handle;

cyg_uint32 gpio_isr(cyg_vector_t vector, cyg_addrword_t data) {
     diag_printf("gpio_isr()\n");


     cyg_interrupt_mask(vector);
     cyg_interrupt_acknowledge(vector);

     return (CYG_ISR_HANDLED | CYG_ISR_CALL_DSR); // Run the DSR
}
void gpio_dsr(cyg_vector_t vector, cyg_ucount32 count, cyg_addrword_t 
data) {
     diag_printf("gpio_dsr()\n");
     intr_count++;

     // !!! just clear PortB:0 for now
     *GPIOBEOI = 0x1;

     // !!! clear the bit(s)
     //cyg_interrupt_unmask(vector);
}
void cyg_user_start(void) {

     gpioInit();

     cyg_vector_t int1_vector = CYGNUM_HAL_INTERRUPT_GPIO;
     cyg_priority_t int1_priority = 0;
     cyg_interrupt_create(int1_vector,
                          int1_priority,
                          (cyg_addrword_t) 0,
                          (cyg_ISR_t *) gpio_isr,
                          (cyg_DSR_t *) gpio_dsr,
&int1_handle,
&int1);

     cyg_interrupt_attach(int1_handle);
     cyg_interrupt_unmask(int1_vector);

     cyg_thread_create(4, gpio_thread, (cyg_addrword_t) 0, "gpio_thread",
             (void *) stack[0], STACKSIZE, &thread[0], &thread_obj[0]);
     cyg_thread_resume(thread[0]);
}




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

Re: [ECOS] ISR / DSR debugging

[Stanislav Meduna]

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
-- 
                                       Stano

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

Re: [ECOS] ISR / DSR debugging

[gmail]

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