[ECOS] Redboot-GDB

[Nick Garnett]

"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


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