Programcounter value after reset and debug problems

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

...Only humans can be fools, I guess that makes me a pretty good human...

I try to debug a project using avr-dbg and avarice for the first time, using avrdude to upload the program. I now have a stable connection but the debugging does not go so well..

I am able to load and start the debugger, But when trying to single step I keep getting the message "Failed to single-step Failed to single-step0x00000000 in __vectors ()"

I tried to do this several times and behaviour was cinda unstable. sometimes gdb returned at once, other times it hangs a while before returning. Also Sometimes avarice gives message "IDR dirty: 0x40"

(gdb) target remote localhost:4242
Remote debugging using localhost:4242
0x00000000 in __vectors ()
(gdb) step
Single stepping until exit from function __vectors, 
which has no line number information.
Failed to single-stepFailed to single-stepFailed to single-stepFailed to single-stepFailed to single-stepFailed to single-stepFailed to single-stepFailed to single-stepFailed to single-stepFailed to single-stepFailed to single-stepFailed to single-stepFailed to single-stepFailed to single-stepFailed to single-stepFailed to single-stepFailed to single-step0x00000004 in __vectors ()
(gdb) info registers PC
PC             0x4	4

When I set a breakpoint early in main, before anything is initialized and then Running by issue command "continue". The breakpoint does not kick in. If breaking using ctrl+c, The program runs deep inside the application.

I wonder if the startup code is corrupted somehow, or if stack is initialized wrongly. Avrdude do however not report any errors when flashing. Sometimes register PC does not point to 0x0 but 0xfffe after i first flashed device using avrdude before connecting avarice and avr-dbg. This scares me cause I do not know what will happen since the address does not exist. I thought avr-dbg should have issued a reset on the reset pin before attaching making the PC turn to 0x00.
SP is also having a strange value but SP should be initialised later.

Since I merely can call myself an expert in anything I dear show you the listing of the first few inches of my program as read by gdb disassemble command. At the bottom I have listed the registers as they are after gdb attached.

(gdb) target remote localhost:4242
Remote debugging using localhost:4242
0x0000fffe in ?? ()
(gdb) disassemble 0x0 0x200
Dump of assembler code from 0x0 to 0x200:
0x00000000 <__vectors+0>:	jmp	0x88	;  0x88 <__trampolines_start>
0x00000004 <__vectors+4>:	jmp	0x14d8	;  0x14d8 <__vector_1>
0x00000008 <__vectors+8>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x0000000c <__vectors+12>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000010 <__vectors+16>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000014 <__vectors+20>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000018 <__vectors+24>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x0000001c <__vectors+28>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000020 <__vectors+32>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000024 <__vectors+36>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000028 <__vectors+40>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x0000002c <__vectors+44>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000030 <__vectors+48>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000034 <__vectors+52>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000038 <__vectors+56>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x0000003c <__vectors+60>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000040 <__vectors+64>:	jmp	0x460	;  0x460 <__vector_16>
0x00000044 <__vectors+68>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000048 <__vectors+72>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x0000004c <__vectors+76>:	jmp	0xf80	;  0xf80 <__vector_19>
0x00000050 <__vectors+80>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000054 <__vectors+84>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000058 <__vectors+88>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x0000005c <__vectors+92>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000060 <__vectors+96>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000064 <__vectors+100>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000068 <__vectors+104>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x0000006c <__vectors+108>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000070 <__vectors+112>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000074 <__vectors+116>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x00000078 <__vectors+120>:	jmp	0xc2	;  0xc2 <__bad_interrupt>
0x0000007c <__c.1935+0>:	ori	r22, 0x43	; 67
0x0000007e <__c.1935+2>:	ori	r22, 0xE9	; 233
0x00000080 <__c.1935+4>:	andi	r22, 0x0F	; 15
0x00000082 <__c.1935+6>:	andi	r23, 0x53	; 83
0x00000084 <__c.1935+8>:	subi	r23, 0x88	; 136
0x00000086 <__c.1935+10>:	nop
0x00000088 <__trampolines_start+0>:	eor	r1, r1
0x0000008a <__trampolines_start+2>:	out	0x3f, r1	; 63
0x0000008c <__trampolines_start+4>:	ldi	r28, 0xFF	; 255
0x0000008e <__trampolines_start+6>:	ldi	r29, 0x10	; 16
0x00000090 <__trampolines_start+8>:	out	0x3e, r29	; 62
0x00000092 <__trampolines_start+10>:	out	0x3d, r28	; 61
0x00000094 <__do_copy_data+0>:	ldi	r17, 0x02	; 2
0x00000096 <__do_copy_data+2>:	ldi	r26, 0x00	; 0
---Type  to continue, or q  to quit---
0x00000098 <__do_copy_data+4>:	ldi	r27, 0x01	; 1
0x0000009a <__do_copy_data+6>:	ldi	r30, 0x02	; 2
0x0000009c <__do_copy_data+8>:	ldi	r31, 0x57	; 87
0x0000009e <__do_copy_data+10>:	rjmp	.+4      	;  0xa4 <.do_copy_data_start>
0x000000a0 <.do_copy_data_loop+0>:	lpm	r0, Z+
0x000000a2 <.do_copy_data_loop+2>:	st	X+, r0
0x000000a4 <.do_copy_data_start+0>:	cpi	r26, 0x02	; 2
0x000000a6 <.do_copy_data_start+2>:	cpc	r27, r17
0x000000a8 <.do_copy_data_start+4>:	brne	.-10     	;  0xa0 <.do_copy_data_loop>
0x000000aa <__do_clear_bss+0>:	ldi	r17, 0x09	; 9
0x000000ac <__do_clear_bss+2>:	ldi	r26, 0x02	; 2
0x000000ae <__do_clear_bss+4>:	ldi	r27, 0x02	; 2
0x000000b0 <__do_clear_bss+6>:	rjmp	.+2      	;  0xb4 <.do_clear_bss_start>
0x000000b2 <.do_clear_bss_loop+0>:	st	X+, r1
0x000000b4 <.do_clear_bss_start+0>:	cpi	r26, 0x06	; 6
0x000000b6 <.do_clear_bss_start+2>:	cpc	r27, r17
0x000000b8 <.do_clear_bss_start+4>:	brne	.-8      	;  0xb2 <.do_clear_bss_loop>
0x000000ba <.do_clear_bss_start+6>:	call	0x110	;  0x110 
0x000000be <.do_clear_bss_start+10>: jmp 0x56fe ; 0x56fe 0x000000c2 <__bad_interrupt+0>: jmp 0 ; 0x0 <__vectors> 0x000000c6 : push r29 0x000000c8 : push r28 0x000000ca : in r28, 0x3d ; 61 0x000000cc : in r29, 0x3e ; 62 0x000000ce : ldi r30, 0x21 ; 33 0x000000d0 : ldi r31, 0x00 ; 0 0x000000d2 : ldi r24, 0xF0 ; 240 0x000000d4 : st Z, r24 0x000000d6 : ldi r30, 0x24 ; 36 0x000000d8 : ldi r31, 0x00 ; 0 0x000000da : ldi r24, 0xBB ; 187 0x000000dc : st Z, r24 0x000000de : ldi r30, 0x27 ; 39 0x000000e0 : ldi r31, 0x00 ; 0 0x000000e2 : ldi r24, 0x7C ; 124 0x000000e4 : st Z, r24 0x000000e6 : ldi r30, 0x2A ; 42 0x000000e8 : ldi r31, 0x00 ; 0 0x000000ea : ldi r24, 0xB4 ; 180 0x000000ec : st Z, r24 0x000000ee : ldi r30, 0x22 ; 34 0x000000f0 : ldi r31, 0x00 ; 0 0x000000f2 : st Z, r1 0x000000f4 : ldi r30, 0x25 ; 37 0x000000f6 : ldi r31, 0x00 ; 0 0x000000f8 : ldi r24, 0x08 ; 8 0x000000fa : st Z, r24 0x000000fc : ldi r30, 0x28 ; 40 0x000000fe : ldi r31, 0x00 ; 0 0x00000100 : ldi r24, 0x40 ; 64 0x00000102 : st Z, r24 0x00000104 : ldi r30, 0x2B ; 43 0x00000106 : ldi r31, 0x00 ; 0 0x00000108 : st Z, r1 0x0000010a : pop r28 0x0000010c : pop r29 0x0000010e : ret 0x00000110 : push r12 0x00000112 : push r13 0x00000114 : push r14 0x00000116 : push r15 0x00000118 : push r16 0x0000011a : push r17 0x0000011c : push r29 0x0000011e : push r28 0x00000120 : in r28, 0x3d ; 61 0x00000122 : in r29, 0x3e ; 62 0x00000124 : sbiw r28, 0x0c ; 12 0x00000126 : in r0, 0x3f ; 63 0x00000128 : cli 0x0000012a : out 0x3e, r29 ; 62 0x0000012c : out 0x3f, r0 ; 63 0x0000012e : out 0x3d, r28 ; 61 0x00000130 : std Y+3, r1 ; 0x03 0x00000132 : cli 0x00000134 : call 0xc6 ; 0xc6 0x00000138 : ldi r30, 0x50 ; 80 0x0000013a : ldi r31, 0x00 ; 0 0x0000013c : st Z, r1 0x0000013e : call 0x40a ; 0x40a ... (gdb) info registers r0 0x80 128 r1 0x0 0 r2 0x0 0 r3 0x0 0 r4 0x44 68 r5 0x20 32 r6 0x20 32 r7 0x74 116 r8 0x32 50 r9 0x2e 46 r10 0x25 37 r11 0x3a 58 r12 0x75 117 r13 0x32 50 r14 0x81 129 r15 0x14 20 r16 0x0 0 r17 0xff 255 r18 0xb2 178 r19 0x6f 111 r20 0x0 0 r21 0x0 0 r22 0x92 146 r23 0x0 0 r24 0x0 0 r25 0x0 0 r26 0xa 10 r27 0x0 0 r28 0xea 234 r29 0xf 15 r30 0x4 4 r31 0x3f 63 SREG 0x40 64 SP 0x8000e2 0x8000e2 PC 0xfffe 65534

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The "IDR dirty" in that could be a clue. This is only normally seen when there's an electronic noise problem (often "long" cables) between the debugger and the AVR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What aboute PC=0xfffe? I guess that could be a faulty reading if there is noise in the system but then the reading should be random, its not. However the way it behave while stepping is kinda random though. I will check the proto board for noise and bad connections. Thanx for the tip...

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"