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

Yin Bao yin.bao@biometricsolutions.com
Fri Nov 22 08:32:00 GMT 2002

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

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


Peter Vandenabeele wrote:

>On Fri, Nov 15, 2002 at 09:42:37AM -0500, Yin Bao wrote:
>>10/28/2002 snapshot of eCos, Cirrus Logic 7312 template with default 
>>target is Cirrus Login 7312 development board.
>>Successful :
>>built redboot and eCos lib for RAM startup, built the lcd_test program 
>>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)
>>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 
>>(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 
>>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 
>>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 
>>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 ?).
>>Appreciate any help in advance.
>>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

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

More information about the Ecos-discuss mailing list