Remote Debugging of RCX using GDB over IR

      (Tested over LegOS a.k.a. BrickOS)

CSC 714 RTCS Project Website

Start Date:                     10/29/02
End Date:                      12/02/02

Group Members:        

        Jaydeep Marathe                    jpmarath[at]unity.ncsu.edu
        Palash Kasodhan                    pmkasodh[at]unity.ncsu.edu

        Gautam Gopinadhan              gvgopina[at]unity.ncsu.edu
 

Status:

        Complete.

        Basic debugging is supported (no threads support).

Relevant Docs:
        Preliminary Project Proposal

        Final Project Report

Work Progress
 

Sr.

Task Description

Assigned to

Status

I.

Validation of Previous Work Done

 

 

   a. 

Setting up Linux and downloading required LegOS packages on Home Machine etc.

Common

Done

   b. 

Testing Communication between machine and RCX.This involved the setup of lnpd server on the host machine and running sample programs to make sure communication occurred both ways.

The initial setup caused “Collision” messages such that neither the host nor the RCX were able to get any messages whatsoever.

On searching the web we found some documentation that said that we needed to invoke the following command to set the baud rate of the serial device used for communication.

setserial /dev/ttyS0 uart 16450

In spite of this the RCX got messages with incorrect length.

The problem appeared to be mismatch in packetization logic. LNP protocol had undergone changes after the debugger was written. We studied the LNP protocol changes. Also we tried the experiment with a different version of LegOS operating system (Version of LegOS was not documented on the website reporting previous work.) LegOS 2.4 seemed to work.

Common 

Done

   c.

Testing if all operations that were previously mentioned continue to work.

There were a lot of problems that we faced as regards to the libraries to be used. Specifically there was a lot of version dependency between the egcs, binutils and gdb. We had to try out various sources till we finally got it right.

We have now been able to run and test the claims of the previous developer. However we have realized that the setup phase to start the debugging procedure is lengthy and involved. We are thinking of simplifying the procedure.

 Common

Done

II.

Setup changes and background study

 

 

   a.

Porting the GDB python server on the host machine to C code

This task was started but was later aborted since we realized that the pylnp library seems to be well written and works quite well. Changing this seems unnecessary at this point.

Update: We had some problems with the version of Python that was installed on our system and so we finally did go ahead and implement this in C.

Gautam

Done

   b.

Study of the current source code and instruction set for H8/300 processor.

This is an ongoing process...

Common

Done

   c.

Study of the remote GDB protocol and a study of the GDBServer.

Here are some links that we found and studied.

GDB online book
http://www.delorie.com/gnu/docs/gdb/gdb_toc.html

Redhat articles on using GDB remote protocol
http://www.redhat.com/devnet/articles/embedrem.htm

http://prdownloads.sourceforge.net/gdbstubs/
an attempt for writing portable stub framework, might be useful.

http://www.csa.iisc.ernet.in/Department_Resources/Hypertext/gdb/gdb_3.html#SE
C7
some info on stubs.

 

Common

Done

III.

Development

 

 

   a.

Due to the absence of a trap instruction the breakpoints are being supported writing a software jsr instruction. Implementation of the basic breakpoint code.

Jaydeep

Done

   b.

Implement step and next instructions.

There might be some source code from gdbstubs website on sourceforge that seems to be useful. We might have to move some of the parsing and breakpoint code within the stub framework.

Gautam + Palash

Done

Appendix

TODO/Wish List

 

 

 

  1. Convert the current version of the debugging utility so that it works with the new LNP protocol.
  2. Add thread support.
  3. Freeze the RCX environment during a debug.