public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] [Fwd: redboot RAM for EB40 v2.0]
@ 2002-11-06  5:42 Jonathan Larmour
  0 siblings, 0 replies; only message in thread
From: Jonathan Larmour @ 2002-11-06  5:42 UTC (permalink / raw)
  To: eCos discussion

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: redboot RAM for EB40 v2.0 --]
[-- Type: message/rfc822, Size: 9211 bytes --]

[-- Attachment #2.1.1.1: Type: text/plain, Size: 2149 bytes --]

Hi,

I am beginner to the eCos and I need assistance from expert. I have purchased Atmel's EB40 v2.0 starter kit and I have been stuck with building redboot ram from ecos 2.0 alpha release and ecos configtool 2.11 for longer time. I know that this old theme but I could not find solution from discuss list where the problem is a bit described. My own build release of redboot_RAM.elf starts immediatelly (almost always if it wouldn't hung up) gdb protocol as well as the precompiled one from ecos site. I have also observed that it works unstable. I mean that the same image uploaded with gdb first time sends massage I have logged in file test1.log and the second it sends that what is in test2.log and than hung up. It looks like redboot image used somewhere uninitialized data memory area. I was trying to understand why it starts gdb protocol and one entry point I can see is packages/redboot/current/src/main.c : 324

#ifdef CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
            if (res == _GETS_GDB) {
...
so I have inserted functions like mon_write_char or diag_printf to trace real program execution (like "###TP1" from test2.log) but it seems that image works another way I can see from source and I have also debugged image with ARM STD v2.5. I am not sure but my image uses probably interrupt from serial as well as it pools serial status register in routines cyg_hal_plf_serial_putc and cyg_hal_plf_serial_getc but ARM STD 2v5 debugger don't emulate AT91x408xx so I have to set/clear status bits at 0xfffd0014 or 0xfffcc014 by my hand. Therefore this is the reason why image works in predicted manner under ARM STD and different in real I guess.

But I really dont know how to configure redboot better even I have applied redboot_RAM.ecm from /packages/hal/arm/at91/misc. Another thing is gdb which could not connects to rdi target under cygwin and under linux is able to establish faultless transmission at speed not greater than 9600 bps.

I use cygwin 1.3.12-4 and gcc 3.2, binutils 2.13, newlib 1.10, gdb 5.2.1
for logging I used auxiliary terminal connected to TX line from EB40.

Best regards,
Krzysztof Blaszkowski




[-- Attachment #2.1.1.2: Type: text/html, Size: 3179 bytes --]

[-- Attachment #2.1.2: TEST2.LOG --]
[-- Type: application/octet-stream, Size: 468 bytes --]

[-- Attachment #2.1.3: TEST1.LOG --]
[-- Type: application/octet-stream, Size: 397 bytes --]

[-- Attachment #3: Type: text/plain, Size: 146 bytes --]

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2002-11-06 13:42 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-11-06  5:42 [ECOS] [Fwd: redboot RAM for EB40 v2.0] Jonathan Larmour

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).