search

STMicroelectronics / OpenOCD

STMicroelectronics customized version of OpenOCD supporting STM32 MCUs and MPUs
Other
130 stars 35 forks source link

gdbserver, Failed to read memory at 0xfffffffe #7

Closed manoj153 closed 2 years ago

manoj153 commented 3 years ago

Any idea what is going wrong?

set WORKAREASIZE 0x3000 set CHIPNAME STM32H7A3ZI set BOARDNAME NUCLEO-H7A3ZI_Q

source [find target/stm32h7x.cfg]

Use connect_assert_srst here to be able to program

even when core is in sleep mode

reset_config srst_only srst_nogate connect_assert_srst

$_CHIPNAME.cpu0 configure -event gdb-attach { echo "Debugger attaching: halting execution" gdb_breakpoint_override hard }

$_CHIPNAME.cpu0 configure -event gdb-detach { echo "Debugger detaching: resuming execution" resume }

Due to the use of connect_assert_srst, running gdb requires

to reset halt just after openocd init.

rename init old_init proc init {} { old_init reset halt }


## openocd runtime info :

Open On-Chip Debugger 0.11.0+dev-00242-g7036ed509-dirty (2021-09-20-14:06) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html init Info : STLINK V3J8M3 (API v3) VID:PID 0483:374E Info : stlink_dap_op_connect(connect) Info : SWD DPIDR 0x6ba02477 Info : STM32H7A3ZI.cpu0: hardware has 8 breakpoints, 4 watchpoints Info : STM32H7A3ZI.cpu0: external reset detected Info : gdb port disabled Info : starting gdb server for STM32H7A3ZI.cpu0 on 3333 Info : Listening on port 3333 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08001530 msp: 0x24000700 TargetName Type Endian TapName State

0 STM32H7A3ZI.ap2 mem_ap little STM32H7A3ZI.cpu halted 1* STM32H7A3ZI.cpu0 cortex_m little STM32H7A3ZI.cpu halted

target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08001530 msp: 0x24000700 Info : Listening on port 6333 for tcl connections Info : Listening on port 4444 for telnet connections target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08001530 msp: 0x24000700 Info : accepting 'gdb' connection on tcp/3333 Debugger attaching: halting execution force hard breakpoints Info : Device: STM32H7Ax/7Bx Info : flash size probed value 2048 Info : STM32H7 flash has dual banks Info : Bank (0) size is 1024 kb, base address is 0x08000000 Info : New GDB Connection: 1, Target STM32H7A3ZI.cpu0, state: halted Error: Failed to read memory at 0xfffffffe

tarek-bochkati commented 2 years ago

Hi,

I acknowledge the issue you have noticed, and confirm that we can reproduce.

We have identified that this issue is mainly caused by bad call stack management at gdb level. Thus we reported the issue to gdb community (please refer to https://sourceware.org/bugzilla/show_bug.cgi?id=28549 )

Several tentative have been done to fix the gdb stack unwinder, but this required much effort. Currently there is a promising patch series (at gdb mailing list https://sourceware.org/pipermail/gdb-patches/2022-January/185131.html).

I will keep you posted whenever this is merged upstream. Once done, you will need to rebuild gdb binary ( if you are using your own toolchain ). At STM32CubeIDE level, we will try to include the fixed ASAP.

Thank you for reporting this. Regards, Tarek