RE: [ECOS] how to debug application(not based on ecos) that trig interrupt with redboot!

["Paul D. DeRocco" <pderocco at ix dot netcom dot com>]

> From: Billking
>
> I am trying to use redboot to debug some application.To those
> non_interrupt
> application ,redboot works well!(and the debug channel is
> ethernet) but when
> I use redboot to debug "interrupt" application,it become dumpped and
> unstable.
> my board is MCU core based ARM7TDMI.
> below is what I do to add interrupt support in redboot!
>
> as you kown ,when initialization redboot set up IRQ vector ,but program
> would never reach those place because redboot works in poll mode .
>
> It seems easy,because redboot will not use IRQ vector ,why not just set up
> an interrupt handler in redboot. But IRQ handler in redboot is
> tightly band
> with ecos interrupt handle mode (isr and dsr),so you have to set
> up your own
> interrupt handler and build it with application(non ecos') together.well
> then interrupt handler's address is not static ,so you could not
> build this
> undefined address in redboot.
>
> I think the solution is to set up an fixed address that point your own
> handler in application. then you could add an instrusion that jump to this
> fixed address right after redboot's IRQ handler. this would
> transfer control
> to your application handler.
>
> PS: why interrupt can't jump to application handler?
> because when redboot works as a rom monitor(include gdb stub),it
> occupy the
> memory from address 0~...
> but in arm architecture,when exception occur ,arm core would jump to
> 0x0~0x32(normal this place lay exception table),so interrupt control must
> first be handle in redboot.
>
>   I am examining the problem, but my board is not stable after I add that
> jump instruction .what confused me most is it would reset automaticly time
> after time.

I don't know what hardware you're using, but in the ARM boards I've used,
the interrupt vector at location 0 is in RAM. On startup it's in ROM, but
the memory gets remapped by Redboot to put RAM there. From this point on,
you can write whatever you want into the interrupt vector entries that
correspond to your hardware interrupts.

However, be aware that handling interrupts in an ARM is a bit tricky. You
typically manipulate the status register with MRS and MSR to switch to
System mode for execution of the handler, then manipulate the status
register bits again to switch back to IRQ mode before returning from the
interrupt. (And if you're running your app in Thumb state, the interrupt
forces you into ARM state.) You can study the eCos code as a guide, or just
study the ARM docs very carefully. My guess is that you just have a bug
getting into or out of your interrupt handler. Prepare for some more hair
pulling.

I've done exactly what you're talking about, on an EB40A board, with no
problem. Redboot doesn't use the hardware interrupts, so you can stuff
anything you want into those interrupt vector entries. I invented my own
interrupt handler objects in C++, with a little inline assembler code, and
built my own simple co-operative multi-threading system. I was able to debug
it under GDB with no problems, except of course that GDB had no knowledge of
my threads, since I didn't add any extensions to GDB through the virtual
vector table. But that's another whole can of worms...

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com


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