This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: [ECOS] Redboot-GDB
- From: Nick Garnett <nickg at ecoscentric dot com>
- To: "Michael Anburaj" <embeddedeng at hotmail dot com>
- Cc: ecos-discuss at sources dot redhat dot com, ecos-devel at sources dot redhat dot com
- Date: 20 Jun 2003 14:13:45 +0100
- Subject: Re: [ECOS] Redboot-GDB
- References: <Law15-F103vSCVRqid7000502a7@hotmail.com>
"Michael Anburaj" <embeddedeng@hotmail.com> writes:
> >It seems strange that it is sending a "C" command rather than a "c"
> >command. This is a continue with signal, in this case SIGBUS. Maybe
> >this is the cause of your problems. Are you sure that RedBoot has
> >actually reached its initial breakpoint and has not actually hit some
> >other error? What do you get from RedBoot if you just type a $ to the
> >RedBoot> prompt?
>
> I will do some more work tomorrow & let you know. But, I was able to
> connect to the ARM9 Target & load the image without any issue. Which I
> guess indicates that the breakpoint (or Undefined instruction)
> exception is working fine. Am I right?
Possibly. Or it may mean that RedBoot has hit a fault, fallen into the
GDB stubs and you are then loading and running your program from a
different state to the one expected. That's why taking a look at the
result of typing a $ is useful, it will tell us whether RedBoot is
working correctly.
>
> Only after I issue the continue command on the gdb console (on the PC
> host) the gdb on the host becomes mum. Which sends Hc0 & C0a
> after. Even if there were exceptions occurring on the target, in which
> case I would imagine the target communicating this 1st to the host
> (Signaling its condition). I am right? <I am not a GDB expert, so
> excuse me if I am wrong :), just a guess >
>
That's correct in theory. There's lots that could go wrong, or just be
overlooked, if a bus error is mistaken for a breakpoint, for example.
>
> One thing I really want to know is:
> 1. From the host I am able to connect to the target (ARM9 with
> Redboot_ROMRAM) & load the ecos image. Does this imply that the GDB
> serial protocol / breakpoint (or Undefined instruction) exception
> mechanism is working fine?
Certainly the protocol is working fine. The breakpoints should work
too, but we may be getting different fault occuring instead.
>
> 2. If that?s true, then is the packet, $C0a#d4 sent from the host the
> root of this problem? If so, what could driver the host to send
> this?
I suspect that this is a symptom. RedBoot is hitting something other
than a breakpoint.
>
> Also let me know what is the last redboot_ROMRAM instruction executed
> before the 1st ecos_RAM instruction at vector.S (in my case
> 0x40000). I mean the very 1st time ecos is made to run after it?s
> loaded. Does this (last redboot_ROMRAM) code live in
> return_from_exception: of vector.S?
>
It is exactly that code. It will be one of the ldmfd instructions
there, depending on the options and system state. Probably the
ldmeqfd sp,{r0-r14,pc}^
at line 655 (in my copy of the source anyway).
--
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts