This is the mail archive of the ecos-discuss@sourceware.org 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]
Other format: [Raw text]

eCos causing something.. Maybe?


Hi,
	let me appologise first for asking a really open ended question,
but I've already wasted about 2 weeks on this/these problem(s), and I'm
running out of things to take a closer look at. 

I'm trying to run a trivial program based on eCos, on a custom board
with a SAM7S256 on it. I'm programming it with a BDI2000. I can get this
setup working with code from Atmel, and blink an LED. This program works
perfectly every time. I have another trivial program that uses eCos.
This one never makes it into main. It seems no matter how I configure
eCos, it will not run on this board. Just to make sure I did the
configuration correctly, I frequently go back to the AT91SAM7SE512-EK
board, load the exact same program that won't run on my custom board,
and it runs perfectly every time. I would guess that it's a problem on
the board, except that the Atmel provided code runs flawlessly every
time.

I've gotten to the point where I debug the eCos app from the very first
instruction. Using "br *0x100040" in gdb. Sometimes it will stop here
for me. Many times however, it will stop a few instructions later, or
stop when it has a failure, at 0x00000000 or 0xfffffxxx or somewhere
else.

The times it does stop at the right location, I can step through one
instruction at a time for a while. Eventually, execution jumps
somewhere, and everything is fubar. I often get an error at this time:
"Remote failure response: E01" which can be caused by junk gdb packets
according to BDI support. The crash doesn't always happen at the same
time, and doesn't always happen on a jump or branch type of instruction.
I've had it crash while stepping over an instruction that worked fine in
a previous session. This is all done repeatedly on the same program,
without recompiles in between.

I'm having a lot of trouble with this because I can't produce a
repeatable failure on the custom board, and I can't verify that I'm
doing it wrong, since it works on the Atmel board. I've tried many
different eCos configurations, many of which were ones that were working
previously, with no success. The only change made to the board between
the working and not-working state was that we grounded the ground pin on
the RS232 voltage converter. It was floating before. I've even gone so
far as to replace the chip itself, but the new one has the exact same
problem.

If anyone can think of anything else I could
try/program/read/probe/time/configure please let me know. 

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


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