Re: [ECOS] Serial Console

[Bart Veer <bartv at redhat dot com>]

>>>>> "Anthony" == Anthony Massa <amassa@cts.com> writes:

    Anthony> I have tried this method. I connected hyperterminal and
    Anthony> tried to get output from the program. I load the program
    Anthony> into RAM using EPPC-bug firmware and then enter the GO
    Anthony> command to get it to execute the downloaded ecos code.
    Anthony> The first line in my cyg_user_start is a printf. I tried
    Anthony> changing this to diag_printf and even using cyg_io_write
    Anthony> using the /dev/ser1 (SMC1 port). However, I still cannot
    Anthony> get output from the target MBX board.

    Anthony> Do you have an .ecc configuration that you were able to
    Anthony> get running without GDB on a target MBX board?

    Anthony> Do you know what else I should enable/disable in the ecos
    Anthony> configuration that I might be overlooking?

So you believe you are downloading a valid executable and nothing
happens. There are many things which could be going wrong here before
eCos can even get started. Note that I have not used the MBX board
myself and have no experience with EPPC, but I can give some general
hints. 

1) are you sure that the code you are loading is actually in the right
   format for EPPC? If you are trying to load an ELF executable, does
   EPPC contain a full ELF loader capable of doing the relocations
   etc? If EPPC expects a raw binary, S-records, or anything like
   that, then the ELF executables will need to be converted using
   objcopy and the appropriate options (see the documentation for more
   details).

   Other things to worry about are the start address which EPPC should
   jump to, and whether or not static data gets properly initialized.
   Look at the eCos startup code to see what it will do for you and
   what it expects to have happened already. If the wrong start
   address is used then obviously eCos will not start up correctly and
   you will never see any output.

   Try to simplify the problem as much as possible, for example
   generate an absolutely minimal executable which just lights up an
   LED or something along those lines. This need not involve eCos at
   all. Make sure you can download and run that.

   Have a look at the gdb sources related to EPPC and see what they
   do. Perhaps use a serial analyzer to see what actually happens when
   gdb successfully loads and runs a program, and how this differs
   from what you are attempting to do with hyperterminal and EPPC.


   Once you are certain that you can correctly build, load and run
   executables without using gdb then you can progress.

2) when EPPC transfers control to eCos, what state is the system in?
   Does gdb do anything special before telling EPPC to actually jump
   to the downloaded application? For example, if you are doing the
   download at 9600 baud and eCos immediately switches to 38400 baud
   then obviously you are going to run into problems.

   Again, try to write and run a minimal program which attempts to
   access the serial port directly, and see if you can get any data
   out that way. Look at the eCos serial driver sources and the
   hardware documentation for details on how to do this. If this
   works, gradually scale up the minimal program so that it does much
   the same as the eCos startup code and find out where things start
   behaving differently.

3) Is there a second serial port you can use, so that gdb uses one
   port normally and your application uses the other?

4) look at the actual implementations of the various eCos routines,
   including diag_printf() and cyg_io_write(). What configuration
   options affect them? What has to be working first in terms of
   interrupt handling etc. before you can start using them? eCos is
   open source, so you can look at the source code and figure out what
   is going on.

If you feel you need a technical support contract, please contact
ecos-info@redhat.com for details. Questions on ecos-discuss may or may
not get answered, either by the main eCos developers or by other
users, and may not get answered quickly or at all. The same is true
for mailing lists on other open source projects.

Bart Veer // eCos net maintainer