This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

I use W90P710 MCU.
and store start code in Norflash,located at 0x3000000 after remap
while Ram located at 0x0~0x1000000
but I consider this is the menory problem.
because I have debug my application in ICE mode.and it works OK.
I think you mean your application is seperated from interrupt handler while
I need to combine them.
so it cause problem like I have mentioned:
> 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.

thank you anyway.I am annoyed by that redboot could not work stably,so the
problem
can't be observed clearly!



Paul D. DeRocco wrote:
> 
>> 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.
> 
> 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
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/how-to-debug-application%28not-based-on-ecos%29-that-trig-interrupt-with-redboot%21-tp15630621p15661346.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]