[ECOS] AEB: GDB vs. ROM monitor dilemma

[Marco Götze <marco dot goetze at imms dot de>]

Hi all,

I'm experiencing difficulties in getting a (somewhat more
elaborate) sample application to run on an AEB board.
Actually, I'm rather stuck and clueless as to what else to
try.

The board is revision C and connected to the ix86 Linux
host machine via a serial cable.  The eCos version I'm using
is a 010312 CVS snapshot, but I've tried other versions as
well, including release 1.3.1.  At a minimum, the only
modifications made to the "ecos.ecc" file concern the board's
revision and CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE
(increased to 32768).  Other settings I've played with include
serial console/port/diag ones, but those don't appear to make
any relevant difference either.

Symptoms: When running the target application inside GDB
(Insight), things work as expected.  When communicating with
the on-board ROM monitor (v0.01) via a terminal application
(minicom), however, execution typically immediately branches
through zero (as remarked upon by the monitor, followed by
a reboot).

There isn't anything obvious going wrong downloadwise, and
small sample applications ("hello", "twothreads", and the
like) work just fine.  I'm stressing the attribute "small"
since my experiments suggest that there's some correlation
with the binary's size: linking a rudimentary application
against the bulk of the library my actual efforts are
focused on causes said symptoms to be exhibited; leaving it
out resolves the issue (but somehow fails to contend me).
To make this clear, I needn't even *call* any of its functions
to cause the failure.  Downloaded code size with the library
code included varies from 85 to 115K, and the library will
allocate a few chunks of dynamic memory.  Again, everything
seems fine when run inside, erm, Insight.

BTW, what should perhaps be mentioned is that, since the
library concerned has been ported to eCos and uses C++
templates to some extent, I haven't managed to compile it
with "-fvtable-gc", as this results in assembler errors
(besides a flood of warnings).  Otherwise, used compiler/
linker flags are as follows:

  compiler: -mcpu=arm7di -ffunction-sections -fdata-sections \
            -fno-exceptions -fno-rtti -finit-priority [-g]
  linker: -Wl,--gc-sections -nostartfiles

Things I've tried include tampering with various configuration
options, CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE, per-thread
stack sizes, etc.--to no avail.  So this is why I'd appreciate
any suggestions as to what else to try or where the problem
might be rooted.  If needed, I'll gladly provide more specific
information.


TIA--

  Marco
-- 

-------------------------------------------------
This mail sent through IMP: imp.imms.de