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

[Yin Bao]

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