How to Read Register Values Directly Openocd
Contents
- 1 Article purpose
- 2 Introduction
- 3 Overview of GDB setup for STM32MPU
- 3.1 GDB setup paths
- 3.two JTAG and SWD debug port
- iv Installing the GDB tool
- 4.1 Installing the GDB tool on your host PC
- 4.1.i Using the STM32MPU Embedded Software distribution
- four.i.i.1 Developer Package
- 4.1.i Using the STM32MPU Embedded Software distribution
- iv.2 Installing the GDB on your target board
- 4.1 Installing the GDB tool on your host PC
- 5 Getting started
- 5.1 Prerequisites
- five.two Debug OpenSTLinux BSP components
- 5.2.1 Setting up GDB / OpenOCD debug path environment
- v.2.2 Configuring GDB and OpenOCD for zipper on a running target
- 5.2.2.ane U-Kick execution stage
- 5.ii.2.2 Linux kernel execution phase
- v.2.3 Configuring GDB and OpenOCD for attachment on boot
- five.ii.3.one TF-A(BL2) kick case
- 5.two.3.ii TF-A(BL32) boot example
- 5.2.3.three OP-TEE kicking case
- v.ii.three.4 U-Kicking boot case
- 5.2.3.5 Linux kernel kicking instance
- 5.two.4 Running OpenOCD and GDB
- 5.2.v To know more about Linux kernel debug with GDB
- v.2.6 Access to STM32MP registers
- v.two.6.one Using gdb control line
- 5.ii.6.ii Using CMSIS-SVD environment
- 5.3 Debug Cortex-M4 firmware with GDB
- 5.three.1 Debug Cortex-M4 firmware in technology kicking way
- v.3.2 Debug Cortex-M4 firmware in production kick mode
- five.iv Debug Linux application with gdbserver
- 5.4.one Enable debug data
- 5.4.2 Remote debugging using gdbserver
- 5.5 User interface application
- 5.5.1 Text user interface (TUI) style
- 5.five.two Debugging with GDBGUI
- five.5.3 Debugging with DDD
- 5.5.iv Debugging with IDE
- 6 To get further
- 6.ane Useful GDB commands
- six.2 Cadre dump analysis using GDB
- half-dozen.3 Tips
- seven References
1 Article purpose [edit]
This article provides the basic data needed to kickoff using the GDB [1] application tool.
It explains how to utilize this GNU debugger tool connected to your ST lath target via Ethernet or via ST-LINK, and how to perform cross-debugging (IDE, gdb viewer tool or command line) on Arm® Cortex®-A7 side for Linux ® application, Linux ® kernel (including external modules), or Arm® Cortext®-M4 firmware.
2 Introduction [edit]
The following table provides a brief clarification of the tool, as well as its availability depending on the software packages:
: this tool is either present (ready to apply or to be activated), or can be integrated and activated on the software parcel.
: this tool is not nowadays and cannot be integrated, or it is present just cannot be activated on the software package.
| Tool | STM32MPU Embedded Software distribution | STM32MPU Embedded Software distribution for Android™ | ||||||
|---|---|---|---|---|---|---|---|---|
| Name | Category | Purpose | Starter Package | Developer Package | Distribution Package | Starter Package | Programmer Package | Distribution Bundle |
| GDB | Debugging tools | The GNU Project debugger, GDB [1], allows monitoring program execution, or what the program was doing at the moment it crashed. | * | | ** | | | |
| * Cantankerous compile gdb and openocd binaries are required and but available from Developer Package. ** It is recommended to use the Developer Package to run the gdb debug session, which provided all dependencies |
| |||||||
The GDB can perform four main types of actions (plus other corollary actions) to aid you lot detect bugs when running your software or application:
- Kickoff the programme, specifying anything that might affect its behaviour.
- Make the program stop on specific conditions.
- Examine what happened when the plan stopped.
- Update the plan in order to test a bug correction, and leap to the next one.
3 Overview of GDB setup for STM32MPU [edit]
3.1 GDB setup paths [edit]
Two paths can be used in the STM32MPU environment for GDB setup:
- gdb ↔ gdbserver path through Ethernet, used for Cortex-A7 Linux applications.
- In that case, two software components are required, one on the target and the other on the host PC.
- gdb ↔ JTAG/SWD path through OpenOCD and ST-LINK, used both for Cortex-M4 firmware and Cortex-A7 Linux kernel.
- In that case, simply one software component is required on the host PC.
Two components are included in OpenSTLinux Developer Package for GDB setup:
- gdbserver: embedded on target rootfs and used equally remote admission for a host connection
- arm-ostl-linux-gnueabi-gdb: embedded on host PC side, cross-compiled gdb binary that manages the connectedness between the host computer and the target lath
three.2 JTAG and SWD debug port [edit]
The STM32MPU features two debug ports through the embedded CoreSight™ component that implements an external admission port for connecting debugging equipment:
- A 5-pin standard JTAG interface (JTAG-DP)
- A 2-pin (clock + data) "serial-wire debug" port (SW-DP)
These two modes are mutually exclusive since they share the same I/O pins.
Refer to STM32MP15 reference manuals for information related to JTAG and SWD.
iv Installing the GDB tool [edit]
This tool is made of two parts, one on the host PC, and a second on the target (only for debugging Linux applications).
4.ane Installing the GDB tool on your host PC [edit]
Below is the listing of required components:
- The cross-compiled GDB binary
- The OpenOCD binary and configuration files
- The symbols files of all BSP components (TF-A, U-Kicking and Linux kernel), corresponding to the images of the OpenSTLinux Starter Bundle.
4.1.1 Using the STM32MPU Embedded Software distribution [edit]
4.1.1.i Developer Package [edit]
But the Developer Package can be used, since information technology is the just i which provides all the required components.
4.2 Installing the GDB on your target board [edit]
On the target board, merely the gdbserver binary is required for debugging Linux applications.
Information technology is available past default within the Starter Parcel, which provides images linked to the Developer Package.
5 Getting started [edit]
This chapter describes the 2 ways for debugging OpenSTLinux BSP components (TF-A, U-Boot and Linux kernel including external modules), Linux applications and Cortex-M4 firmware: by using GDB commands or by using a GDB user interface such as gdbgui, DDD or IDE.
v.1 Prerequisites [edit]
The target board is upwards and running.
five.2 Debug OpenSTLinux BSP components [edit]
v.2.1 Setting upwards GDB / OpenOCD debug path surroundings [edit]
- Architecture
The effigy beneath shows the architecture corresponding to the GDB/OpenOCD connected to Cortex-A7 and Cortex-M4 cores.
Notation: The ST-LINK probes bachelor on the STM32MP1 board can exist used through a USB interface, besides as whatever other external probes through the Trace or JTag connector.
- Prerequisites
- The Developer Package must exist installed. It provides the SDK, the debug symbol files and the source files for TF-A, U-Boot and Linux kernel (refer to STM32MP1 Developer Package).
- The debug symbol files contain the symbols for the TF-A, U-Kicking and Linux kernel binaries (from the Starter Package image) that have been flashed on the lath.
- Environment configuration files
- To speed up surroundings setup for debugging with GDB, download two configuration files, and install them on your PC (nether the home directory: $HOME/gdbscripts/). You can so customize them:
- - Setup.gdb: primary configuration file in which yous can define the debug context you want to use (Refer to Boot chain overview for details). Possible combinations are:
- Trusted boot chain:
- - Setup.gdb: primary configuration file in which yous can define the debug context you want to use (Refer to Boot chain overview for details). Possible combinations are:
-
-
Debug mode (one)
Cortex-A7
TF-A(BL2)(two)
Cortex-A7
TF-A(BL32)(three)
Cortex-A7
SSBL(U-Boot)(four)
Cortext-A7
Linux kernel(0) - Boot (1) - Running target
-
-
-
- Trusted kick concatenation with OP-TEE:
-
-
-
Debug mode (1)
Cortex-A7
TF-A(BL2)(ii)
Cortex-A7
OP-TEE(3)
Cortex-A7
SSBL(U-Boot)(iv)
Cortext-A7
Linux kernel(0) - Boot (1) - Running target
-
-
- - File:Path env py.txt: customization file to define all the paths to source and symbol files, which tin can either be directly retrieved from the Developer Package (refer to the Example of directory construction for Packages), or result from a new compilation. In both cases, update the paths corresponding to your surroundings.
Please read carefully the comments provided in this file to help you updating source and symbol paths .
- - File:Path env py.txt: customization file to define all the paths to source and symbol files, which tin can either be directly retrieved from the Developer Package (refer to the Example of directory construction for Packages), or result from a new compilation. In both cases, update the paths corresponding to your surroundings.
- Shop these files locally on your host PC, bank check for name cast (Setup.gdb and Path_env.py) and update them accordingly.
5.2.ii Configuring GDB and OpenOCD for attachment on a running target [edit]
When the target board is running, you can adhere the GDB merely during one of post-obit phases:
5.2.2.i U-Boot execution stage [edit]
Select the right configuration in Setup.gdb:
# Set debug phase: # 1: Attach at Cortex-A7 / TF-A(BL2) # 2: Attach at Cortex-A7 / TF-A(BL32) or OP-TEE # 3: Adhere at Cortex-A7 / U-Kick # 4: Attach at Cortex-A7 / Linux kernel prepare $debug_phase = 3
# 0: Adhere at boot # one: Attach running target set $debug_mode = 1
# Set debug trusted bootchain: # 0: TF-A BL2 / TF-A BL32 / U-Boot / Linux kernel # 1: TF-A BL2 / OP-TEE / U-Kick / Linux kernel prepare $debug_trusted_bootchain = 0 or 1 #depending on your software boot chain configuration
When the configuration is complete, bound to Running OpenOCD and GDB.
5.2.2.ii Linux kernel execution stage [edit]
Select the correct configuration in Setup.gdb:
# Fix debug stage: # 1: Adhere at Cortex-A7 / TF-A(BL2) # 2: Attach at Cortex-A7 / TF-A(BL32) or OP-TEE # iii: Attach at Cortex-A7 / U-Boot # 4: Attach at Cortex-A7 / Linux kernel prepare $debug_phase = 4
# 0: Adhere at boot # 1: Attach running target ready $debug_mode = i
# Ready debug trusted bootchain: # 0: TF-A BL2 / TF-A BL32 / U-Kicking / Linux kernel # ane: TF-A BL2 / OP-TEE / U-Kick / Linux kernel ready $debug_trusted_bootchain = 0 or one #depending on your software boot chain configuration
When the configuration is complete, jump to Running OpenOCD and GDB.
5.2.3 Configuring GDB and OpenOCD for attachment on boot [edit]
Y'all tin can attach the GDB during target kick only in the following cases:
- TF-A(BL2) kick case;
- TF-A(BL32) kicking instance;
- OP-TEE kicking case;
- U-Kicking boot case;
- Linux kernel kick example.
To handle the cases above, the FSBL image has to be wrapped through the tool stm32wrapper4dbg. This operation allows the debugger to halt the target at the very first instruction of FSBL.
 Warning |
| In these cases, the target board will automatically reboots when the GDB starts. |
5.two.3.1 TF-A(BL2) boot case [edit]
In that case, the GDB breaks in bl2_entrypoint office.
Select the right configuration in Setup.gdb:
# Set debug phase: # 1: Attach at Cortex-A7 / TF-A(BL2) # 2: Attach at Cortex-A7 / TF-A(BL32) or OP-TEE # 3: Attach at Cortex-A7 / U-Boot # 4: Attach at Cortex-A7 / Linux kernel set $debug_phase = 1
# 0: Attach at boot # 1: Attach running target ready $debug_mode = 0
# Set debug trusted bootchain: # 0: TF-A BL2 / TF-A BL32 / U-Boot / Linux kernel # one: TF-A BL2 / OP-TEE / U-Kicking / Linux kernel set $debug_trusted_bootchain = 0 or 1 #depending on your software boot chain configuration
When this operation is complete, spring to Running OpenOCD and GDB.
five.ii.3.2 TF-A(BL32) kick case [edit]
In that case, the GDB breaks in sp_min_entrypoint function.
Select the right configuration in Setup.gdb:
# Set debug stage: # 1: Attach at Cortex-A7 / TF-A(BL2) # ii: Attach at Cortex-A7 / TF-A(BL32) or OP-TEE # 3: Adhere at Cortex-A7 / U-Kick # 4: Adhere at Cortex-A7 / Linux kernel set $debug_phase = ii
# 0: Attach at boot # 1: Attach running target ready $debug_mode = 0
# Set debug trusted bootchain: # 0: TF-A BL2 / TF-A BL32 / U-Kicking / Linux kernel # 1: TF-A BL2 / OP-TEE / U-Boot / Linux kernel gear up $debug_trusted_bootchain = 0
When this performance is complete, spring to Running OpenOCD and GDB.
5.2.3.3 OP-TEE boot case [edit]
In that case, the GDB breaks in _start function.
Select the right configuration in Setup.gdb:
# Prepare debug stage: # 1: Adhere at Cortex-A7 / TF-A(BL2) # 2: Attach at Cortex-A7 / TF-A(BL32) or OP-TEE # iii: Attach at Cortex-A7 / U-Boot # iv: Attach at Cortex-A7 / Linux kernel ready $debug_phase = 2
# 0: Attach at boot # 1: Adhere running target set $debug_mode = 0
# Set up debug trusted bootchain: # 0: TF-A BL2 / TF-A BL32 / U-Kicking / Linux kernel # ane: TF-A BL2 / OP-TEE / U-Boot / Linux kernel set $debug_trusted_bootchain = ane
When this operation is complete, bound to Running OpenOCD and GDB.
5.two.3.iv U-Kick boot instance [edit]
In that case, the GDB breaks in in _start function.
Select the correct configuration in Setup.gdb:
# Set up debug phase: # 1: Attach at Cortex-A7 / TF-A(BL2) # 2: Attach at Cortex-A7 / TF-A(BL32) or OP-TEE # 3: Attach at Cortex-A7 / U-Boot # 4: Adhere at Cortex-A7 / Linux kernel set $debug_phase = 3
# 0: Attach at kick # 1: Attach running target ready $debug_mode = 0
# Set debug trusted bootchain: # 0: TF-A BL2 / TF-A BL32 / U-Kick / Linux kernel # one: TF-A BL2 / OP-TEE / U-Boot / Linux kernel set $debug_trusted_bootchain = 0 or 1 #depending on your software kick concatenation configuration
When this operation is complete, jump to Running OpenOCD and GDB.
v.2.3.five Linux kernel kicking case [edit]
In that case, the GDB breaks in stext function.
Select the right configuration in Setup.gdb:
# Fix debug phase: # i: Adhere at Cortex-A7 / TF-A(BL2) # two: Attach at Cortex-A7 / TF-A(BL32) or OP-TEE # 3: Attach at Cortex-A7 / U-Kicking # 4: Attach at Cortex-A7 / Linux kernel set $debug_phase = 4
# 0: Attach at boot # 1: Attach running target set $debug_mode = 0
# Set debug trusted bootchain: # 0: TF-A BL2 / TF-A BL32 / U-Boot / Linux kernel # 1: TF-A BL2 / OP-TEE / U-Boot / Linux kernel set up $debug_trusted_bootchain = 0 or one #depending on your software boot chain configuration
When this operation is complete, jump to Running OpenOCD and GDB.
v.2.four Running OpenOCD and GDB [edit]
- Prerequisites
Before running OpenOCD and GDB, check that the target board is in the correct state.
For all configurations except GDB attachment to a running SSBL (U-Kick), the lath has to operate in OpenSTLinux running mode.
In case of attachment to a running SSBL (U-Boot) configuration, the lath target must be in U-Boot console mode:
#Reboot the target board #Press any cardinal to finish at U-Kick execution when booting the board STM32MP> ... STM32MP> Striking any key to stop autoboot: 0 STM32MP>
When you are in the expected configuration, two dissimilar consoles must exist started: 1 for OpenOCD and i for GDB.
The SDK environment must be installed on both console terminals.
- OpenOCD panel
# First console for starting openocd with configuration file PC $> source <Your_SDK_path> /environment-setup-cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi PC $> openocd -f <lath.cfg>
- Possible target configuration files for <board.cfg> :
-
Target lath Adapter SWD mode board.cfg JTAG mode lath.cfg STM32MP157C-EV1 ST-LINK * board/stm32mp15x_ev1_stlink_swd.cfg lath/stm32mp15x_ev1_stlink_jtag.cfg STM32MP157C-EV1 U-LINK2 board/stm32mp15x_ev1_ulink2_swd.cfg board/stm32mp15x_ev1_ulink2_jtag.cfg STM32MP157C-EV1 J-LINK board/stm32mp15x_ev1_jlink_swd.cfg lath/stm32mp15x_ev1_jlink_jtag.cfg STM32MP157X-DK2 ST-LINK * board/stm32mp15x_dk2.cfg **
- * Both v2 and v3 are supported.
- ** JTAG wires are not connected in DK2.
- Notation: Information technology is recommended to utilise SWD, which is faster than JTAG.
- GDB console
| Warning |
| The GDB must be executed from the directory where the scripts accept been installed (i.due east. $HOME/gdbscripts/) |
# Second panel for starting the GDB PC $> cd $HOME/gdbscripts/ PC $> source <Your_SDK_path> /environment-setup-cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi PC $> $GDB -ten Setup.gdb
5.2.five To know more about Linux kernel debug with GDB [edit]
Please refer to Debugging the Linux kernel using the GDB.
5.ii.6 Access to STM32MP registers [edit]
5.2.half dozen.1 Using gdb command line [edit]
- The post-obit monitoring commands can be used to read a register value:
(gdb) monitor mdb <phys_address> [count] #Display target retentiveness every bit 8-chip bytes (gdb) monitor mdh <phys_address> [count] #Display target memory equally 16-bit bytes (gdb) monitor mdw <phys_address> [count] #Display target retentiveness as 32-flake bytes
- For case: Read RCC_MP_APB1ENSETR register on STM32MP1 to bank check RCC APB1 peripheral enable condition.
(gdb) monitor mdw phys 0x50000a00 #full 32bits value upshot requested 0x50000a00: 00010000 --> UART4 is enable as explained in STM32MP15 reference manuals
- The post-obit monitoring commands can be used to set a register value:
(gdb) monitor mwb <phys_address> <value> [count] #Write byte(s) to target memory (gdb) monitor mwh <phys_address> <value> [count] #Write 16-scrap one-half-word(s) to target memory (gdb) monitor mww <phys_address> <value> [count] #Write 32-bit word(s) to target retentiveness
- For instance: Write RCC_MP_APB1ENCLRR annals on STM32MP1 to articulate the UART4 RCC of APB1 peripheral, then reenable information technology:
(gdb) monitor mww phys 0x50000a04 0x00010000 #full 32bits value given # You can and then check that UART4 is disable by reading the RCC_MP_APB1ENSETR register: (gdb) monitor mdw phys 0x50000a00 0x50000a00: 00000000 # You can also cheque that the console is disabled by going on running the GDB (gdb) c # When the GBD has stopped running, you can re-enable UART4 RCC: (gdb) monitor mww phys 0x50000a00 0x00010000
5.2.half-dozen.2 Using CMSIS-SVD surround [edit]
The CMSIS-SVD surroundings is useful to become detailed data on registers, such as name and bit descriptions.
It is based on python scripts and svd files which contain the description of all registers.
Refer to CMSIS-SVD surround and scripts for more details.
5.three Debug Cortex-M4 firmware with GDB [edit]
The Arm Cortex-M4 cadre firmware can also be debugged using the GDB in command line (without IDE).
Either engineering kick mode and production boot mode are supported.
Please refer to the Hardware Description (Category:STM32 MPU boards) of your board for information on the Boot mode selection switch.
5.3.1 Debug Cortex-M4 firmware in engineering science boot mode [edit]
As in previous chapter Running OpenOCD and GDB, both OpenOCD and GDB accept to be started on separate consoles.
OpenOCD has to be executed in the aforementioned way as in the mentionned chapter.
GDB, instead, has to be executed with a unlike command line, without the script just with the path of ELF file containing the firmware to be debugged:
# 2d console for starting the GDB PC $> source <Your_SDK_path> /surroundings-setup-cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi PC $> $GDB $HOME/path/to/file.elf
So, the post-obit commands has to be typed in the GDB console to start the execution of a firmware and halt it at the beginning of main():
(gdb) target extended-remote localhost:3334 (gdb) load (gdb) thbreak main (gdb) go along Once the execution halts at main(), GDB volition return the prompt allowing the debug of the firmware.
five.three.2 Debug Cortex-M4 firmware in production boot mode [edit]
In production style the firmware is started by Linux, independently from GDB. Nevertheless, GDB tin can set a breakpoint earlier the firmware is started by Linux; thus the firmware volition halt at the breakpoint, allowing GDB to debug the firmware.
Please check in Linux remoteproc framework overview how to start and stop a firmware using Linux remoteproc framework.
At first, verify that no firmware is running on Cortex-M4 or, eventually, end it.
And so, start OpenOCD and GDB as in previous chapter Debug Cortex-M4 firmware in technology boot way.
Type the following commands in the GDB panel:
(gdb) target extended-remote localhost:3334 (gdb) thbreak main (gdb) go along Finally, let Linux start the firmware. The firmware execution will halt at main() and GDB will return the prompt allowing the debug of the firmware.
| Warning |
| Use on GDB command line the exact aforementioned ELF file that is used by Linux to read and run the firmware. If the files are not the same, the symbols on GDB will non match the firmware in execution. |
5.4 Debug Linux awarding with gdbserver [edit]
v.4.1 Enable debug information [edit]
Once your plan is built using the sdk toolchain, make certain that the -m option is enabled to debug your plan and add the necessary debug information.
Notation: If an upshot occurs during debugging, you tin can also force gcc to "not optimize lawmaking" using the -O0 choice.
- Example of a simple examination program build:
PC $> $CC -g -o myappli myappli.c
- Example based on Hello Earth: refer to "hello world" user space case
Edit and update the makefile for the user infinite case:
... # Add / change option in CFLAGS if needed -# CFLAGS += <new option> + CFLAGS += -g ...
5.4.two Remote debugging using gdbserver [edit]
In this setup, an ethernet link must be set up between the host PC and the target board.
Once your programme is installed on the target (using ssh or copied from an SDcard), y'all tin can beginning debugging information technology.
- On target side: based on "Howdy world" user infinite example
Board $> cd /usr/local/bin Lath $> ls hello_world_example Board $> gdbserver host:1234 hello_world_example Process main created; pid = 11832 (this value depends on your target) Listening on port 1234
- Your target waits for remote PC connection, and so starts debugging.
- Launch the GDB command from your source file binder (easier source loading)
The SDK environment must exist installed.
PC $> cd <source file folder path> PC $> ls hello_world_example hello_world_example.c hello_world_example.o kernel_install_dir Makefile PC $> source <Your_SDK_path> /environment-setup-cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi PC $> $GDB GNU gdb (GDB) X.Y.Z ... This GDB was configured every bit "--host=x86_64-ostl_sdk-linux --target=arm-ostl-linux-gnueabi". ... (gdb)
- Connect to the target and load the source file:
(gdb) target remote <IP_Addr_of_Board> :1234 Remote debugging using <IP_Addr_of_Board>:1234 Reading /home/root/examination from remote target... ... (gdb) break xvi (line number in the source file) (gdb) go on - The target program breaks on the breakpoint. Proceed until the end of the plan:
(gdb) keep Continuing. [Junior i (process 16204) exited normally] (gdb) quit
five.v User interface application [edit]
5.5.1 Text user interface (TUI) way [edit]
This user interface way is the first footstep before using the graphical UI as GDBGUI or DDD.
The TUI can be very useful to map source code with teaching.
Please go through the online documentation [two] [3].
5.v.2 Debugging with GDBGUI [edit]
Please refer to the dedicated gdbgui article.
5.5.3 Debugging with DDD [edit]
GNU DDD is a graphical forepart-end for command-line debuggers. Delight refer to defended spider web page for details[4].
v.5.4 Debugging with IDE [edit]
Please refer to STM32CubeIDE.
six To get further [edit]
6.1 Useful GDB commands [edit]
When using the GDB in command line way, it is important to know some basic GDB commands, such equally run software, set breakpoints, execute step past footstep, print variables and brandish information.
Please refer to GDB commands article.
six.2 Core dump assay using GDB [edit]
The core dump generated for an application crash can exist analysed by using the GDB.
Developer Package components, such every bit SDK and symbol files, must installed. Please refer to STM32MP1 Programmer Bundle.
The symbol file containing the debug symbol of the application in which the crash occurred must also be bachelor.
- First enable the SDK environment:
PC $> source <Your_SDK_path> /environment-setup-cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi - Then play the core dump with GDB:
PC $> $GDB <path_to_the_binary> <path_to_the_core_dump_file> 6.3 Tips [edit]
- Managing multiple debug setups
To manage multiple debug setups for different software versions, create different Path_env.py files with dissimilar names, and phone call the expected file in the Setup.gdb file:
... #################################################################### # Set up surround configuration #Path_env.py source Path_env_dk2_18_12_14.py #################################################################### ...
vii References [edit]
- ↑ 1.0 1.i https://www.gnu.org/software/gdb
- ↑ https://sourceware.org/gdb/onlinedocs/gdb/TUI.html#TUI
- ↑ https://ftp.gnu.org/sometime-gnu/Manuals/gdb/html_chapter/gdb_19.html
- ↑ https://world wide web.gnu.org/software/ddd
- Useful external links
| Document link | Document Type | Description |
|---|---|---|
| Using kgdb, kdb and the kernel debugger internals | User Guide | KGDB documentation guide |
| Welcome to the GDB Wiki | User guide | GDB Wiki |
| Building GDB and GDBserver for cross debugging | User Guide | Explicate how to build gdb for target and host |
| A GDB Tutorial with Examples | Training | Debugging a simple awarding |
Source: https://wiki.st.com/stm32mpu/wiki/GDB
0 Response to "How to Read Register Values Directly Openocd"
Post a Comment