Registered User |
Registered User |
Line 1: |
Line 1: |
| | <noinclude>{{ApplicableFor |
| | |MPUs list=STM32MP13x,STM32MP15x |
| | |MPUs checklist=STM32MP13x, STM32MP15x, STM32MP25x |
| | }}</noinclude> |
| | |
| ==Article purpose== | | ==Article purpose== |
| This article provides the basic information needed to start using the '''GDB'''<ref name=gdbgnudotorg/> application tool.
| | The purpose of this article is to: |
| | | * briefly introduce the DFSDM peripheral and its main features, |
| It explains how to use this GNU debugger tool connected to your ST board target via Ethernet or via [[ST-LINK]], and how to perform cross-debugging (IDE, gdb viewer tool or command line) on Arm<sup>®</sup> Cortex<sup>®</sup>-A7 side for Linux<sup>®</sup> application, Linux<sup>®</sup> kernel (including external modules), or Arm<sup>®</sup> Cortext<sup>®</sup>-M4 firmware.
| | * indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts), |
| | | * list the software frameworks and drivers managing the peripheral, |
| == Introduction ==
| | * explain how to configure the peripheral. |
| {{:Trace_and_debug_tools_assignment_table_template}}
| |
| <onlyinclude>
| |
| | rowspan="2" | [[GDB]]
| |
| | rowspan="2" | [[:Category:Debugging tools|Debugging tools]]
| |
| | rowspan="2" style="text-align:left;" | The GNU Project debugger, '''GDB'''<ref name=gdbgnudotorg>https://www.gnu.org/software/gdb</ref>, allows monitoring program execution, or what the program was doing at the moment it crashed.<br>
| |
| | {{N}}* || {{Y}} || {{N}}**
| |
| | {{N}} || {{N}} || {{Y}}**
| |
| |-
| |
| | colspan="3" style="text-align:left;font-size:70%;" | * ''Cross compile gdb and openocd binaries are required and only available from Developer Package.''<br>** ''It is recommended to use the Developer Package to run the gdb debug session, which provided all dependencies''
| |
| | colspan="3" style="text-align:left;font-size:70%;" | * ''Cross compile gdb and openocd binaries are required and only available from Distribution Package.''
| |
| |-
| |
| </onlyinclude>
| |
| |}
| |
| | |
| The GDB can perform four main types of actions (plus other corollary actions) to help you detect bugs when running your software or application:
| |
| *Start the program, specifying anything that might affect its behaviour.
| |
| *Make the program stop on specific conditions. | |
| *Examine what happened when the program stopped.
| |
| *Update the program in order to test a bug correction, and jump to the next one.
| |
| | |
| == Overview of GDB setup for STM32MPU ==
| |
| === GDB setup paths ===
| |
| Two paths can be used in the STM32MPU environment for GDB setup:
| |
| * '''gdb ↔ gdbserver''' path through Ethernet, {{highlight|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]], {{highlight|used both for Cortex-M4 firmware and Cortex-A7 Linux kernel}}.
| |
| :In that case, only one software component is required on the host PC.
| |
| | |
| {{ImageMap|
| |
| Image:gdb_path_scheme.png {{!}} thumb{{!}} 500px {{!}} center {{!}} GDB paths scheme <br/> {{WarningImageMapOverlay}}
| |
| rect 230 15 315 40 [[Gdbgui|gdbgui]]
| |
| }}
| |
| | |
| Two components are included in OpenSTLinux Developer Package for GDB setup:
| |
| *'''gdbserver''': {{highlight|embedded on target rootfs}} and used as remote access for a host connection
| |
| *'''arm-openstlinux_weston-linux-gdb''': {{highlight|embedded on host PC side}}, cross-compiled gdb binary that manages the connexion between the host computer and the target board
| |
| | |
| === JTAG and SWD debug port ===
| |
| The STM32MPU features two debug ports through the embedded CoreSight™ component that implements an external access 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 resources#Reference manuals|STM32MP15 reference manuals]] for information related to JTAG and SWD.
| |
| | |
| == Installing the GDB tool ==
| |
| This tool is made of two parts, one on the host PC, and a second on the target (only for debugging Linux applications).
| |
| === Installing the GDB tool on your host PC ===
| |
| Below is the list of required components:
| |
| * The cross-compiled GDB binary | |
| * The OpenOCD binary and configuration files
| |
| * The symbols files of all BSP components (TF-A, U-Boot and Linux kernel), corresponding to the images of the OpenSTLinux Starter Package.
| |
| | |
| ==== Using the STM32MPU Embedded Software distribution ====
| |
| ===== Developer Package =====
| |
| Only the Developer Package can be used, since it is the only one which provides all the required components.
| |
| | |
| ==== Using the STM32MPU Embedded Software distribution for Android™ ====
| |
| =====Distribution Package=====
| |
| Only Distribution Package can be used, since it is the only one which provides all the required components.
| |
| | |
| === Installing the GDB on your target board ===
| |
| On the target board, only the gdbserver binary is required for debugging Linux applications.
| |
|
| |
|
| It is available by default within the Starter Package, which provides images linked to the Developer Package. | | ==Peripheral overview== |
| {{Android|Also the case for Starter Package for Android™}}
| | The '''DFSDM''' (Digital Filter for Sigma-Delta Modulator) peripheral is used as a generic ADC. It benefits from external analog frontend interfaces and internal digital filters.<br /> |
| | It can be used in various applications<ref name="DFSDM training">[https://st-onlinetraining.s3.amazonaws.com/STM32L4_System_Digital_Filter_for_SD_Modulators_interface_(DFSDM)/index.html STM32L4 System Digital Filter for SD Modulators interface], online DFSDM training from STMicroelectronics</ref> such as: '''audio record''' with MEMS microphones, '''energy measurement''' with STPMS2<ref name="STPMS2">[https://www.st.com/en/data-converters/stpms2.html STPMS2] "Smart sensor" device</ref> for electricity meters or motor control... |
|
| |
|
| == Getting started ==
| | The '''DFSDM''' peripheral provides several features, among which: |
| This chapter describes the two 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.
| | * Serial or parallel input '''channels''': |
| | ** External analog frontend serial interfaces (SPI, manchester coded single wire interface, clock output), for various sigma-delta modulators |
| | ** Alternative Internal digital parallel interfaces (from internal ADC<ref name="ADC internal peripheral">[[ADC internal peripheral]]</ref> or memory data stream via DMA<ref name="DMA internal peripheral">[[DMA internal peripheral]]</ref> or CPU) |
| | * Digital '''filters''', that offers up to 24-bit final ADC resolution |
| | * Conversions that can be launched continuously, or using various triggers: by software, TIM<ref name="TIM internal peripheral">[[TIM internal peripheral]]</ref>, LPTIM<ref name="LPTIM internal peripheral">[[LPTIM internal peripheral]]</ref>, EXTI<ref name="EXTI internal peripheral">[[EXTI internal peripheral]]</ref> or synchronously with DFSDM filter 0 |
| | * Event detectors: analog watchdog high/low thresholds, short-circuit detector, extremes detector |
| | * Break generation to TIM<ref name="TIM internal peripheral"/> on analog watchdog or short-circuit detector events |
|
| |
|
| === Prerequisites === | | {| class="st-table" style="width: 100%;" |
| The target board is up and running.
| | |- style="background: {{STLightGrey}};" |
| | | ! style="width:40%; | DFSDM features |
| === Debug OpenSTLinux BSP components ===
| | ! style="width:20%; | Number of channels |
| | | ! style="width:20%;" | Number of filters |
| ==== Setting up GDB / OpenOCD debug path environment ====
| |
| * '''Architecture'''
| |
| The figure below shows the architecture corresponding to the GDB/OpenOCD connected to Cortex-A7 and Cortex-M4 cores.<br>
| |
| ''Note: The [[ST-LINK]] probes available on the STM32MP1 board can be used through a USB interface, as well as any other external probes through the Trace or JTag connector''.
| |
| [[File:GDB_openOCD_focus_graph.png|700px|center|link=]]
| |
| * '''Prerequisites'''
| |
| :The Developer Package must be 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]]). | |
| :{{Android|The Distribution Package must be installed:
| |
| :* to get the debug symbol files for TF-A and U-Boot.
| |
| :* to get the source files for [[How_to_build_bootloaders_for_Android#Load_the_bootloader_sources|TF-A, U-Boot]] and [[How_to_build_kernel_for_Android#Load_the_kernel_sources|Linux kernel]]
| |
| :* to generate the symbol file for Linux kernel ({{Highlight|'''vmlinux file not present by default'''}}): please refer to article [[How_to_build_kernel_for_Android]] | |
| }} | |
| :The debug symbol files contain the symbols for the TF-A, U-Boot and Linux kernel binaries (from the Starter Package image) that have been flashed on the board. | |
| | |
| * '''Environment configuration files'''
| |
| :To speed up environment setup for debugging with GDB, download two configuration files, and install them on your PC (''under the home directory: $HOME/gdbscripts/''). You can then {{highlight|'''customize'''}} them:
| |
| ::- [[media:Setup.gdb.txt|Setup.gdb]]: main configuration file in which you can define the debug context you want to use (Refer to [[Boot chains overview]] for details). Possible combinations are: | |
| ::* Trusted boot chain: | |
| ::{|
| |
| |- | | |- |
| ! Debug mode
| | | {{MicroprocessorDevice | device=13}} |
| ! style="text-align: center;" width="150" | (1)<br/>Cortex-A7<br/>TF-A(BL2)
| | | 4 |
| ! style="text-align: center;" width="150" | (2)<br/>Cortex-A7<br/>TF-A(BL32)
| | | 2 |
| ! style="text-align: center;" width="150" | (3)<br/>Cortex-A7<br/>SSBL(U-Boot)
| |
| ! style="text-align: center;" width="150" | (4)<br/>Cortext-A7<br/>Linux kernel
| |
| |- | | |- |
| | (0) - Boot
| | | {{MicroprocessorDevice | device=15}} |
| | style="text-align: center;" | {{Y}}
| | | 8 |
| | style="text-align: center;" | {{Y}} | | | 6 |
| | style="text-align: center;" | {{Y}} | |
| | style="text-align: center;" | {{Y}} | |
| |- | | |- |
| | (1) - Running target
| |
| | style="text-align: center;" | {{N}}
| |
| | style="text-align: center;" | {{N}}
| |
| | style="text-align: center;" | {{Y}}
| |
| | style="text-align: center;" | {{Y}}
| |
| |} | | |} |
|
| |
|
| ::* Trusted boot chain with OP-TEE:
| | Refer to the [[STM32 MPU resources#Reference manuals|STM32 MPU reference manuals]] for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented. |
| ::{|
| |
| |-
| |
| ! Debug mode
| |
| ! style="text-align: center;" width="150" | (1)<br/>Cortex-A7<br/>TF-A(BL2)
| |
| ! style="text-align: center;" width="150" | (2)<br/>Cortex-A7<br/>OP-TEE
| |
| ! style="text-align: center;" width="150" | (3)<br/>Cortex-A7<br/>SSBL(U-Boot)
| |
| ! style="text-align: center;" width="150" | (4)<br/>Cortext-A7<br/>Linux kernel
| |
| |-
| |
| | (0) - Boot
| |
| | style="text-align: center;" | {{Y}}
| |
| | style="text-align: center;" | {{Y}}
| |
| | style="text-align: center;" | {{Y}}
| |
| | style="text-align: center;" | {{Y}}
| |
| |-
| |
| | (1) - Running target
| |
| | style="text-align: center;" | {{N}}
| |
| | style="text-align: center;" | {{N}}
| |
| | style="text-align: center;" | {{Y}}
| |
| | style="text-align: center;" | {{Y}}
| |
| |}
| |
|
| |
|
| ::- [[media:Path_env.gdb.txt|Path_env.gdb]]: customization file to define all the paths to source and symbol files, which can either be directly retrieved from the '''Developer Package''' (refer to the [[Example of directory structure for Packages]]), or result from a new compilation. {{highlight|'''In both cases, update the paths corresponding to your environment. <br>Please read carefully the comments provided in this file to help you updating source and symbol paths'''}}.
| | ==Peripheral usage== |
| :Store these files locally on your host PC, {{highlight|'''check for name cast (Setup.gdb and Path_env.gdb)'''}} and update them accordingly.
| | This chapter is applicable in the scope of the '''OpenSTLinux BSP''' running on the Arm<sup>®</sup> Cortex<sup>®</sup>-A processor(s), and the '''STM32CubeMPU Package''' running on the Arm<sup>®</sup> Cortex<sup>®</sup>-M processor. |
|
| |
|
| ==== Configuring GDB and OpenOCD for attachment on a running target ==== | | ===Boot time assignment=== |
| When the target board is running, you can attach the GDB only during one of following phases:
| | The DFSDM peripheral is not used at boot time. |
| ===== U-Boot execution phase =====
| |
| 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
| |
| {{green|set $debug_phase}} = {{highlight|'''3'''}}
| |
|
| |
|
| # 0: Attach at boot
| | ===Runtime assignment=== |
| # 1: Attach running target
| | ====On {{MicroprocessorDevice | device=13}}==== |
| {{green|set $debug_mode}} = {{highlight|'''1'''}}
| | {{#lst:STM32MP1_internal_peripherals_assignment_table_template|stm32mp13_runtime}} |
| | | <section begin=stm32mp13_runtime /> |
| # Set debug trusted bootchain:
| | | rowspan="1" | Analog |
| # 0: TF-A BL2 / TF-A BL32 / U-Boot / Linux kernel
| | | rowspan="1" | [[DFSDM internal peripheral|DFSDM]] |
| # 1: TF-A BL2 / OP-TEE / U-Boot / Linux kernel
| | | DFSDM |
| {{green|set $debug_trusted_bootchain}} = {{green|'''0'''}} or {{green|'''1'''}} {{highlight|#depending on your software boot chain configuration}}
| | | |
| | | | <span title="assignable peripheral" style="font-size:21px">☐</span> |
| When the configuration is complete, jump to [[#Running OpenOCD and GDB|Running OpenOCD and GDB]].
| | | Assignment (single choice) |
| | | |- |
| ===== Linux kernel execution phase ===== | | <section end=stm32mp13_runtime /> |
| 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
| |
| {{green|set $debug_phase}} = {{highlight|'''4'''}}
| |
| | |
| # 0: Attach at boot
| |
| # 1: Attach running target
| |
| {{green|set $debug_mode}} = {{highlight|'''1'''}}
| |
| | |
| # 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
| |
| {{green|set $debug_trusted_bootchain}} = {{green|'''0'''}} or {{green|'''1'''}} {{highlight|#depending on your software boot chain configuration}}
| |
| | |
| When the configuration is complete, jump to [[#Running OpenOCD and GDB|Running OpenOCD and GDB]].
| |
| | |
| ==== Configuring GDB and OpenOCD for attachment on boot ==== | |
| You can attach the GDB during target boot only in the following cases:
| |
| {{Warning|In that case, the target board will automatically reboots when the GDB starts.}} | |
| | |
| ===== TF-A(BL2) boot case =====
| |
| In that case, the GDB breaks in bl2_entrypoint function.
| |
| | |
| 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
| |
| {{green|set $debug_phase}} = {{highlight|'''1'''}}
| |
| | |
| # 0: Attach at boot
| |
| # 1: Attach running target
| |
| {{green|set $debug_mode}} = {{highlight|'''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
| |
| {{green|set $debug_trusted_bootchain}} = {{green|'''0'''}} or {{green|'''1'''}} {{highlight|#depending on your software boot chain configuration}} | |
| | |
| When this operation is complete, jump to [[#Running OpenOCD and GDB|Running OpenOCD and GDB]].
| |
| | |
| ===== TF-A(BL32) boot case =====
| |
| In that case, the GDB breaks in sp_min_entrypoint function.
| |
| | |
| 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
| |
| {{green|set $debug_phase}} = {{highlight|'''2'''}}
| |
| | |
| # 0: Attach at boot
| |
| # 1: Attach running target
| |
| {{green|set $debug_mode}} = {{highlight|'''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
| |
| {{green|set $debug_trusted_bootchain}} = {{highlight|'''0'''}}
| |
| | |
| When this operation is complete, jump to [[#Running OpenOCD and GDB|Running OpenOCD and GDB]].
| |
| | |
| ===== OP-TEE boot case =====
| |
| In that case, the GDB breaks in _start function.
| |
| | |
| 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
| |
| {{green|set $debug_phase}} = {{highlight|'''2'''}} | |
| | |
| # 0: Attach at boot | |
| # 1: Attach running target
| |
| {{green|set $debug_mode}} = {{highlight|'''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
| |
| {{green|set $debug_trusted_bootchain}} = {{highlight|'''1'''}} | |
| | |
| When this operation is complete, jump to [[#Running OpenOCD and GDB|Running OpenOCD and GDB]].
| |
| | |
| ===== U-Boot boot case =====
| |
| In that case, the GDB breaks in in _start function.
| |
| | |
| 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
| |
| {{green|set $debug_phase}} = {{highlight|'''3'''}}
| |
| | |
| # 0: Attach at boot
| |
| # 1: Attach running target
| |
| {{green|set $debug_mode}} = {{highlight|'''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
| |
| {{green|set $debug_trusted_bootchain}} = {{green|'''0'''}} or {{green|'''1'''}} {{highlight|#depending on your software boot chain configuration}}
| |
| | |
| When this operation is complete, jump to [[#Running OpenOCD and GDB|Running OpenOCD and GDB]].
| |
| | |
| ===== Linux kernel boot case =====
| |
| In that case, the GDB breaks in stext function.
| |
| | |
| 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
| |
| {{green|set $debug_phase}} = {{highlight|'''4'''}}
| |
| | |
| # 0: Attach at boot
| |
| # 1: Attach running target
| |
| {{green|set $debug_mode}} = {{highlight|'''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
| |
| {{green|set $debug_trusted_bootchain}} = {{green|'''0'''}} or {{green|'''1'''}} {{highlight|#depending on your software boot chain configuration}}
| |
|
| |
|
| When this operation is complete, jump to [[#Running OpenOCD and GDB|Running OpenOCD and GDB]].
| | ====On {{MicroprocessorDevice | device=15}}==== |
| | | {{#lst:STM32MP1_internal_peripherals_assignment_table_template|stm32mp15_runtime}} |
| ==== Running OpenOCD and GDB ==== | | <section begin=stm32mp15_runtime /> |
| * Prerequisites
| | | rowspan="1" | Analog |
| Before running OpenOCD and GDB, check that the target board is in the right state.
| | | rowspan="1" | [[DFSDM internal peripheral|DFSDM]] |
| | | | DFSDM |
| For all configurations except GDB attachment to a running SSBL (U-Boot), the board has to operate in OpenSTLinux running mode.
| | | |
| | | | <span title="assignable peripheral" style="font-size:21px">☐</span> |
| In case of attachment to a running SSBL (U-Boot) configuration, the board target must be in U-Boot console mode:
| | | <span title="assignable peripheral" style="font-size:21px">☐</span> |
| #''Reboot the target board''
| | | Assignment (single choice) |
|
| | |- |
| #''Press any key to stop at U-Boot execution when booting the board''
| | <section end=stm32mp15_runtime /> |
| {{U-Boot$}} ...
| |
| {{U-Boot$}} Hit any key to stop autoboot: 0
| |
| {{U-Boot$}}
| |
| | |
| | |
| When you are in the expected configuration, two different consoles must be started: '''one for OpenOCD''' and '''one for GDB'''.<br>
| |
| {{highlight|The SDK environment must be installed on both console terminals.}}
| |
| | |
| * OpenOCD console
| |
| # First console for starting openocd with configuration file
| |
| {{PC$}} source {{HighlightParam|''<Your_SDK_path>''}}/environment-setup-cortexa7hf-neon-vfpv4-openstlinux_weston-linux-gnueabi
| |
| {{PC$}} $OECORE_NATIVE_SYSROOT/usr/bin/openocd -s $OECORE_NATIVE_SYSROOT/usr/share/openocd/scripts -f {{HighlightParam|''<board.cfg>''}}
| |
| {{Android|
| |
| # First console for starting openocd with configuration file
| |
| {{PC$}} cd {{HighlightParam|''<Your_Android_distribution_path>''}} | |
| {{PC$}} ./device/stm/stm32mp1-openocd/prebuilt/openocd -s ./device/stm/stm32mp1-openocd/prebuilt/scripts -f {{HighlightParam|''<board.cfg>''}}
| |
| }}
| |
| | |
| : Possible target configuration files for {{HighlightParam|''<board.cfg>''}}:
| |
| :{|
| |
| |-
| |
| ! Target board
| |
| ! style="text-align: center;" | Adapter
| |
| ! style="text-align: center;" | SWD mode board.cfg
| |
| ! style="text-align: center;" | JTAG mode board.cfg
| |
| |- | |
| | STM32MP157C-EV1 | |
| | ST-LINK * | |
| | style="text-align: center;" | board/stm32mp15x_ev1_stlink_swd.cfg | |
| | style="text-align: center;" | board/stm32mp15x_ev1_stlink_jtag.cfg
| |
| |- | |
| | STM32MP157C-EV1
| |
| | U-LINK2
| |
| | style="text-align: center;" | board/stm32mp15x_ev1_ulink2_swd.cfg
| |
| | style="text-align: center;" | board/stm32mp15x_ev1_ulink2_jtag.cfg
| |
| |- | |
| | STM32MP157C-EV1 | |
| | J-LINK
| |
| | style="text-align: center;" | board/stm32mp15x_ev1_jlink_swd.cfg
| |
| | style="text-align: center;" | board/stm32mp15x_ev1_jlink_jtag.cfg
| |
| |-
| |
| | STM32MP157X-DK2
| |
| | ST-LINK *
| |
| | style="text-align: center;" | board/stm32mp15x_dk2.cfg
| |
| | style="text-align: center;" | {{N}}**
| |
| |} | | |} |
| :''* Both v2 and v3 are supported.''<br>
| |
| :''** JTAG wires are not connected in DK2.''
| |
| :{{highlight|''Note: It is recommended to use SWD, which is faster than JTAG.''}}
| |
|
| |
| * GDB console
| |
| :{{Warning|The GDB must be executed from the directory where the scripts have been installed (i.e. $HOME/gdbscripts/)}}
| |
| # Second console for starting the GDB
| |
| {{PC$}} {{highlight|cd $HOME/gdbscripts/}}
| |
| {{PC$}} source {{HighlightParam|''<Your_SDK_path>''}}/environment-setup-cortexa7hf-neon-vfpv4-openstlinux_weston-linux-gnueabi
| |
| {{PC$}} $OECORE_NATIVE_SYSROOT/usr/bin/arm-openstlinux_weston-linux-gnueabi/arm-openstlinux_weston-linux-gnueabi-gdb -x={{highlight|$HOME/gdbscripts/Setup.gdb}}
| |
| {{Android|
| |
| {{highlight|Ensure the GCC toolchain is installed using ''bspsetup'' command in your Distribution Package}}
| |
| # Second console for starting the GDB
| |
| {{PC$}} {{highlight|cd $HOME/gdbscripts/}}
| |
| {{PC$}} {{HighlightParam|''<Your_Android_distribution_path>''}}/prebuilts/gcc/linux-x86/arm/{{HighlightParam|''<toolchain_version>''}}-x86_64-arm-eabi/bin/arm-eabi-gdb -x=$HOME/gdbscripts/Setup.gdb
| |
| }}
| |
|
| |
| ==== To know more about Linux kernel debug with GDB ====
| |
| Please refer to [[Debugging the Linux kernel using the GDB]].
| |
|
| |
| ==== Access to STM32MP registers ====
| |
| ===== Using gdb command line =====
| |
| - The following monitoring commands can be used to read a register value:
| |
| {{GDB$}} monitor mdb {{HighlightParam|''<phys_address>''}} [{{HighlightParam|count}}] ''#Display target memory as 8-bit bytes''
| |
| {{GDB$}} monitor mdh {{HighlightParam|''<phys_address>''}} [{{HighlightParam|count}}] ''#Display target memory as 16-bit bytes''
| |
| {{GDB$}} monitor mdw {{HighlightParam|''<phys_address>''}} [{{HighlightParam|count}}] ''#Display target memory as 32-bit bytes''
| |
| :For example: Read RCC_MP_APB1ENSETR register on STM32MP1 to check RCC APB1 peripheral enable status.
| |
| {{GDB$}} monitor {{highlight|mdw}} phys {{green|0x50000a00}} ''{{highlight|#full 32bits value result requested}}''
| |
| 0x50000a00: {{highlight|00010000}} --> UART4 is enable as explained in [[STM32MP15 resources#Reference manuals|STM32MP15 reference manuals]]
| |
|
| |
| - The following monitoring commands can be used to set a register value:
| |
| {{GDB$}} monitor mwb {{HighlightParam|''<phys_address>''}} {{HighlightParam|''<value>''}} [{{HighlightParam|count}}] ''#Write byte(s) to target memory''
| |
| {{GDB$}} monitor mwh {{HighlightParam|''<phys_address>''}} {{HighlightParam|''<value>''}} [{{HighlightParam|count}}] ''#Write 16-bit half-word(s) to target memory''
| |
| {{GDB$}} monitor mww {{HighlightParam|''<phys_address>''}} {{HighlightParam|''<value>''}} [{{HighlightParam|count}}] ''#Write 32-bit word(s) to target memory''
| |
| :For example: Write RCC_MP_APB1ENCLRR register on STM32MP1 to clear the UART4 RCC of APB1 peripheral, then reenable it:
| |
| {{GDB$}} monitor {{highlight|mww}} phys {{green|0x50000a04}} {{highlight|0x00010000}} ''{{highlight|#full 32bits value given}}''
| |
|
| |
| # You can then check that UART4 is disable by reading the RCC_MP_APB1ENSETR register:
| |
| {{GDB$}} monitor mdw phys {{green|0x50000a00}}
| |
| 0x50000a00: 00000000
| |
|
| |
| # You can also check 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 {{green|0x50000a00}} {{highlight|0x00010000}}
| |
|
| |
| ===== Using CMSIS-SVD environment =====
| |
| The CMSIS-SVD environment is useful to get detailed information 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 environment and scripts]] for more details.
| |
|
| |
| === Debug Cortex-M4 firmware with GDB ===
| |
| The Arm Cortex-M4 core firmware can also be debugged using the GDB in command line (without IDE).
| |
|
| |
| Two setups can be used:
| |
| * Engineering mode (only Cortex-M4 core running)
| |
| {{UnderConstruction}}
| |
| * Production mode (both Cortex-M4 and Cortex-A7 cores running)
| |
| {{UnderConstruction}}
| |
|
| |
| === Debug Linux application with gdbserver===
| |
|
| |
| ==== Enable debug information ====
| |
| Once your program is built using the sdk toolchain, make sure that the '''-g''' option is enabled to debug your program and add the necessary debug information.
| |
|
| |
| ''Note: If an issue occurs during debugging, you can also force gcc to "not optimize code" using the '''-O0''' option.''
| |
|
| |
| *Example of a simple test program build:
| |
| {{PC$}} $CC '''-g''' -o myappli myappli.c
| |
|
| |
| *Example based on Hello World: refer to [[How to cross-compile with the Developer Package#Adding_a_"hello_world"_user_space_example|"hello world" user space example]]
| |
|
| |
| Edit and update the makefile for the user space example:
| |
| ...
| |
| # Add / change option in CFLAGS if needed
| |
| -# CFLAGS += <new option>
| |
| + '''CFLAGS += -g'''
| |
| ...
| |
|
| |
| ==== Remote debugging using gdbserver ====
| |
| In this setup, an {{highlight|ethernet link must be set between the host PC and the target board}}.
| |
|
| |
| Once your program is installed on the target (using ssh or copied from an SDcard), you can start debugging it.
| |
|
| |
| *On target side: based on "Hello world" user space example
| |
| {{Board$}} cd /usr/local/bin
| |
| {{Board$}} 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 then starts debugging.
| |
|
| |
| *Launch the GDB command from your source file folder (easier source loading)
| |
| {{highlight|The SDK environment must be installed.}}
| |
| {{PC$}} cd {{HighlightParam|''<source file folder path>''}}
| |
| {{PC$}} ls
| |
| hello_world_example hello_world_example.c hello_world_example.o kernel_install_dir Makefile
| |
| {{PC$}} source {{HighlightParam|''<Your_SDK_path>''}}/environment-setup-cortexa7hf-neon-vfpv4-openstlinux_weston-linux-gnueabi
| |
| {{PC$}} $OECORE_NATIVE_SYSROOT/usr/bin/arm-openstlinux_weston-linux-gnueabi/arm-openstlinux_weston-linux-gnueabi-gdb
| |
| GNU gdb (GDB) X.Y.Z
| |
| ...
| |
| This GDB was configured as "--host=x86_64-openstlinux_weston_sdk-linux --target=arm-openstlinux_weston-linux-gnueabi".
| |
| ...
| |
| {{GDB$}}
| |
|
| |
| *Connect to the target and load the source file:
| |
| {{GDB$}} target remote {{HighlightParam|''<IP_Addr_of_Board>''}}:1234
| |
| Remote debugging using <IP_Addr_of_Board>:1234
| |
| Reading /home/root/test from remote target...
| |
| ...
| |
| {{GDB$}} break 16 (''line number in the source file'')
| |
| {{GDB$}} continue
| |
| *The target program breaks on the breakpoint. Proceed until the end of the program:
| |
| {{GDB$}} continue
| |
| Continuing.
| |
| [Inferior 1 (process 16204) exited normally]
| |
| {{GDB$}} quit
| |
|
| |
| === User interface application ===
| |
| ==== Text user interface (TUI) mode ====
| |
| This user interface mode is the first step before using the graphical UI as GDBGUI or DDD.
| |
|
| |
| The TUI can be very useful to map source code with instruction.
| |
|
| |
| Please go through the online documentation <ref>https://sourceware.org/gdb/onlinedocs/gdb/TUI.html#TUI</ref> <ref>https://ftp.gnu.org/old-gnu/Manuals/gdb/html_chapter/gdb_19.html</ref>.
| |
|
| |
| ==== Debugging with GDBGUI ====
| |
| Please refer to the dedicated [[Gdbgui|gdbgui]] article.
| |
|
| |
| ==== Debugging with DDD ====
| |
| GNU DDD is a graphical front-end for command-line debuggers. Please refer to dedicated web page for details<ref>https://www.gnu.org/software/ddd</ref>.
| |
|
| |
| ==== Debugging with IDE ====
| |
| Please refer to [[STM32-CoPro-MPU plugin for SW4STM32]].
| |
|
| |
|
| == To go further == | | ==Software frameworks and drivers== |
| === Useful GDB commands ===
| | Below are listed the software frameworks and drivers managing the DFSDM peripheral for the embedded software components listed in the above tables. |
| When using the GDB in command line mode, it is important to know some basic GDB commands, such as run software, set breakpoints, execute step by step, print variables and display information.
| |
|
| |
|
| Please refer to [[GDB commands]] article.
| | * '''Linux<sup>®</sup>''': [[IIO overview|IIO framework]] or [[ALSA overview|ALSA framework]] |
| | * '''STM32Cube''': {{CodeSource | STM32CubeMP1 | Drivers/STM32MP1xx_HAL_Driver/Src/stm32mp1xx_hal_dfsdm.c | HAL DFSDM driver}} |
|
| |
|
| === Core dump analysis using GDB === | | ==How to assign and configure the peripheral== |
| The [[Core dump|core dump]] generated for an application crash can be analysed by using the GDB. | | The peripheral assignment can be done via the [[STM32CubeMX]] graphical tool (and manually completed if needed).<br /> |
| | This tool also helps to configure the peripheral: |
| | * partial device trees (pin control and clock tree) generation for the OpenSTLinux software components, |
| | * HAL initialization code generation for the STM32CubeMPU Package. |
| | The configuration is applied by the firmware running in the context in which the peripheral is assigned. |
|
| |
|
| Developer Package components, such as SDK and symbol files, must installed. Please refer to [[STM32MP1 Developer Package]].
| | For the Linux kernel configuration, please refer to [[DFSDM device tree configuration]] and [[DFSDM Linux driver]] articles. |
|
| |
|
| The symbol file containing the debug symbol of the application in which the crash occurred must also be available.
| | ==How to go further== |
| | See: |
| | * ''STM32L4 System Digital Filter for SD Modulators interface''<ref name="DFSDM training"/>, online DFSDM training with application examples from STMicroelectronics |
|
| |
|
| * First enable the SDK environment: | | * ''Getting started with sigma-delta digital interface''<ref>[https://www.st.com/content/ccc/resource/technical/document/application_note/group0/b2/44/42/9d/46/b4/4d/34/DM00354333/files/DM00354333.pdf/jcr:content/translations/en.DM00354333.pdf Getting started with sigma-delta digital interface], application note from STMicroelectronics</ref>, application note from STMicroelectronics |
| {{PC$}} source {{HighlightParam|''<Your_SDK_path>''}}/environment-setup-cortexa7hf-neon-vfpv4-openstlinux_weston-linux-gnueabi
| |
| | |
| * Then play the core dump with GDB:
| |
| {{PC$}} $OECORE_NATIVE_SYSROOT/usr/bin/arm-openstlinux_weston-linux-gnueabi/arm-openstlinux_weston-linux-gnueabi-gdb {{HighlightParam|''<path_to_the_binary> <path_to_the_core_dump_file>''}}
| |
| | |
| === Tips ===
| |
| * Managing multiple debug setups
| |
| To manage multiple debug setups for different software versions, create different Path_env.gdb files with different names, and call the expected file in the Setup.gdb file:
| |
| | |
| ...
| |
| ####################################################################
| |
|
| |
| # Set environment configuration
| |
| #Path_env.gdb
| |
| source Path_env_dk2_18_12_14.gdb
| |
|
| |
| ####################################################################
| |
| ...
| |
| | |
| == References ==
| |
| <references />
| |
| | |
| * Useful external links
| |
| {|
| |
| ! scope=col | Document link
| |
| ! scope=col | Document Type
| |
| ! scope=col | Description
| |
| |-
| |
| | [https://www.kernel.org/pub/linux/kernel/people/jwessel/kdb/ Using kgdb, kdb and the kernel debugger internals]
| |
| | | User Guide
| |
| | | KGDB documentation guide
| |
| |-
| |
| | [https://sourceware.org/gdb/wiki/ Welcome to the GDB Wiki]
| |
| | | User guide
| |
| | | GDB Wiki
| |
| |-
| |
| | [https://sourceware.org/gdb/wiki/BuildingCrossGDBandGDBserver Building GDB and GDBserver for cross debugging]
| |
| | | User Guide
| |
| | | Explain how to build gdb for target and host
| |
| |-
| |
| | [http://www.cprogramming.com/gdb.html A GDB Tutorial with Examples]
| |
| | | Training
| |
| | | Debugging a simple application
| |
| |}
| |
|
| |
|
| {{ ArticleBasedOnModel | Trace and debug tools article model }}
| | ==References== |
| {{ PublicationRequestId | 10264 | 15Jan'19 }}
| | <references/> |
|
| |
|
| [[Category:Debugging tools]] | | <noinclude> |
| [[Category:Android]] | | [[Category:Analog peripherals]] |
| | [[Category:Audio peripherals]] |
| | {{ArticleBasedOnModel| Internal peripheral article model}} |
| | {{PublicationRequestId | 8311 | 2018-08-07 | AlainF}} |
| | </noinclude> |