 Welcome to this training, describing trace and debug solutions on the STM32-MP1 platform. This slide set covers only the Cortex-A7 part running Linux kernel. The Cortex-M4 part running CUBE software is presented in another module, STM32-MP1 Software Co-Processor Management. The STM32-MP1 platform offers various trace and debug paths and solutions, depending on the part to focus on. Both hardware and software interfaces are proposed on STM32-MP1 platforms. The hardware path enables hardware signals for debugging ARM cores, Cortex-A7 and or Cortex-M4, or for watching internal signals between peripherals by using the hardware debug port or HDP. Be careful, these interfaces are not present by default on all boards. For example, only the JTAG port is available on disco board. The software path allows the benefits of the Linux trace and debug environment and tools suite. Some of the tools are embedded in the Linux kernel. For example, Strace, Perf, Ftrace, Kmemleak, not necessarily enabled by default. Some others, interfacing at user space level, can be integrated from outside. For a debug path, ARM also introduces notions of invasive and non-invasive debug modes. Non-invasive debug environment reads or collects information without at all modifying the behavior of the system. It means that it does not impact the system setup and execution. On the contrary, in the invasive debug environment, the system behavior is impacted. This impact can be important, and this has to be known and taken into account by the user when setting up the system. This scheme is a representation of the trace and debug environment on STM32MP1 microprocessors, showing the different hardware and software paths which interface with the cores and hardware peripherals on the target side. The host side represents a different group of tools to interface with the user, and is able to manage and or display the trace and debug data. We can mention here that this is a general trace and debug setup view. Some external target interfaces may not necessarily be present on all boards. As an example, trace and IO probe interface are not present on the disco board. This scheme is a hardware and software block representation, which allows a parallel with the detailed debug block diagram available in the STM32MP1 reference manual. It highlights the main ARM core site block IP, which is embedded in the STM32MP1 chip. Now let's look at basic embedded kernel observations illustrated by an example around UART configuration. Kernel observation is the first step before using any other debug method. Linux kernel is using a circular log buffer to store information coming from core components or drivers. PrintK is a basic function used to store some messages in this buffer. The simple way to read the content of this buffer is to use the dmesg command. Note that all log messages are classified in different log levels, from 0 to 7. This classification enables the filtering of those messages when reading them. Please remember that the Linux kernel is a file system-oriented operating system. This means that all information about current configurations, running processes, and applications are stored as files, which can be accessible and read by trace and debug tools. In this file system, you can get a status about STM32MP1 hardware register settings, which is key to manage the system configuration and monitor the system behavior. DebugFS is also an important mounted point on the file system, which provides more debug information. We will see some usage examples during this training. This scheme is an extract from the trace and debug architecture scheme. It focuses on the Linux kernel observation path and summarizes the information given in the previous slide. To put into practice embedded kernel observations detailed in the previous slides of this presentation, you can refer to the Wiki article, trace and debug scenario, UART embedded kernel observations. As prerequisites, it is recommended to get the reference manual and the data sheet of the STM32MP1 shift and also the hardware schematics of your board. The above listed documents enable you to have a full description and configuration information about every hardware-related register and know the exact hardware configuration settings. Here is some information about trace and debug tools by giving an overview about the solutions available on the STM32MP1 microprocessor and by continuing the example on the UART issue to illustrate. Linux kernel embeds a set of tools for deeper kernel observations. The Linux community also proposes some tools, mainly at user space level, which can get multiple information from the file system and especially from the debug FS. The Linux Tracing Monitoring and Debugging Wiki page is a good entry point about trace and debug solutions for Linux kernel ported on STM32MP1. Three main axes are proposed to get started with tracing and monitoring setup. Some tools present by default on OpenST Linux distribution which provide useful information. Details for those tools are described in the corresponding Wiki article. Here we highlight two main trace and debug features embedded with the Linux kernel and so present on OpenST Linux. Dynamic Debug, which is an important tracing feature, it triggers trace on demand to not overload the trace buffer. Those traces are present on the source code with specific syntax, devdbg or prdebug. A corresponding Wiki article is available. The Linux kernel tracing feature is also a powerful trace environment, which provides information about Linux kernel code execution. It can be used to trace function calls to make performance analysis. Please note that this tracing feature is not enabled by default, as it is intrusive in code execution. All details are given in the FTrace tool Wiki article. This scheme is a block view representation of the Linux kernel tracing and monitoring links, including some tools available at user space level. To put into practice trace and debug tools information detailed in previous slides of this presentation, you can refer to the Wiki article Trace and Debug Scenario UART Trace and Debug Tools. The following prerequisites are recommended. STM32MPU Embedded Software Packages available, Developer Package or Distribution Package, to be able to modify the kernel configuration options and recompile the kernel image, and Linux kernel source code in order to be able to check for the debug traces available for a given driver. Let's see some advanced trace and debug tools which take advantage of hardware traces and active debugging directly on code execution on cores. Depending on the STM32MP1 board you are using, you can access fully or partially some hardware debug ports for getting traces or signals. Three main hardware debug ports are proposed and could be available on board. JTAG and Serial Wire port or SWD through hardware probes such as STLink or through the JTAG connector. This helps drive the software execution and access memory, read and or write. Hardware trace connector which can provide ARM core site signals also linked to software execution on cores. And hardware debug port or HDP which allows the observation of internal signals. This is an internal peripheral configured by a Linux kernel driver and for which output signals are mapped on GPIO. An important usage of this debug port is the possibility to do active debug directly on the source code running. It is possible to manage software execution by adding breakpoints, performing step by step execution, tracing variables, etc. For this environment use the STLink probe to connect the target to the host PC and as debug tool use the GDB debugger interface linked to OpenOCD interface which enables the control of the JTAG SWD port. For more detail you can refer to the GDB wiki page. Here you can find a representation of the hardware debug configurations detailed in the previous slide. To put into practice advanced trace and debug tools information detailed in previous slides of this presentation you can refer to the wiki article trace and debug scenario UART control execution of code with GDB. The following prerequisites are recommended. STM32MPU embedded software developer package available for GDB and OpenOCD environment. The STM32MP1 user guide provides useful wiki articles to support developers on several aspects. How to use the platform and how to trace, monitor and debug the platform. To go further on trace and debug solutions for STM32MP1 simply go to wiki.st.com search STM32MPU and search for the articles listed in this presentation. Thank you.