ISS on Nios II not starting at reset address

[Altera_Forum]

Hi there, 

 I am experiencing a problem with the ISS (Instruction Set Simulator) on a Nios-II design. Since my design would not even reach the first breakpoint in main(), I decided to use the &#39;trace&#39; option in the ISS to see where the CPU wandered off.  To my surprise, this ISS-generated trace file (trace.out) shows that the Nios-II processor starts executing at address 0x00000008. Strange, since the reset address in my design is 0, and I understand that the reset-address of Nios-II is a non-vectored one.  So my question is: is this normal ISS behavior ?   Details below.  Bye from a puzzled Roland http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/huh.gif   Info : PTF Setting uart_0/SYSTEM_BUILDER_INFO/Iss_Launch_Telnet="0" detected Info : &#39;uart_0&#39; character stream will be displayed in this window Info : The host communication device for stdin is uart_0 Info : The host communication device for stdout is uart_0 Info : The host communication device for stderr is uart_0 Info : Running &#39;rollator&#39; model [1] 0x000000f8 <_start>: 0x06c00034 movhi sp, 0 [dstData=0x0 dstReg=sp] Nios2 Register Contents ----------------------------------- PC = 0x000000f8  r0 = 0x00000000 r1 = 0xdeadbeef r2 = 0xdeadbeef r3 = 0xdeadbeef  r4 = 0xdeadbeef r5 = 0xdeadbeef r6 = 0xdeadbeef r7 = 0xdeadbeef  r8 = 0xdeadbeef r9 = 0xdeadbeef r10 = 0xdeadbeef r11 = 0xdeadbeef  r12 = 0xdeadbeef r13 = 0xdeadbeef r14 = 0xdeadbeef r15 = 0xdeadbeef  r16 = 0xdeadbeef r17 = 0xdeadbeef r18 = 0xdeadbeef r19 = 0xdeadbeef  r20 = 0xdeadbeef r21 = 0xdeadbeef r22 = 0xdeadbeef r23 = 0xdeadbeef  r24 = 0xdeadbeef r25 = 0xdeadbeef gp = 0xdeadbeef sp = 0x00000000  fp = 0xdeadbeef ea = 0xdeadbeef ba = 0xdeadbeef ra = 0xdeadbeef  status = 0x00000000 estatus = 0x00000000 bstatus = 0x00000000 ienable = 0x00000000  ipending= 0x00000000   [2] 0x000000fc <_start+0x4>: 0xded40004 addi sp, sp, 20480 [dstData=0x5000 dstReg=sp] Nios2 Register Contents ----------------------------------- PC = 0x000000fc  r0 = 0x00000000 r1 = 0xdeadbeef r2 = 0xdeadbeef r3 = 0xdeadbeef  r4 = 0xdeadbeef r5 = 0xdeadbeef r6 = 0xdeadbeef r7 = 0xdeadbeef  r8 = 0xdeadbeef r9 = 0xdeadbeef r10 = 0xdeadbeef r11 = 0xdeadbeef  r12 = 0xdeadbeef r13 = 0xdeadbeef r14 = 0xdeadbeef r15 = 0xdeadbeef  r16 = 0xdeadbeef r17 = 0xdeadbeef r18 = 0xdeadbeef r19 = 0xdeadbeef  r20 = 0xdeadbeef r21 = 0xdeadbeef r22 = 0xdeadbeef r23 = 0xdeadbeef  r24 = 0xdeadbeef r25 = 0xdeadbeef gp = 0xdeadbeef sp = 0x00005000  fp = 0xdeadbeef ea = 0xdeadbeef ba = 0xdeadbeef ra = 0xdeadbeef  status = 0x00000000 estatus = 0x00000000 bstatus = 0x00000000 ienable = 0x00000000  ipending= 0x00000000

[Altera_Forum]

Ehm, that is 0x000000f8 of course, and not 0x00000008. Guess I am seeing too much hexidecimal values these days http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/wink.gif

[Altera_Forum]

I believe it&#39;s just skipping over the bootloader, which *is* at 0x0... Doesn&#39;t make much sense to emulate what the bootloader is doing, does it? 

 Create an objdump and see where the _start symbol is located.  - slackerman

[Altera_Forum]

The ISS starts executing at the entry point specified in your .ELF file. This is set by the ENTRY directive in the linker script to the function _start: 

 ENTRY( _start )  The debugger starts at the same place when you download from the IDE.

[Altera_Forum]

Ok, this makes sense. Indeed the address I referred to (0x000000f8) corresponds to label _start. Of course running a program does not mean that you reset the system. Thank you Slacker and Wombat. I have one more question but will create a new topic on that, in order not to &#39;pollute&#39; this thread with multiple subjects.