public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] help needed for testing ROM image & Q about gdb
@ 2002-11-15  6:41 Yin Bao
  2002-11-21 10:41 ` Peter Vandenabeele
  0 siblings, 1 reply; 3+ messages in thread
From: Yin Bao @ 2002-11-15  6:41 UTC (permalink / raw)
  To: ecos-discuss


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?

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [ECOS] help needed for testing ROM image & Q about gdb
  2002-11-15  6:41 [ECOS] help needed for testing ROM image & Q about gdb Yin Bao
@ 2002-11-21 10:41 ` Peter Vandenabeele
  2002-11-22  8:32   ` Yin Bao
  0 siblings, 1 reply; 3+ messages in thread
From: Peter Vandenabeele @ 2002-11-21 10:41 UTC (permalink / raw)
  To: Yin Bao; +Cc: ecos-discuss

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [ECOS] help needed for testing ROM image & Q about gdb
  2002-11-21 10:41 ` Peter Vandenabeele
@ 2002-11-22  8:32   ` Yin Bao
  0 siblings, 0 replies; 3+ messages in thread
From: Yin Bao @ 2002-11-22  8:32 UTC (permalink / raw)
  To: Peter Vandenabeele; +Cc: ecos-discuss


Thanks for the response. I did try JTAG and gdb together and the root
of the problem was solved by reading gdb manuals and added the
following lines in the beginning of application code:

    // setting gdb trap/breakpoint
    set_debug_traps();
    breakpoint();

This gives a chance for gdb on host to establish connection with
the target before the execution of application.

Yin

Peter Vandenabeele wrote:

>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
>>
>>    
>>
>
>  
>

-- 

Yin Bao
Senior Software Engineer
Biometric Solutions LLC
805 Third Avenue,  Suite 1500
New York,  NY  10022
Office:  212-317-8308
Fax:     212-317-8055
yin.bao@biometricsolutions.com




-- 
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] 3+ messages in thread

end of thread, other threads:[~2002-11-22 16:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-11-15  6:41 [ECOS] help needed for testing ROM image & Q about gdb Yin Bao
2002-11-21 10:41 ` Peter Vandenabeele
2002-11-22  8:32   ` Yin Bao

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).