Re: [ECOS] help needed for testing ROM image & Q about gdb

[Yin Bao <yin dot bao at biometricsolutions dot com>]

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