Hi All,
When I sent out my latest cry for help, I forgot to include a Hyperterminal
screenshot. Here it is:
---------- Hyperterminal screenshot begins here. ------------------------
J-Boot Menu
-----------
1. Execute Flash image
2. Download image to RAM
3. Execute RAM image
4. Erase Flash
5. Write image into Flash
6. Set kernel cmdline
Make your choice>Coooo ssssaaaannnnRRRRtttttttnccccaaaallll:::::::itttt
aa
aaoooo.......8ggggPPPPPPPMrrrrrrrMMMM1
aaaaaaaMrrrr11114444aaaalllleeee1111
eeee9999dddd,,,,KKKKiiiiiiikeeeeUUUUttttaaaa::::!!!!!!!
---------- Hyperterminal screenshot ends here. ------------------------
As you can see, immediately after downloading the bitstream, everything
occurs normally and as expected, indicating that the serial communication
channel is working properly. However, when I download the 'image.bin' file
and jump to it (using XMD), I get a few lines of garbage followed by "dead
air". Of course, if I download the 'image.bin' file using XMD and then
switch over to GDB to execute the image, so that I can perform a
"post-mortem" analysis, then I get the stack trace, which I previously
submitted, ala:
--------- "post-mortem" GDB output begins here. ----------------------
Program received signal SIGTRAP, Trace/breakpoint trap.
0xfe00b824 in machine_halt () at machine.c:234
234 asm ("nop; nop; nop; nop; nop");
(gdb) bt 10
#0 0xfe00b824 in machine_halt () at machine.c:234
#1 0xfe005b54 in __bug (file=0x1d "\b(r)\220", line=1, data=0x359) at
bug.c:30
#2 0xfe02188c in kmem_cache_create (name=0xfe121fa0 "eeee",
size=4263526892, offset=4262690804, flags=4262559768, ctor=0,
dtor=0) at slab.c:857
#3 0xfe127364 in kmem_cache_sizes_init () at slab.c:495
#4 0xfe123568 in start_kernel () at init/main.c:453
#5 0xfe123568 in start_kernel () at init/main.c:453
#6 0xfe123568 in start_kernel () at init/main.c:453
#7 0xfe123568 in start_kernel () at init/main.c:453
#8 0xfe123568 in start_kernel () at init/main.c:453
#9 0xfe123568 in start_kernel () at init/main.c:453
(More stack frames follow...)
--------- "post-mortem" GDB output endss here. ----------------------
indicating a kernel "bail out" do to bogus values getting received by the
"kmem_cache_create" function (although analysis of stack frame #3 indicates
that reasonable values were sent by the "kmem_cache_sizes_init" function).
The corruption of function parameter values, along with the strange
repetition of "start_kernel" in the stack trace, seems to hint at stack
corruption.
Has anyone experienced anything similar?
Thanks,
David Banas
Field Applications Engineer
Nu Horizons Electronics Corp.
2070 Ringwood Avenue
San Jose, CA 95131
(408)434-0800 - office
(415)846-5837 - cell
http://www.nuhorizons.com
<<attachment: winmail.dat>>