This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: help needed for testing ROM image & Q about gdb
- From: Peter Vandenabeele <peter dot vandenabeele at mind dot be>
- To: Yin Bao <yin dot bao at biometricsolutions dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Thu, 21 Nov 2002 19:41:36 +0100
- Subject: Re: [ECOS] help needed for testing ROM image & Q about gdb
- Organisation: Mind NV -- http://mind.be/ -- Leuven/Belgium
- References: <3DD507DD.302@biometricsolutions.com>
- Reply-to: Peter Vandenabeele <peter dot vandenabeele at mind dot be>
On Fri, Nov 15, 2002 at 09:42:37AM -0500, Yin Bao wrote:
>
> Environment:
>
> 10/28/2002 snapshot of eCos, Cirrus Logic 7312 template with default
> packages;
> target is Cirrus Login 7312 development board.
>
> Successful :
>
> built redboot and eCos lib for RAM startup, built the lcd_test program
> included
> in the distribution linked with the eCos library. Use gdb download to
> run the
> program and works fine (LCD shows expected printouts and diag_printf shows
> up from gdb on host)
>
> Failure:
>
> built eCos lib for ROM startup, built the same test with the library, used
> arm-elf-objcopy to convert it into .bin and downloaded onto the flash. Reset
> the target and sees nothing on the LCD (the test is supposed to write
> sth. onto
> lcd and then do while(1) on test exit). Tried to get gdb talking to the
> target
> (ecos was built with gdb stub) and getting timeout eventually, however it
> seems to have got some junk, and even pieces of diag_printf() that says
> "LCD test here!" which makes me believe that the test is somewhat running
> on the target.
>
> My question:
>
> In such a case, what can I do to figure out what is wrong? What is an
> effective
> way to debug in flash execution mode using gdb? (since gdb no longer has
> control till the program starts running?) I know the physical serial is
> working
> fine since I can burn the redboot back and download/ran the same test.
> Even in RAM startup mode, there is sth. strange: If I start redboot, then
> get the host to talk to target through gdb, it was never successful the
> first
> time (does not get acks) till I reset the target while the host keeps trying
> "target remote com1" (this is in RAM startup mode of course). Is this
> a reasonable behavior of gdb stubs?
I am not a technical specialist, but the logical solution here seems to connect
a JTAG debugger, working with gdb to the target. Then you will see what
happens during the boot process from NOR flash. Do you have a JTAG debugger
that works with gdb (we use BDI200) for ARM and PowerPC targets succesfully)?
Does your board support JTAG connections to the processor (and ARM 7 I assume ?).
Success,
Peter
> Appreciate any help in advance.
>
> Yin
>
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>
--
.----------------------------------------------------------.
| Mind: Embedded Linux, eCos and JVM Development in Europe |
|----------------------------------------------------------|
| Peter Vandenabeele, CEO email: peter@mind.be |
| Mind (http://mind.be) tel: +32-16-30.96.66 |
| Vaartkom 11 fax: +32-16-30.96.44 |
| B-3000 Leuven, Belgium gsm: +32-478-27.40.69 |
'----------------------------------------------------------'
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss