Introduction
The MCUSW do not provide Port MCAL drivers, this document details on techniques that could be used to integrate MCAL modules into an AUTOSAR stack with out Port modules.
The techniques details below can also be applied for AM62x/AM62A class of devices.
Device Architecture
DRA829 / TDA4VM / AM752x SoC top-level block diagram
- As show above 3 pimary domains, Wake-up (WKUP), MCU & Main
Wake-up
Device Management Security Controller (DMSC) provides
- Power / Clock Management
- Resource Management
- Security Management
- Other processing cores requests for resource, services to DMSC
MCU Domain
- Dual Core R5F / lock step
- Expected to host AUTOSAR/control SW
Main Domain
- Multiple Compute cores (R5F’s, A72’s, C66x’s, C7x’s)
- R5F's Expected to host AUTOSAR/Other SW functionalities
Back To Top
Device Architecture DMSC
- Each Compute core (CPU’s), before accessing / using a resource
- Request DMSC for required resources
- Request DMSC to setup required clock frequencies (for required peripherals)
- Typically done at start up
- DMSC hosts firmware, that provide these services
- Firmware is provided by TI
- SCI Client is hosted on other compute cores (MCU R5F, Main Domain R5F, A72, etc…)
- SCI Client API’s used to request these DMSC services
- DMSC Firmware
- Is a library hosted on DMSC
- Firmware loaded by Secondary Boot Loader (SBL)
- Can be used in systems upto ASIL D
- SCI Client SW
- Is Interface library that provides API’s to request DMSC for a specific operation
- Is hosted on local cores that requires services of DMSC
- Can be used in systems upto ASIL D
Back To Top
Generate Pinmux : Configuring Ports with MCU+ SDK
This section demonstrates how to configure pinmux settings for MPU devices such as AM62x, AM62P, AM62D, AM62A, and AM275x. We will use the MCU+ SDK (mcu_plus_sdk) to generate the necessary pinmux.c and other files for MCAL.
1. Overview
For each supported device, there is a corresponding MCU+ SDK (for example for AM62px it will be present here: https://www.ti.com/tool/download/MCU-PLUS-SDK-AM62PX/) that provides SysConfig, driver libraries, and tooling for pinmux. By following these steps, you can generate the required pinmux configuration files and then integrate them into your MCAL environment.
2. Using SysConfig
- Launch SysConfig for your specific device (e.g., AM62Px). For more information regarding
syscfg tool, please read the MCU+ SDK documentation, under Developer Guides -> Using SDK with SysConfig.
- Open or create a SysConfig project for pinmux for a particular device.
- Select the desired pins after selecting a module and configure them per your application needs (GPIO, SPI, I2C, UART, etc.).
Note: The SysConfig interface may vary slightly depending on the MCU+ SDK version or the device family.
3. Generating Pinmux Source Files
- Update the configuration and build the example of that particular device for appropriate module in MCU+ SDK to produce
pinmux.c, pinmux.h, and any other necessary files.
- These generated files contain the low-level pinmux configurations specific to your selected device and peripheral setup.
SYSCFG generated Code in MCU+ SDK
4. Updating/Using Generated Files in MCAL
- Navigate to your MCAL SDK example folder, typically found under
└── mcal_drv/
└── examples/
└── <module_name>/
└── <soc_device_name>/
└── Generated_Dpl/
- Copy the
pinmux.c, pinmux.h, and any additional generated files into the Generated_Dpl (or appropriate) subdirectory for that device.
SYSCFG MCAL Structure
Recommended Usage in Customer Applications
Note: In actual customer use cases, do not place generated files directly into the MCAL SDK example directories. Instead:
- When
pinmux and syscfg files are generated, they should be moved to the build environment where your application or use case is structured.
- From there, link against the MCAL SDK and MCU_PLUS_SDK libraries properly by setting the required include paths and library paths in your build system or makefiles.
- This ensures clean separation between SDK-provided examples and your custom application logic.
- It also allows calling SDK APIs like
pinmux_init() and others in a modular and maintainable way without modifying SDK examples directly.
5. Verifying the Configuration
- Build the MCAL demo or example project for your target device.
- Check that the pinmux configurations are applied at runtime (e.g., check the device registers or peripheral functionality).
- Validate that you can run any relevant driver examples (CAN, SPI, UART, etc.) on the newly configured pins.
6. Summary
By using the MCU+ SDK (mcu_plus_sdk) and SysConfig for each device (AM62x, AM62P, AM62D, AM62A, AM275x, etc.), you can quickly generate pinmux configuration files (pinmux.c, pinmux.h) and integrate them into your MCAL workflow. This process streamlines pinmux setup and ensures you have the correct device-specific configurations for each peripheral.
Back To Top
AUTOSAR Port Primary functionality
AUTOSAR on MCU R5F / AUTOSAR on MAIN R5F
- AUTOSAR / MCAL
- Can be hosted on MCU R5F and/or MAIN Domain R5F
- Port Primarily responsible for
- De multiplexing a PIN for required functionality
- Setup direction (in/out), enable pullup/pulldowns, etc…
Back To Top
AUTOSAR Mapping Port Functionality
De Muxing pin for a required functionality
- Jacinto/SMPU/SPMCU Class of devices has multiple pins that enable interface to external chips/logics
- Some of the pins can support more than 1 functionality (e.g. SPI Master-Out-Slave-In, can also act as Pwm output pin)
- Some of the peripheral IO could be routed to more than 1 pin (only 1 to be active at a time)
Multiple compute core requires to access device PINs
- A single register could control multiple pins functionality
- There could be instances where a single register might require access from multiple compute core
Recommended
- One processing entity performs PIN de-mux (such as SBL, AUTOSAR start up code)
Back To Top
[Reach to TI - in case of questions] (https://e2e.ti.com/)
1.12.0