This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[FAQ]:Migration Tips for Developers Transitioning to MPU Devices from Old Microcontroller.

Part Number: AM6442
Other Parts Discussed in Thread: AM62P

Tool/software:

With this FAQ, developers can ensure a smoother, faster transition to Sitara MPU devices (AM64x,AM243,AM62x,AM62A,AM62P and AM62D)  and maximizing the benefits of the new architecture while minimizing potential challenges during migration.

This document provides insights for developers transitioning from older Microcontrollers to Sitara MPUs. It enables them to:

  1. Developers can easily identify peripheral and architectural differences which are crucial for migration.

  2. Developers can address all necessary changes in peripheral usage and system Architecture in the design phases, which helps to speed up development process and reduces bugs in the production stage.

  • Reset, Clock, Resource Allocation, and Security Management :

    Traditional Microcontroller: In traditional microcontroller, clock and reset operations are integrated within a single core, providing direct control over registers. However, these systems typically lack advanced features for security and resource allocation.

    Sitara MPU: In contrast, the Sitara MPU centralizes clocks and resets functions through a dedicated core known as the DMSC (Device Management and Security Controller). Users interact with the DMSC core by sending specific requests for operations with the SCI API's, facilitated by Inter-Processor Communication (IPC). This architecture allows the DMSC to function as a black box.

    Sitara devices are multicore processors . So, interrupts are routed to different cores.

    This interrupt routing configuration can be decided by the user for which core wants to route. This process is called resource allocation.

    And, Sitara devices support different security features as well.

    Link : 

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/RESOURCE_ALLOCATION_GUIDE.html

    Boot Flow : 

    Traditional Microcontroller: Upon reset, traditional microcontrollers initiate a boot process from a fixed ROM bootloader, leading directly to application execution from flash.

    Sitara MPU: The boot process in Sitara MPUs begins with the ROM Boot Loader (RBL), followed by the Secondary Boot Loader (SBL), which loads application images from external nonvolatile memory into internal RAM (IRAM, MSRAM, and DDR). Next, the application execution starts from RAM's .

    While users cannot modify the RBL, the SBL is customizable, allowing for different application needs.

     Link : 

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/BOOTFLOW_GUIDE.html

  • Interrupt Configuration : 

    Traditional Microcontroller: Enabling interrupts requires setting specific bits in the IP level, then the peripheral interrupts routed to the destination cores.

    Sitara MPU: Users must configure interrupts enablement  on both the IP and VIM (Vector Interrupt Manager) sides.

    GPIO Interrupt Configuration : 

    Traditional microcontroller: All GPIO pin interrupts are routed to the destination core.

    Sitara MPU : Sitara devices have huge pin packages and Due to the large number of possible GPIO interrupt sources, routing all interrupt events to each processing element is impractical. Since most applications do not typically require many GPIO interrupts, the Interrupter uncertainty is resolved by mapping all GPIO interrupts to a series of event MUXes implemented using Interrupt Router (IntRouter).

     Link: 

    https://www.ti.com/lit/ab/spradk0/spradk0.pdf?ts=1728887629537&ref_url=https%253A%252F%252Fwww.google.com%252F

    Multicore : 

    Traditional Microcontroller: Typically, traditional microcontrollers do not support multicore architectures.

    Sitara MPU: Sitara devices are multicore processors , In the Sitara MPU, IPC facilitates data transfer between cores.

    All the peripherals access is available on all cores but users need to use them in single core and the same already used peripherals are not supposed to use on other cores as well.

     Link : 

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/IPC_GUIDE.html

  • Watchdog Mechanism

    Traditional Microcontroller: A watchdog timer's expiration results in a complete core reset.

    Sitara MPU: The watchdog feature in Sitara devices is more complex since devices need to reset the SOC for all the core Watchdog events.

    So, on the SITARA devices there is an ESM (Error signal Module) module which collects all the errors from the different cores and then the user can decide either SOC Reset with the help of an ESM module or not when the Watchdog is expired with the help of configuring MMR registers .

    Each core has dedicated Watchdog .

     Link : 

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1283237/faq-am64x-am62x-how-to-reset-the-soc-when-wdt-timer-expires-in-am64x-and-am62x

    Timers and PWM Functionality : 

    Traditional Microcontroller: Basic timer and PWM (Pulse Width Modulation) functionalities are present.

    Sitara MPU: In addition to standard timer and PWM features, Sitara MPUs offer enhanced capabilities.

    Please look at the TRM for more details for enhanced features .

    I2C, SPI, and UART Communication : 

    Traditional Microcontroller: Basic I2C , SPI and UART functionalities are present.

    Sitara MPU: In addition to standard I2C , SPI and UART features, Sitara MPUs offer enhanced capabilities.

    Please look at the TRM for more details for enhanced features .

  • Reset Mechanisms :

    Traditional Microcontroller: Resets in traditional Microcontroller can be executed via software (SW) or hardware (HW) methods, providing basic control over the system state.

    Sitara MPU: Sitara MPUs support both SW and HW reset mechanisms. The architecture supports different reset types, such as Power-On Reset (POR), warm resets, and local CPU resets, each with distinct effects on memory and register states.

    Reset Isolation: This feature enables reset isolation for the MCU domain, ensuring that resets do not propagate to other domains, maintaining system integrity.

    Use cases for Reset Isolation : 

    1. Automotive  Applications :
    In modern vehicles, the reliable operation of the Linux core is crucial for functionalities such as infotainment systems, navigation, and driver assistance. A crash in the A53 core can result in system failures that impact safety and user experience. The MCU can quickly reset the Linux core, restoring operations with minimal disruption.

    2. Industrial Automation :
    Linux systems in industrial settings control machinery and monitor processes. A crash in the A53 core may halt production or introduce operational risks. Utilizing crash detection via the MCU core enables quick recovery, ensuring production efficiency and reducing downtime.


    3. Consumer Electronics :
    Devices like smart TVs and home automation systems operate on Linux. A crash can significantly degrade user experience. Employing the MCU to detect crashes and reset the Linux core enhances product reliability and customer satisfaction.


    4. Robotics :
    In robotic systems, Linux is used for high-level control and processing. Crashes can result in malfunction or unsafe behavior. A robust crash detection and recovery mechanism is essential to ensure quick recovery, maintaining safety and operational continuity.

    Link : 

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/MCU_RESET_ISOLATION.html

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1421267/faq-am6x-device-reset-troubleshooting-document