Re: S3c2410x (ARM920T) HAL port -- please help me --

[Jonathan Larmour <jifl at eCosCentric dot com>]

[ Sorry if you got a reply elsewhere or sorted this out - if so ignore me! ]

Michael Anburaj wrote:
> <Please look at the previous email (appended below) 1st, forgive me for 
> the long detailed email>
>
> I did further debugging using a JTAG probe & the following is about that:
>
> 1. Redboot_ROMRAM was burnt in the Flash & was made to run.
> 2. I invoked gdb to download hello (elf image of hello.c from 
> /examples): $ arm-elf-gdb hello
> 3. At the gdb prompt (for gdb alone I am using a Win2K+cygwin setup): 
> (gdb) target remote com1
> 4. Load the image: (gdb) l
> 5. Continue (After continue gdb becomes speechless): (gdb) c
>
> At this point gdb send the following packet to the S3c2410x target:
> $C0a#d4
>
> Since I have setup a breakpoint (Through JTAG probe & AXD) at 
> __process_packet() case ‘S’, ‘s’,’C’,’c’, it broke there. As I single 
> stepped through the code, I noted the following:
>
> 1. __hexToInt() converted the string to sigval = 0x0a
> 2. cyg_hal_process_signal() of hal_stub.c got called with sigval = 0x0a. 
> And it returned 0, so sigval got zeroed out.
> 3. cyg_hal_gdb_break_is_set() of hal_stub.c got called. 
> break_buffer.targetAddr == NULL, so it returned 0.
> 4. lock_thread_scheduler() got called with 1. _gdb_cont_thread == 0, so 
> it returned at the very beginning
> 5. Caches were flushed, hal_flush_output() got called & 
> __process_packet() returned control with –1
>
> I follwed still further & fould that the controller returned to 
> return_from_exception: in Vector.S & when to the background process in 
> the Redoot, where it got interrupted.

What's described there looks correct to me I believe. What happens is that 
in previous calls GDB loaded up the memory, and set the PC so that when 
the program returns it returns to the start of the loaded program.

If it barfs there, I would check that what's at the PC in memory is the 
program you expect!

Also, make sure your ROMRAM redboot doesn't have overlapping memory with 
the RAM program you have downloaded. Check your memory layout files for this.

> I am sure something here is wrong. If you have a clue on this, please 
> let me know.
>
> Questions:
> 1.    I guess the (exception) return stack must have got swapped with 
> the new applications (prepared) stack, upon processing “$C0a#d4”. So 
> that Control could jump to the loaded application. Am I right? If I am 
> wrong correct me, as how this should happen & if possible point me to 
> relevant documents.
> 2.    If that’s the case then, why I didn’t happen that way? Why didn’t 
> stack swap happen?

When it returns the stack is irrelevant as the program starts from its PC 
which will not assume it can use the current $sp, and instead will use a 
stack of its own.

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine