STM32MP1 Platform trace and debug environment overview for Android

Revision as of 15:31, 4 September 2019 by Registered User

The block diagram below shows the STM32MP1 Platform trace and debug environment for Android components and their possible interfaces:

  • The STM32MPU Embedded Software package (see STM32MPU Embedded Software for Android architecture overview) that includes:
    • The STM32MPU distribution for Android™, running on the Arm® Cortex®-A, including:
      • The OpenSTLinux BSP with:
        • The boot chain based on TF-A and U-Boot.
        • The OP-TEE secure OS running on the Arm® Cortex®-A in secure mode.
        • The Linux® kernel running on the Arm® Cortex®-A in non-secure mode.
      • The application frameworks are composed of middlewares relying on the BSP and providing API:
        • on the OP-TEE side to run Trusted Applications (TA) that allow to manipulate secrets (not visible from the Linux and STM32Cube MPU Package)
        • on the Android side to run Applications that typically interact with the user via the display, the touchscreen, etc.
    • The STM32Cube MPU Package is running on the Arm® Cortex®-M: it is based on HAL drivers and middlewares, like other STM32 microcontrollers, completed with coprocessor management.

The figure below is clickable so that the user can directly jump to one of the sub-levels listed above.

  • The STM32MPU peripherals shared between Cortex®-A and Cortex®-M cores (such as GPIO, I2C and SPI)
  • The user interfaces or tools, which allow to interact with different trace and debug Tools, such as:
    • The remote shell using terminal console
    • The Android host tools (such as Android Studio)
    • The debugger tools (such as GDB)
    • The graphical IDE (such as GDBGUI or SystemWorkbench)
  • The trace and debug interfaces or hardware paths that provide access to trace and debug components through:
    • The network interface (e.g. Ethernet)
    • The communication port (e.g UART)
    • The hardware connector interfaces:
      • JTag port
      • Trace port to access ETM, STM, ITM and SWD
      • I/O probes to access HDP
  • The hardware probes such as ST-Link.


This block diagram also illustrates the Arm® debugging modes:

  • Invasive debug: debug process that allows the control and monitoring of the processor. Most debug features are considered invasive because they enable you to halt the processor and modify its state.
  • Non-invasive debug: debug process that allows the monitoring of the processor but not the control. The embedded trace macrocell (ETM) interface and the performance monitor registers are non-invasive debug features.


Click the figure below to directly jump to the component you want to trace, monitor or debug:

  • By selecting a hardware component, you will be redirected to the corresponding hardware board article in order to check if the hardware connector is supported on your board.
  • By selecting a target software component, you will be be redirected to an article that explains in details how to trace, monitor or debug this component.
  • By selecting a host software component, you will be redirected to an article that explains how to use this remote tool.


Error: Image is invalid or non-existent.

STM32MP1 Platform trace and debug environment overview legend.png