Software counter does not advance

Question

I am trying to debug the Reset_Handler() function written in assembler (which I do not understand, but was provided as part of the standard library). Using GDB, I go through each instruction using ni . Here is what I get:

 (gdb) ni 0x08005dc4 in Reset_Handler () (gdb) ni 0x08005dc6 in Reset_Handler () (gdb) ni 0x08005dc6 in Reset_Handler () (gdb) ni 0x08005dc6 in Reset_Handler () (gdb) ni 0x08005dc6 in Reset_Handler () 

In fact, the program pointer is stuck at 0x08005dc6 . Is this normal behavior, or should the program pointer progress every time I do ni ? The following is the beginning of Reset_Handler() :

  .section .text.Reset_Handler .weak Reset_Handler .type Reset_Handler, %function Reset_Handler: /* Copy the data segment initializers from flash to SRAM */ movs r1, #0 b LoopCopyDataInit CopyDataInit: ldr r3, =_sidata ldr r3, [r3, r1] str r3, [r0, r1] adds r1, r1, #4 LoopCopyDataInit: ldr r0, =_sdata ldr r3, =_edata adds r2, r0, r1 cmp r2, r3 bcc CopyDataInit ldr r2, =_sbss b LoopFillZerobss /* Zero fill the bss segment. */ FillZerobss: movs r3, #0 str r3, [r2], #4 

EDIT . Here are the parsed instructions:

 disas Dump of assembler code for function Reset_Handler: 0x08005dc0 <+0>: movs r1, #0 0x08005dc2 <+2>: bn 0x8005dcc <LoopCopyDataInit> 0x08005dc4 <+4>: ldr r3, [pc, #40] ; (0x8005df0 <LoopFillZerobss+16>) => 0x08005dc6 <+6>: ldr r3, [r3, r1] 0x08005dc8 <+8>: str r3, [r0, r1] 0x08005dca <+10>: adds r1, #4 0x08005dcc <+0>: ldr r0, [pc, #36] ; (0x8005df4 <LoopFillZerobss+20>) 0x08005dce <+2>: ldr r3, [pc, #40] ; (0x8005df8 <LoopFillZerobss+24>) 0x08005dd0 <+4>: adds r2, r0, r1 0x08005dd2 <+6>: cmp r2, r3 0x08005dd4 <+8>: bcc.n 0x8005dc4 <Reset_Handler+4> 0x08005dd6 <+10>: ldr r2, [pc, #36] ; (0x8005dfc <LoopFillZerobss+28>) 0x08005dd8 <+12>: bn 0x8005de0 <LoopFillZerobss> 0x08005dda <+0>: movs r3, #0 0x08005ddc <+2>: str.w r3, [r2], #4 0x08005de0 <+0>: ldr r3, [pc, #28] ; (0x8005e00 <LoopFillZerobss+32>) 0x08005de2 <+2>: cmp r2, r3 0x08005de4 <+4>: bcc.n 0x8005dda <FillZerobss> 0x08005de6 <+6>: bl 0x8005c64 <SystemInit> 0x08005dea <+10>: bl 0x8000184 <main> 0x08005dee <+14>: bx lr End of assembler dump. 

Answer 1

Based on the code and disassembly that you posted, I assume that the address that is in _sidata is not valid. _sidata loads in r3 , so when

  ldr r3, [r3, r1] 

invalid access causes another processor reset, which then runs until it repeats this instruction. Or something like that.

Check that in _sidata .

---

Some additional notes:

I see that the instruction at xxxx uses r0 , but I don’t see where r0 was initialized in reset_handler() . It is possible that the code that calls reset_handler() could correctly configure r0 , but to know for sure, we will need to see the table of exception vectors and the code that the reset vector actually points to. (I assume this is for ARM7 or similar - let me know if I guessed wrong), where the table of exception vectors might look something like this (borrowed from ethernut.de), which will be bound to a label named _start to reset:

 .global __vectors __vectors: ldr pc, [pc, #24] /* Reset */ ldr pc, [pc, #24] /* Undefined instruction */ ldr pc, [pc, #24] /* Software interrupt */ ldr pc, [pc, #24] /* Prefetch abort */ ldr pc, [pc, #24] /* Data abort */ ldr pc, [pc, #24] /* Reserved */ /* * On IRQ the PC will be loaded from AIC_IVR, which * provides the address previously set in AIC_SVR. * The interrupt routine will be called in ARM_MODE_IRQ * with IRQ disabled and FIQ unchanged. */ ldr pc, [pc, #-0xF20] /* Interrupt request, auto vectoring. */ ldr pc, [pc, #-0xF20] /* Fast interrupt request, auto vectoring. */ .word _start .word __undef .word __swi .word __prefetch_abort .word __data_abort 

Answer 2

Well, it depends :-)

The instruction on 0x08005dc6 depends on 0x08005dc6 . It is possible that in the reset handler you may have an instruction, for example:

 0x08005dc6 jmp 0x08005dc6 

who would exhibit this behavior.

You should check what is actually in this place, with something like:

 disas 0x08005dc6 0x08005dcf