Re: ISR / DSR debugging
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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 maxThis 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