Hi, It's not problem with OpenOCD, but with arm-none-eabi-gdb.exe. Reference to the discussed topic "Problem with GDB 6.8". My log is similar with Ramon's.
I cut some information from his log: Debug: 653 9781 gdb_server.c:1997 gdb_input_inner(): received packet: 's' Debug: 654 9781 gdb_server.c:1296 gdb_step_continue_packet(): - Debug: 655 9781 gdb_server.c:1316 gdb_step_continue_packet(): step Debug: 656 9781 armv7m.c:134 armv7m_restore_context(): Debug: 657 9781 target.c:709 target_call_event_callbacks(): target event 6 (resumed) Debug: 658 9781 target.c:2995 target_handle_event(): event: 6 resumed - no action Debug: 659 9781 target.c:2995 target_handle_event(): event: 6 resumed - no action Debug: 660 9781 cortex_m3.c:667 cortex_m3_step(): target stepped dcb_dhcsr = 0x1030007 nvic_icsr = 0x0 Debug: 661 9781 cortex_m3.c:306 cortex_m3_debug_entry(): Debug: 662 9796 cortex_m3.c:114 cortex_m3_clear_halt(): NVIC_DFSR 0x1 Debug: 663 9812 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 0 value 0x20000068 Debug: 664 9812 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 1 value 0xdc0 Debug: 665 9828 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 2 value 0xdc0 Debug: 666 9843 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 3 value 0xe180 Debug: 667 9859 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 4 value 0xa4420001 Debug: 668 9874 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 5 value 0x1 Debug: 669 9874 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 6 value 0xdc0 Debug: 670 9890 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 7 value 0x0 Debug: 671 9906 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 8 value 0x200003da Debug: 672 9921 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 9 value 0xe000ed0c Debug: 673 9921 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 10 value 0x5fa0004 Debug: 674 9937 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 11 value 0x1000 Debug: 675 9953 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 12 value 0x1 Debug: 676 9968 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 13 value 0x2000040c Debug: 677 9968 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 14 value 0xffffffff // <<<<<<<<-------- here, lr = 0xffffffff Debug: 678 9984 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 15 value 0x444 Debug: 679 9999 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 16 value 0x1000000 Debug: 680 10015 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 17 value 0x2000040c Debug: 681 10031 cortex_m3.c:1159 cortex_m3_load_core_reg_u32(): load from core reg 18 value 0x80010410 Debug: 682 10031 cortex_m3.c:1185 cortex_m3_load_core_reg_u32(): load from special reg 19 value 0x0 Debug: 683 10046 cortex_m3.c:1185 cortex_m3_load_core_reg_u32(): load from special reg 20 value 0x0 Debug: 684 10062 cortex_m3.c:1185 cortex_m3_load_core_reg_u32(): load from special reg 21 value 0x0 Debug: 685 10078 cortex_m3.c:1185 cortex_m3_load_core_reg_u32(): load from special reg 22 value 0x0 Debug: 686 10078 cortex_m3.c:368 cortex_m3_debug_entry(): entered debug state in core mode: Thread at PC 0x444, target->state: halted Debug: 687 10078 target.c:709 target_call_event_callbacks(): target event 4 (early-halted) Debug: 688 10078 target.c:2995 target_handle_event(): event: 4 early-halted - no action Debug: 689 10078 target.c:2995 target_handle_event(): event: 4 early-halted - no action Debug: 690 10078 target.c:709 target_call_event_callbacks(): target event 5 (halted) Debug: 691 10078 target.c:2995 target_handle_event(): event: 5 halted - no action User: 692 10078 target.c:965 target_arch_state(): target state: halted User: 693 10078 armv7m.c:465 armv7m_arch_state(): target halted due to single-step, current mode: Thread xPSR: 0x01000000 pc: 0x00000444 Debug: 694 10078 target.c:2995 target_handle_event(): event: 5 halted - no action Debug: 695 10078 cortex_m3.c:672 cortex_m3_step(): target stepped dcb_dhcsr = 0x30007 nvic_icsr = 0x0 Debug: 696 10078 gdb_server.c:1997 gdb_input_inner(): received packet: 'g' Debug: 697 10078 gdb_server.c:1997 gdb_input_inner(): received packet: 'm444,4' Debug: 698 10078 gdb_server.c:1137 gdb_read_memory_packet(): addr: 0x00000444, len: 0x00000004 Debug: 699 10078 target.c:1057 target_read_buffer(): reading buffer of 4 byte at 0x00000444 Debug: 700 10078 gdb_server.c:1997 gdb_input_inner(): received packet: 'mfffffffe,4' Debug: 701 10078 gdb_server.c:1137 gdb_read_memory_packet(): addr: 0xfffffffe, len: 0x00000004 Debug: 702 10078 target.c:1057 target_read_buffer(): reading buffer of 4 byte at 0xfffffffe Error: 703 10078 target.c:1068 target_read_buffer(): address+size wrapped(0xfffffffe, 0x00000004) Error: 704 10078 gdb_server.c:1098 gdb_error(): unexpected error -4 On startup, reg 14(lr, link register) is 0xffffffff, so when step, arm-none-eabi-gdb will set a breakpoint at this position. On cortex-m3, this address will be anded(&) with 0xfffffffe, so arm-none-eabi-gdb will access 0xfffffffe. If OpenOCD return OK to this command "mfffffffe,4", arm-none-eabi-gdb will then send "Z0fffffffe,2" after some memory-reading commands. 2008-12-17 Best Regards, Simon Qian SimonQian([email protected]) ---- www.SimonQian.com 发件人： Rick Altherr 发送时间： 2008-12-17 12:08:18 收件人： SimonQian 抄送： openocd-development 主题： Re: [Openocd-development] About GDB sending "mfffffffe,4" On Dec 16, 2008, at 6:18 AM, SimonQian wrote: Hi all, I've setup a environment based on Eclipse and Codesourcery G++ Lite toolchain. My target MCU is STM32F101C6 chip. When start to debugging, openocd will report an error: Error: address+size wrapped(0xfffffffe, 0x00000004). In the remote log: Sending packet: $mfffffffe,4#fc...Packet received: 00000000. I traced the error, and find that it's caused by invalid value in lr when startup, which is 0xFFFFFFFF. I change the lr to 0xFFFFFF0F, and use run_to_line to run to another position in the same function. And received in the remote log: Sending packet: $mffffff0e,4#c6...Packet received: 00000000. 2008-12-16 Best Regards, Simon Qian SimonQian([email protected]) ---- www.SimonQian.com _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development Can you provide steps to reproduce starting from a full target reset? Also, set debug_level 3 in OpenOCD and attach the output generated when doing those steps. That will help us understand what is happening. -- Rick Altherr [email protected] "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
