1. F29H85x-MCAL-SDK 26.01.00 Release Notes

1.1. Introduction

F29x MCAL is a cohesive set of tools for AUTOSAR based development on C2000 real-time controllers. It includes device-specific drivers (MCALs), EB Tresos Plugins for configuration, Bare-metal Examples for each driver.

This release is a LTS (Long Term Support) release targeted for F29H85x.

1.2. Quick Start

  1. Get Access to MCAL:

    • Requested from ti.com

    • Downloaded from GitHub

    • Note: For more details of getting access and CI/CD strategy, refer to the User Guide.

  2. Install Prerequisites:

  3. Get Started:

    • Refer to the User Guide at Installer:\docs\User_Guide (local copy) or online version

    • Refer to the Migration Guide for upgrading from previous versions

    • Try the bare-metal examples in the examples/ directory

  4. Get Help:

1.3. Device Support

The following devices are supported with this release:

1.3.1. MCUs

  • F29H859DU_Q1

  • F29H859TM_Q1

  • F29H859TU_Q1

  • F29P329SJ_Q1

  • F29P329SM_Q1

  • F29P589DM_Q1

  • F29P589DU_Q1

1.3.2. Hardware Platforms

  • F29H85X-SOM-EVM

1.4. What Is Supported

  • MCAL / CDD (AUTOSAR v4.3.1)

Drivers

Modules

Micro controller Drivers

GPT, MCU, WDG

Communication Driver

CAN, LIN, SPI

I/O Drivers

DIO, PORT

Memory Drivers

FLS

Complex Device Drivers

ADC, XBAR, SENT, IPC, UART, PWM, ECAP, I2C, DMA, CMPSS

  • Resource Allocator

  • Reference Code:

    • Multi-Core startup code

  • Build System:

    • CMake

    • CCS Projectspec

  • Beta AI Agent Enablement

1.5. What Is Not Supported

  • Multi-core MCALs as per AUTOSAR 4.3.1.

1.6. New In This Release

  • MCAL / CDD:

    • New modules added:

      1. CDD CMPSS:

        • Added Baseline Quality (BQ) CMPSS driver with up to twelve independent instances, each providing High and Low comparators backed by independent 12-bit reference DACs.

        • Added programmable hysteresis and dual digital majority-vote filters per instance for trip-signal conditioning.

        • Added High/Low ramp generators with EPWM-synchronized reload and configurable cross-triggering to maintain a fixed phase relationship between the two ramps.

        • Added Diode Emulation (DE) mode and EPWM-synchronized blanking window support for synchronous-rectifier power stage applications.

        • Added a permanent configuration lock (Cdd_Cmpss_ApplyLock()) to freeze comparator, hysteresis, DAC/ramp, and filter/trip register groups against further runtime changes.

    • Existing modules with enhancements:

      1. CDD DMA:

        • Segregated privileged (link2-only) DMA APIs from common DMA APIs by introducing a dedicated CDD_DMA_PRIVILEGED_CODE memory section. Privileged-only APIs — Cdd_Dma_Init(), Cdd_Dma_DeInit(), Cdd_Dma_SetChannelPriority(), Cdd_Dma_SetDmaCfgCommit(), Cdd_Dma_SetMpuCfgCommit(), Cdd_Dma_SetMpuRegionCommit(), and related low-level register-access helpers — are now placed in this new section, separate from the common CDD_DMA_CODE section, enabling correct link/privilege placement when the System Security Unit (SSU) is enabled.

      2. Os (BSW Stub):

        • Added support for configuring the link owner for each ISR via the new OsIsrLinkOwner parameter, allowing individual interrupts to be assigned to any of the available link owners instead of a fixed link owner.

        • Added an optional NMI (Non-Maskable Interrupt) callback (OsNmiCallbackFunction) that applications can configure to be notified after the default NMI handler clears the NMI flag.

      3. BSW Stubs (CanIf, Dem, Det, EcuM, LinIf, Os, PduR, SchM):

        • Added complete MemMap section markers (START_SEC/STOP_SEC code and data sections) to all BSW stub sources, including a new CanIf_MemMap.h and expanded Can_MemMap.h, Dem_MemMap.h, Det_MemMap.h, EcuM_MemMap.h, LinIf_MemMap.h, Os_MemMap.h, PduR_MemMap.h, and SchM_MemMap.h, so that stub code and data are correctly placed into their intended memory sections.

        • Fixed: EcuM.c used ECUM_STOP_SEC_CODE instead of ECUM_START_SEC_CODE to open its code section MemMap block.

      4. Mcal_Lib:

        • Changed McalLib_GetTimerTickFromUs() to return a new McalLib_TickResultType structure (containing the status and computed tick count) by value, instead of writing the tick count through an output pointer parameter. This removes the need for callers to perform a NULL_PTR check. Note: This is a breaking API change; existing callers must be updated to use the new by-value return type.

      5. Resource Allocator:

        • The Resource Allocator ARXML (AUTOSAR XML) exporter is now available in SysConfig as part of the F29H85x SDK. When a System Architect runs SysConfig in Resource Allocator SETUP mode (--enableResourceAllocationSetup) on a Q1-variant device configured as an AUTOSAR core, the tool exports the peripheral allocation as three ARXML files — ResourceAllocatorModuleExport.arxml, PortModuleExport.arxml, and McuModuleExport.arxml — along with a resourceAllocation.json file. These artifacts give EB Tresos (on one CPU) and SysConfig CONFIGURE mode (via --resourceAllocation, on another CPU) a single, common source of truth for the peripheral allocation, removing the need to manually keep multi-CPU peripheral assignments in sync across tools. Note: This feature requires F29H85X-SDK v26.01.00 or later to be installed.

  • Examples:

    • Added DeviceSupport_ClearEsmEaFlags() to the DeviceSupport reference code. This API captures the CPU1 Error Status Manager (ESM) status for all groups and the Error Aggregator (EA) status for CPU1/CPU2/CPU3, RTDMA1/RTDMA2, SSU, and EtherCAT sources when an NMI occurs, then clears the corresponding status flags, giving applications visibility into the diagnostic status that triggered the NMI.

    • Added a new example, RA_Example_SysCfgToEbIntegration (under examples/RA/), demonstrating the end-to-end, two-persona Resource Allocator workflow: a System Architect allocates peripherals to CPU1 and CPU3 using SysConfig Resource Allocator SETUP mode, after which the CPU1 developer consumes that allocation via EB Tresos and the CPU3 developer independently consumes it via SysConfig CONFIGURE mode; the two resulting images are then merged into a single output binary using the PREBUILD()/POSTBUILD() build-system macros. This is a compile-only example (no hardware/runtime validation) intended purely to illustrate the Resource Allocator hand-off and multi-tool integration path.

  • Build System:

    • Added a centralized tool/dependency detection framework (build/toolchain/tool-detection.cmake) that automatically locates Code Composer Studio (CCS), SysConfig, and the F29H85x SDK installations, checking them against required minimum or recommended versions and reporting a clear status summary during CMake configuration. If a tool is not installed in its default directory, its path can be provided explicitly via -DCCS_PATH=<path>, -DSYSCFG_PATH=<path>, or -DF29H85X_SDK_PATH=<path>.

    • Introduced a new target_requires(...) declaration that examples and tests can use to specify which of these tools/dependencies they need. Examples or tests with an unmet dependency are now automatically skipped during configuration (with a clear status message).

    • Refactored the post-build signing flow into a single, centralized postBuild.py script that supports both single-core and multi-core (CPU2/CPU3) images, with automatic detection of the certificate and CPU2/CPU3 application sections. The previous CPU3MERGE() and SIGNING() CMake macros have been replaced with PREBUILD() and POSTBUILD(): PREBUILD() generates the CPU2/CPU3 application-size source files needed before the build, and POSTBUILD() signs the .out file and, if requested, merges the CPU2/CPU3 application binaries into it. CCS .projectspec post-build steps for examples and tests were updated to invoke the new postBuild.py script as well.

    • Added a new DUMMY_CERT CMake build option (enabled by default) that embeds a pre-built dummy certificate instead of performing full signing.

    • Added a new GENERATE_SYSCFG(...) CMake macro that generates code from a TI SysConfig (.syscfg) file as a pre-build step, supporting both plain and Resource-Allocation (RA) based SysConfig generation modes. Generation is automatically skipped (with a clear status message) if SysConfig and the F29H85x SDK are not detected.

    • Added support for the CMake “RAW” LINK_LIBRARY feature in the c29clang toolchain file, allowing SysConfig-generated linker command files to be linked in without CMake’s default library-flag decoration.

    • Overrode the compiled object file extension to .o for the c29clang toolchain (new build/toolchain/ti-cgt-c29-object-extension.cmake) so generated object file names match the naming convention expected by SysConfig-generated linker command files.

  • Silicon Errata Impact Analysis:

    • Completed analysis of F29H85x, F29P58x, and F29P32x Real-Time MCUs Silicon Errata (Silicon Revisions C, B, A, 0) for document version SPRZ569E – NOVEMBER 2024 – REVISED JULY 2026. Compared to the previously analyzed document version (SPRZ569D), this revision introduces no new advisories requiring action from MCAL users. As always, recommended actions for MCAL users (where applicable) are documented in the Silicon Errata Workarounds and Recommendations chapter of each Module User Guide.

1.7. Module Version Number

Module

Version

MCU

02.03.01

PORT

04.01.00

DIO

01.01.00

GPT

02.00.04

CAN

04.01.01

WDG

02.00.02

LIN

03.01.03

SPI

03.01.03

FLS

03.03.01

CDD ADC

05.00.01

CDD XBAR

03.02.00

CDD SENT

03.03.00

CDD PWM

03.01.03

CDD ECAP

03.02.01

CDD IPC

02.02.00

CDD UART

03.02.00

CDD I2C

01.04.01

CDD DMA

01.02.00

CDD CMPSS

01.00.00

Resource Allocator

01.02.01

1.7.1. Note

We follow Autosar’s requirement [SRS_BSW_00321] for versioning of each module:

5.2.4.10 [SRS_BSW_00321] The version numbers of AUTOSAR Basic Software Modules shall be enumerated according specific rules

Type

Description

Type:

Valid

Description:

The version numbers of AUTOSAR Basic Software Modules shall be enumerated according to the following rules:
- Increasing a more significant digit of a version number resets all less significant digits
- The PATCH_VERSION is incremented if the module is still upwards and downwards compatible (e.g. bug fixed)
- The MINOR_VERSION is incremented if the module is still downwards compatible (e.g. valid functionality added)
- The MAJOR_VERSION is incremented if the module is not compatible any more (e.g. existing API invalid)

Rationale:

Provide unambiguous version identification for each module, provide version cross check as well as basic version retrieval facilities. Compatibility is always visible!

Use Case:

Example: ADC module with version 1.14.2

1.8. Fixed In This Release

Key

Component/s

Severity

Summary

Affected Version

Impact

Steps to Reproduce

Fix Description

MCAL-40500

Spi

S3-Minor

SPI: Spi_SyncTransmit() fails at 20 MHz and above when chip select is configured as SPIX_PTE (hardware peripheral CS)

C29xMCAL_26.00.01

Spi_SyncTransmit() fails when operating at 20 MHz and above with hardware peripheral chip select (SPIX_PTE).

1. Configure SPI with hardware peripheral CS (SPIX_PTE). 2. Set the SPI clock to 20 MHz or above. 3. Call Spi_SyncTransmit(). 4. Observe that the transmission fails.

Test infrastructure fix only — no SPI driver changes were made. Root cause analysis confirmed this is not a driver defect. At high baud rates, the tester (slave) application could not execute fast enough to prepare response data before the SPI master clocked out the next word. The test infrastructure was updated by configuring a word delay in the test application’s SPI external device configuration, providing the tester slave sufficient processing time between consecutive word transfers. The SPI driver operates correctly at 20 MHz and above with SPIX_PTE hardware CS; there is no impact to end users of the driver.

MCAL-40515

Cdd_Uart

S3-Minor

CDD UART: Configured parity type (ODD/EVEN) not applied correctly

C29xMCAL_26.00.00

When parity is enabled, the hardware always used odd parity regardless of the configured parity type. Applications configured for even parity silently communicated with the wrong parity, causing frame errors on the receiving peer.

1. Configure UART with parity enabled and parity type set to EVEN. 2. Connect to a peer configured for even parity. 3. Observe parity errors on the peer.

Fixed the driver initialization to correctly apply the configured parity type (ODD or EVEN) to the hardware.

MCAL-40842

CDD SENT

S3-Minor

Cdd_Sent: MTP fast-channel ISR always reads MDATA[0] slot, ignoring Channel_id TPRAM offset

C29xMCAL_26.00.01

Data from fast channels S2-S4 is not read correctly, leading to incorrect sensor data or data loss.

1. Configure SENT with MTP fast channels. 2. Trigger interrupts on fast channels S2, S3, or S4. 3. Observe that only MDATA[0] is accessed regardless of which channel raised the interrupt.

Use the Channel_id to calculate the correct TPRAM offset in the ISR instead of using a fixed offset of SENT_O_MDATA(0U).

MCAL-40422

Fls

S3-Minor

Failure to claim flash semaphore should not trigger job failure

C29xMCAL_26.00.01

Erase or Write job fails if Flash semaphore acquisition fails

Run Fls with the semaphore already owned by CPU3 or another LINK on CPU1

Fixed the Fls driver so that a failure to acquire the flash semaphore no longer results in the Erase/Write job being reported as failed; the driver now retries semaphore acquisition and only fails the job for genuine flash hardware errors.

MCAL-40841

Resource Allocator

S3-Minor

Resource Allocator: Modules could reference CPU3 instances when no instance was allocated on CPU1

C29xMCAL_26.00.01

When a module had no instance allocated on CPU1 but did have an instance allocated on CPU3, the CPU3 instance was incorrectly selectable when configuring that module on CPU1, allowing an invalid cross-core instance reference.

1. In the Resource Allocator, allocate an instance of a module (e.g. MCAN) to CPU3 only, with no instance of that module allocated to CPU1. 2. Open the configuration for that module on CPU1. 3. Observe that the CPU3 instance is selectable as a reference within the module’s configuration.

Fixed the Resource Allocator XPath used for module instance reference parameters so that when no matching instance is allocated in the current CPU context, the picker no longer falls back to showing instances allocated to other CPU contexts.

MCAL-41325

Mcu

S3-Minor

Mcu: McuClockSettingId is neither auto-calculated nor has duplicate check implemented in plugin

C29xMCAL_26.00.01

This could lead to incorrect index mapping in the generated code, potentially causing the wrong MCU clock setting to be referenced at runtime

1. In Mcu add a new McuClockSettingConfig; keep the value same as any other McuClockSettingConfig or give a random value 2. Check the generated code and observe that the generated value for the symbolic name matches the index and not the value in the field

Fixed the McuClockSettingId validation in xdm by adding checks to detect duplicate or non-sequential Id’s and report an appropriate error during configuartion. This ensures that each McuClockSettingId is unique.

MCAL-41733

Resource Allocator

S3-Minor

Resource Allocator: Device, Variant, and Package selections fail to resolve when only a minimal set of plugins is loaded

C29xMCAL_01.04.00, C29xMCAL_01.04.01, C29xMCAL_26.00.00, C29xMCAL_26.00.01

If an EB Tresos project loaded only a small subset of MCAL plugins (for example, only Mcu and Can) together with Resource Allocator, the Device, Variant, and Package parameters in the Resource Allocator configuration could not calculate their available values or defaults. This happened because Resource Allocator relied on another, unrelated plugin to be loaded in order to supply a required ECU Resource Finder.

1. Create an EB Tresos configuration project that includes only the Mcu, Can, and Resource Allocator plugins. 2. Open the Resource Allocator module configuration. 3. Observe that the Device, Variant, and Package fields cannot resolve their available values or default selection.

Resource Allocator now registers its own ECU Resource Finder so that its Device, Variant, and Package parameters resolve correctly on their own, regardless of which other plugins are loaded.

1.9. Known Issues And Limitations

There are few limitations and known issues associated with this release.

1.9.1. Limitations

  • CDD ECAP:

    • In case of high frequency signals (i.e. 500Khz and above), software overhead in user callback shall be kept to minimum to avoid missing edges.

  • Test Infrastructure: Following tests have not been performed due to limitations of available test infrastructure:

    • CDD SENT: Following modes in SENT are not tested:

      • Enhanced 16-bit Slow Mode.

      • Nibble Count 1,2,3,4,5.

      • MTP Mode with all 4 sensors connected.

    • CDD IPC: IPC is validated between CPU1 and CPU3. Since, CPU2 is configured in lockstep in our framework; IPC between CPU1 and CPU2 or CPU2 and CPU3 is not validated.

    • Fls: Timeout tests are not performed as FLASH characterization data is not yet available for this device.

    • Spi: Board to board Spi communication validated upto 40MHz. 50MHz have been only tested in loopback mode. High-speed mode (HS Mode) has not been tested in board-to-board configuration.

1.9.2. New Known Issues

Key

Component/s

Severity

Summary

Affected Version

Impact

Steps to Reproduce

Workaround

EXT_EP-13552

C/C++ Compiler (cl)

S3-Minor

C29Clang Compiler: Incorrect results from left-shift paired with right-shift-by-16-or-24 expressions at -Os/-Oz/-O2/-O3

C29Clang 1.0.2.LTS, C29Clang 2.1.1.LTS

This is a compiler defect, not an MCAL defect. At -Os/-Oz/-O2/-O3, an expression of the form (x << N) >> 16 or (x << N) >> 24 (32-bit x, immediate N between 0-31) may be miscompiled and produce an incorrect result.

Compile such a shift expression at -Os/-Oz/-O2/-O3 and compare the result against the expected value.

MCAL has verified that none of its drivers use this shift pattern, so MCAL is not impacted. MCAL is delivered and tested with C29Clang 2.2.1 LTS; a future release will migrate to a compiler version with the issue resolved. Customers with application code using this pattern should migrate to one of the following compiler versions: C29_2.2.2.LTS, C29_1.0.3.LTS*, or C29_3.0.0.LTS*.

1.9.3. Existing Known Issues

Key

Component/s

Severity

Summary

Affected Version

Impact

Steps to Reproduce

Workaround

-

-

-

-

-

-

-

-

1.10. Quality Status

Sr. No.

Work Product

Availability

Where to find Artifacts

Current Quality Status

1

Dynamic Analysis Report
1. MCDC
2. Branch
3. Region
4. Line
5. Function

No

CSP

Will be available in future releases. Please refer to device roadmap for details.

2

Static Analysis Report
1. Static
2. HIS
3. MISRA-C

Yes

Installer:*\docs\Static_Analysis

All Mandatory & Critical warnings and errors are resolved. Required and Advisory warnings will be fixed in future releases.

3

Test Reports: Test Cases and Test Results

Yes

Installer:*\docs\Test_Report

All test reports are present in installer.

4

Bi-directional Traceability Report
1. MRD↔SPS
2. SPS↔SW Arch↔SWDesign Doc↔SW Units (Code)
3. MRD↔SPS↔Test Case
4. Test Case↔Arch Test Case↔Design

No

CSP

Will be available in future releases. Please refer to device roadmap for details.

5

Customer Docs: User Guide

Yes

Installer:*\docs\User_Guide

User Guide is present in installer as well as softwaredl

6

SW FMEA

No

CSP

Will be available in future releases. Please refer to device roadmap for details.

7

Detailed Design Document

No

CSP

Will be available in future releases. Please refer to device roadmap for details.

8

SW Manifest

Yes

Installer:*\mcal_manifest

SW manifest is present in installer

9

Software Product Specification: List of functional, safety requirements for SW components

No

CSP

Will be available in future releases. Please refer to device roadmap for details.

10

Architecture Document

No

CSP

Will be available in future releases. Please refer to device roadmap for details.

11

SW Safety Manual

No

CSP

Will be available in future releases. Please refer to device roadmap for details.

12

Safety Assessment

No

CSP

Will be available in future releases. Please refer to device roadmap for details.

Note: CSP = Compliance Support Package

Note: As part of this LTS release, FSQ (Functional Safety Quality) collaterals have been prepared and are currently progressing through functional safety certification. These collaterals will be made available to customers upon successful completion of certification.

1.11. Release Types

F29x MCAL releases follow a tiered support model with three release types: Early Adopter (EA), Short Term Support (STS), and Long Term Support (LTS). Each release type serves different customer needs and provides varying levels of support, quality assurance, and maintenance.

1.11.1. How to Identify Release Type

The release type for each F29x MCAL release can be identified through the following methods:

  • Release Notes Introduction Section: Every release note’s Introduction section will specify the release type (EA, STS, or LTS) for that particular release.

1.11.2. EA (Early Adopter)

Early Adopter releases are intended for customers who want early access to new features and capabilities before they are fully validated. These releases allow customers to evaluate new functionality and provide feedback during the development cycle.

Example Use Cases:

  • Early evaluation of new features

  • Proof-of-concept development

  • Providing feedback to the development team

  • Planning for future integration

1.11.3. STS (Short Term Support)

Short Term Support releases provide a stable platform with validated features suitable for development and integration activities. These releases offer improved quality assurance compared to EA releases but are not intended for production deployment.

Example Use Cases:

  • Development and integration activities

  • System validation and testing

  • Pre-production evaluation

  • Feature completeness verification

1.11.4. LTS (Long Term Support)

Long Term Support releases are production-ready releases that provide the highest level of quality assurance, safety certification support, and long-term maintenance. These releases are recommended for production deployment in automotive and safety-critical applications.

Example Use Cases:

  • Production deployment

  • Safety-critical applications

  • Automotive production systems

  • Applications requiring long-term stability and support

1.11.5. Release Type Comparison

Topic

EA (Early Adopter)

STS (Short Term Support)

LTS (Long Term Support)

Quality

Baseline Quality

Baseline Quality (new features)

Functional Safety (if applicable)

Testing

Best Effort

>95% pass

>95% pass

Safety CSP

NA

NA

Yes (if FSQ)

Safety Certification

NA

NA

Yes (Internal / External)

Maintenance

No

No

Will maintain until next LTS release

Bug Fix / Patch Release

No

Bugs that are prioritized will be fixed in the next release; no backporting to STS releases

Bug fixes on the LTS maintenance branch will be prioritized based on the severity of the bug

Feature Addition

Yes

Yes

New features will be added in an LTS release, but post LTS release, new features will not be backported to the LTS maintenance branch

Production Ready

No

Not recommended for Production

Recommended for Production

1.12. Software Bill of Materials

Component Type

Component Name

Production or Reference

Process Compliance

Certification

Distribution

Comments

Tools

${MCAL_INSTALL_PATH}/build/toolchain/*

Reference

Demo Quality

No

ti.com

Documentation

${MCAL_INSTALL_PATH}/docs/*

Reference

Not Applicable

Yes

ti.com

Drivers

${MCAL_INSTALL_PATH}/drivers/*

Reference

Baseline Quality

Yes

ti.com

Functional Safety Quality and Certification will be available in future releases. Please refer to device roadmap for details.

Stubs

${MCAL_INSTALL_PATH}/drivers/BSW_Stubs

Reference

Demo Quality

No

ti.com

BSW Stubs are provided as reference only.

Examples

${MCAL_INSTALL_PATH}/examples/*

Reference

Demo Quality

No

ti.com

Tools

${MCAL_INSTALL_PATH}/plugins/*

Reference

Baseline Quality

Yes

ti.com

Functional Safety Quality and Certification will be available in future releases. Please refer to device roadmap for details.

1.13. Dependencies

This release has dependency on the following tools: