Re: [ECOS] ARM vectors.S hang issue

[Jonathan Larmour <jlarmour at redhat dot com>]

Bill Diehls wrote:
> 
> Hi All,
> I have been working with a couple of friends porting
> eCos to the Gameboy Advance which uses an ARM7TDMI
> core.  We have ported the hal and we have Redboot up
> and running with console and flash support.  We also
> have the debug stubs working under Redboot.

You probably won't be surprised by this, but I'm sure people would want you
to contribute this back to the main sources so that everyone can have a go
(when it's done). See
http://sources.redhat.com/ecos/faq.html#contrib_assign for the formalities.


> But we
> are experiencing a strange issue in the ISR routine in
> vectors.s.  When running the periodic timer test
> program (intr.c) for 1000 ticks or so, we get a hang
> in the program -- but only if we call diag_printf to
> indicate the number of ticks in the while loop.  If we
> remove diag_printf, the problem goes away completely.
> 
> More interestingly though, if we remove the switch to
> supervisor mode (and the switch back to irq mode) in
> the IRQ routine in vectors.s, the hang problem
> disappears as well, regardless of calling diag_printf.
>  (Note, sprintf instead of diag_printf exhibits the
> same behavior as well as other homemade routines that
> don't use variable args.)   This would probably
> indicate a stack overflow in the supervisor stack, but
> resizing __startup_stack to large values (say 8k) has
> no effect.  Any thoughts on what might be happening
> would be greatly appreciated.

It's not the startup stack size you should change, change the
CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE config option. assuming you are
using a separate interrupt stack (
CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK ).

But if this _is_ an interrupt problem, as seems entirely possible,
diagnostic output in itself should not be enough to cause interrupts
because it's polled. What this may instead mean is that you interrupts are
unmasked for the device doing the diag output. You should ensure those
interrupts are masked in your platform initialization in
cyg_hal_plf_comms_init(). Try adding an explicit mask of those interrupts
in the test.

Also you could try turning off interworking with the ROM monitor (
CYGSEM_HAL_USE_ROM_MONITOR) to be sure that any problems are only in your
app, so if you change config options they definitely take effect.

Also, have you enabled assertion support, and the stack checking options?
If you've enabled assertion support you should get told about a spurious
(i.e. unhandled) interrupt if there is one.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine