This is the mail archive of the ecos-discuss@sources.redhat.com 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]

Re: Questions about GDB Ctrl-C support.


>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

>>  Well, the stub uses the debug channel and hence the driver RedBoot
>> provided for driving that channel. however, the stub code
>> internally uses VV (IIRC) so you should be able to CLAIM_COMMS in
>> the application (i.e., the application provides the drivers used by
>> printf) and still be able to use the GDB support (which will then
>> call into RAM for printing).

Grant> I'm not sure what you mean by "call into RAM".  Do you mean
Grant> that the GDB stubs in RedBoot will use routines in the eCos
Grant> application (via the VV table) to do I/O to/from GDB?  [In my
Grant> case both RedBoot and the eCos application are in RAM.]

Indeed. The VV table allows calling from RAM to ROM or vice
versa. Effectively removing the need for callee and caller to be in
the same (linker) address space.

Grant> That sounds like a pretty good option.  The app will work even
Grant> w/o RedBoot, but the GDB stubs in RedBoot can still be used to
Grant> load and debug programs.  I'll look at doing that.

Correct.

Grant> No, the ISR is always attached. If an interrupt happens and a
Grant> 0x03 is received it assumes RedBoot is there since nobody else
Grant> ever unmasks that interrupt.  It fails if the RedBoot version
Grant> and the eCos application version are incompatible.

OK.

Jesper


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