1. F29H85x-MCAL-SDK 26.00.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 STS (Short Term Support) release targeted for F29H85x.

1.2. Quick Start

  1. Install Prerequisites:

  2. 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

  3. 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

  • 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

  • Beta AI Agent Enablement:

    1. CCS AI Agent Support:

      • Added AGENTS.md file to enable AI-assisted development workflows

      • AI coding agents can automatically create working F29 MCAL example projects

      • Compatible with CCS v20.05.00

      • CCS provides additional MCP services (build, debug) that help AI agents catch and fix issues automatically

      • For more information, see the CCS User Guide - AI Coding Assistants

      • Disclaimer: As with any AI-based tooling, results may vary. The AGENTS.md file will be updated iteratively based on feedback. Always review AI-generated code before use.

    2. LLM Context Files:

      • Added llms.txt and llms-full.txt files to provide structured project context for AI language models

      • These files follow the llms.txt standard to help AI tools better understand the F29x MCAL project structure and APIs

  • MCAL / CDD:

    • New modules added:

      1. CDD DMA:

        • Added DMA driver with support for memory-to-memory, memory-to-peripheral, and peripheral-to-memory transfers

        • Includes EB Tresos plugin for configuration

    • Existing modules with enhancements:

      1. CDD XBAR:

        • Added support for external interrupt configuration

        • Added APIs to configure external interrupt

        • Updated Cdd_Xbar_Gpio_interrupt example to demonstrate external interrupt configuration

        • Added CDD_XBAR_TRIP1 to EPWM Xbar output lines configuration

        • Updated EB Tresos plugin to use superset fallback lists for crossbar input line selections across Output, EPWM, CLB, MinDB, and ICL crossbar types

      2. WDG:

        • Added new Wdg_Example_Reset example demonstrating watchdog timer reset functionality

        • Example shows watchdog timeout behavior when intentionally not serviced

      3. MCU:

        • Lockstep configuration is now available through the Resource Allocator plugin

        • CPUSEL and FRAMESEL settings for supported peripherals can now be configured through the Resource Allocator plugin

        • Note: These features are released with limited testing in this release and will be comprehensively tested in the next release

      4. Resource Allocator:

        • Added superset property aggregation for all device variants, packages, physical pin numbers, mux modes, pin names, peripherals, and signal types

        • EB Tresos plugin configurations now use dynamic superset fallback values instead of hardcoded defaults, enabling the plugin to load and display valid options even when device-specific ECU resource files are not yet available

      5. PORT:

        • Updated EB Tresos plugin to use superset fallback lists for pin configuration parameters including peripherals, mux mode signals, physical pin numbers, pin names, mux modes, and supported directions

        • Restored EPWM6 pin configuration support as per updated specification for F29P32x devices

      6. CDD IPC:

        • Updated EB Tresos plugin to use superset fallback lists for IPC remote cores and IPC instance selections

      7. CDD PWM:

        • Restored EPWM6 configuration support as per updated specification for F29P32x devices

      8. DIO:

        • Added validation in DIO so that it can only refer to PORT pins that are configured as GPIO and mapped to AUTOSAR core i.e. CPU1

      9. CAN:

        • Updated CAN examples to use GPIO 234 and GPIO 235 for CAN TX/RX pins to align with the physically available pinout on the F29H85X-SOM-EVM board

      10. CDD ADC:

        • Updated Cdd_Adc_Example_DmaTransfer example to use the MCAL Cdd_Dma driver instead of the rtdma library from f29x_sdk

        • Added Voltref parameter to Cdd_Adc_GetTemperatureC() and Cdd_Adc_GetTemperatureK() APIs to enable accurate temperature calculation across different voltage reference configurations

        • Updated Temperature sensor example to use the latest Cdd_Adc_GetTemperatureC() and Cdd_Adc_GetTemperatureK() APIs

      11. CDD I2C:

        • Added support for I2C target mode operation

  • Silicon Errata Impact Analysis:

    • Completed analysis of F29H85x, F29P58x, and F29P32x Real-Time MCUs Silicon Errata (Silicon Revisions B, A, 0) for document version SPRZ569C – NOVEMBER 2024 – REVISED MARCH 2026; recommended actions for MCAL users are documented in the Silicon Errata Workarounds and Recommendations chapter of each Module User Guide.

  • Build System:

    • Updated TI C29 Clang compiler and linker version from 2.0.0.STS to 2.2.0.LTS

    • Updated post-build certificate handling steps across build infrastructure for FLASH image signing

1.7. Module Version Number

Module

Version

MCU

02.02.00

PORT

04.00.00

DIO

01.01.00

GPT

02.00.03

CAN

04.00.00

WDG

02.00.02

LIN

03.01.01

SPI

03.01.01

FLS

03.02.00

CDD ADC

04.00.00

CDD XBAR

03.01.00

CDD SENT

03.01.01

CDD PWM

03.01.01

CDD ECAP

03.01.01

CDD IPC

02.01.01

CDD UART

03.00.02

CDD I2C

01.03.00

CDD DMA

01.00.00

Resource Allocator

01.01.00

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-37005

Cdd_Adc, Cdd_Ecap, Cdd_Pwm, Spi

S3-Minor

MemMap: Variables placed in incorrect memory sections

C29xMCAL_01.04.00
C29xMCAL_01.04.01

Variables were placed in unintended memory regions due to incorrect MemMap section marker placement in driver source files.

1. Build MCAL drivers and check generated MAP file.
2. Verify generated memory map and observe module specific data memory location.
3. Review driver source files and identify incorrect section marker placement.

Corrected MemMap section marker placement: moved STOP_SEC_CODE to proper location in Cdd_Adc_Priv.c, removed redundant section markers in Cdd_Ecap_Priv.c, moved SFO calibration variables to file scope with proper sections in Cdd_Pwm_Priv.c, and added missing sections around Spi_DriverObjPtr in Spi_Priv.c.

MCAL-36330

Can

S2-Major

CAN: Continuous CanIf_TxConfirmation() when new transmission is not initiated

C29xMCAL_01.04.00
C29xMCAL_01.04.01

CanIf_TxConfirmation is received multiple times if new message transmission is not initiated on a HOH.

1. Send only one CAN message using Can_Write().
2. Schedule Can_MainFunction_Write() continuously.
3. Observe that CanIf_TxConfirmation() is called continuously for one message.
4. Expectation is CanIf_TxConfirmation() should be called only once after one CAN message transmission.
5. Similar issue happens in interrupt context as well.

As hardware register status (transmission and cancellation) does not clear until next transmission request is added, maintain the pending status in software to help identify if the message is already processed.

MCAL-35980

Can

S3-Minor

CAN: Configuration validation gap for CanMainFunctionRWPeriod in Polling/Mixed Mode

C29xMCAL_01.00.00
C29xMCAL_01.01.00
C29xMCAL_01.02.00
C29xMCAL_01.02.01
C29xMCAL_01.03.00
C29xMCAL_01.04.00

Configurator allows a hardware object mapped to a controller configured entirely in Polling mode to have no schedulable function mapped to it without any warning or error. If such configuration exists, hardware object can’t be read or written.

1. Open EB Tresos configuration tool.
2. Create a new Can module configuration.
3. Configure a CanController with: CanRxProcessing = POLLING, CanTxProcessing = POLLING.
4. Create 2 or more CanHardwareObjects that reference this CanController.
5. Do not configure any CanMainFunctionRWPeriodRef in HOH and do not make any entry in CanMainFunctionRWPeriods.
6. Generate the configuration.
7. Observe that no error is generated despite the invalid configuration.

Added configuration validation check in XDM to detect and report an error when a hardware object set to Polling mode has no CanMainFunctionRWPeriodRef mapped to it.

MCAL-35624

Dio

S3-Minor

DIO: Dio doesn’t follow AUTOSAR naming guidelines for typedefs and macros

C29xMCAL_01.00.00
C29xMCAL_01.01.00
C29xMCAL_01.02.00
C29xMCAL_01.02.01
C29xMCAL_01.03.00
C29xMCAL_01.04.00

As AUTOSAR naming convention is not followed, these definitions may conflict with other definitions in an application

Review the static and dynamic files of DIO module

Updated all macros in DIO module to follow AUTOSAR naming conventions (Dio_ prefix for all public symbols).

MCAL-35862

Fls

S2-Major

FLS: Fls_F29Compare casts a byte aligned pointer to a 32-bit aligned pointer and dereferences it, which is illegal

C29xMCAL_01.04.01

When Fls_f29Compare() is called with a ramAddr that is not 32-bit aligned (e.g. 8-bit aligned), execution will crash in Fls_priv.c in Fls_F29Compare() due to illegal pointer cast and dereference.

1. Call Fls_f29Compare() with a ramAddr that is not 32-bit aligned (e.g. 8-bit aligned).
2. Observe that execution crashes in Fls_priv.c in Fls_F29Compare() at P2VAR(uint32, AUTOMATIC, FLS_APPL_DATA) pu32CheckValueBuffer = (uint32 *)Fls_DrvObj.ramAddr;

Removed the illegal conversion and appropriately internally handle the 8-bit pointer.

MCAL-35789

Fls

S1-Critical

FLS: Flash API initialization fails due to missing semaphore handling in FlashAPIInit

C29xMCAL_01.04.01

The Flash API may not be properly initialized, which can cause flash operations to fail or produce unexpected errors.

1. Call FlashAPIInit without claiming flash semaphore.
2. Observe FLC_MMR_Access error.
3. Release flash semaphore without claiming it first.
4. Observe SSU MMR Error for FMSTAT clear register.

Added semaphore claim and release calls before and after the Flash initialization function.

MCAL-36611

Port

S3-Minor

PORT: Invalid characters in Peripheral Names and non-compliant Physical Pin ID enum values violate AUTOSAR naming rules

C29xMCAL_01.00.00
C29xMCAL_01.01.00
C29xMCAL_01.02.00
C29xMCAL_01.02.01
C29xMCAL_01.03.00
C29xMCAL_01.04.00
C29xMCAL_01.04.01

ARXML generation produces non-compliant AUTOSAR short names, causing AUTOSAR validation tools to reject the generated configuration. Downstream BSW configuration tools expecting valid AUTOSAR identifiers would fail.

1. Open EB Tresos with the Port plugin.
2. Create a Port configuration and select the ANALOG peripheral.
3. Observe peripheral signal names containing / characters (e.g., A0/C24/DACA_OUT).
4. Select any pin and observe the PortPhysicalPinId dropdown containing numeric-only entries (e.g., 1, 10).
5. Run arxml_gen_Port — generated ARXML contains invalid short names.
6. Run vsmd_check_Port — validation failures reported.

Replaced / characters in MuxModeSignalType entries with _ to comply with AUTOSAR short name rules. Added PORT_PIN_ prefix to numeric-only PhysicalPinNumber values to ensure all ENUMERATION literals start with an alphabetic character.
Note: Existing Port configurations may require migration. Refer to the Migration Guide for detailed steps.

MCAL-35838

Fls

S3-Minor

FLS: Incorrect hardcoding of FlsMaxWriteNormalMode to 16 in Fls_Init

C29xMCAL_01.04.01

FlsMaxWriteNormalMode is hardcoded to 16 bytes inside Fls_Init, overriding the user-configured value. Setting FlsMaxWriteNormalMode to 8 is silently ignored, causing write operations to use the wrong chunk size.

1. Set FlsMaxWriteNormalMode to 8 bytes in the FLS configuration.
2. Call Fls_Init with this configuration.
3. Initiate a Write operation.
4. Observe that FlsMaxWriteNormalMode is overridden to 16 bytes internally.

Removed the hardcoded assignment of FlsMaxWriteNormalMode in Fls_Init. The driver now correctly uses the value from the provided configuration.

MCAL-35849

Fls

S2-Major

FLS: Missing semaphore acquisition checks

C29xMCAL_01.04.01

The flash semaphore claim function — called before Fls_Init, Fls_Erase, and Fls_Write — does not verify whether the semaphore was actually acquired. If another core already holds the semaphore, the FLS driver proceeds with the flash operation without exclusive access, which can result in data corruption or unpredictable flash operation failures.

1. Configure a multi-core system where CPU3 holds the flash semaphore.
2. On CPU1, initiate a Flash operation (e.g., Fls_Erase or Fls_Write).
3. Observe that the operation fails.

Added a return value check after each semaphore claim call in Fls_Init, Fls_Erase, and Fls_Write. If the semaphore is not successfully acquired, the operation is aborted and an appropriate error is reported.

MCAL-35885

Fls

S2-Major

FLS: Bug in Fls_Fapi_issueProgrammingCommand

C29xMCAL_01.04.01

When FlsMaxWriteNormalMode is set to 8 bytes and a write of more than 8 bytes is requested, the second chunk is programmed incorrectly. The start condition offset (u32StartCondition) advances correctly, but the source data buffer pointer (pu8DataBuffer) is not compensated by the same offset, causing the second chunk to read from the wrong location in the source buffer.

1. Set FlsMaxWriteNormalMode to 8 bytes.
2. Initiate a Write operation for 16 bytes.
3. Observe that the first 8-byte chunk is written correctly.
4. Observe that the second 8-byte chunk is written with incorrect data due to pu8DataBuffer not being compensated by the chunk offset.

Corrected the indexing of pu8DataBuffer in Fls_Fapi_issueProgrammingCommand to be compensated by u32StartCondition bytes, ensuring each chunk reads from the correct position in the source data buffer.

MCAL-35964

Fls

S3-Minor

FLS: Bugs in implementation involving static and globals for Program and Erase

C29xMCAL_01.04.01

The Fls_U32FlsWrite_PostFapiFsmReady and Fls_SectorBankErase_PostFapiFsmReadyDone state variables are not initialized at startup and are not reset at job boundaries. If a Write or Erase job is canceled mid-operation, these variables retain stale values that can cause the next job to skip required steps (e.g., pre-write blank check, timeout capture) or behave incorrectly.

1. Initiate a Write (Program) operation.
2. Cancel the operation using Fls_Cancel() before it completes.
3. Initiate a new Write or Erase operation.
4. Observe that the subsequent operation behaves incorrectly due to stale PostFapiFsmReady state carried over from the canceled job.

The postFapiFsmReady (write PostFSM ready flag) and Fls_SectorBankErase_PostFapiFsmReadyDone (erase PostFSM ready flag) state variables are now explicitly reset at driver initialization and at the start of each new job, ensuring no stale state from a previous canceled or failed operation carries over into subsequent jobs.

MCAL-36715

Fls

S3-Minor

FLS: Timeout implementation is not cumulative

C29xMCAL_01.04.01

The timeout check for Program and Erase operations does not measure the total elapsed time across multiple Fls_MainFunction calls. The start time is reset on each call instead of being captured once at the beginning of the operation, so the timeout never accumulates and will not trigger even when the configured limit has been exceeded.

1. Enable timeout supervision (FLS_TIMEOUT_SUPERVISION_ENABLED = STD_ON).
2. Set the timeout value for Erase or Program to approximately 10% of the expected operation duration.
3. Initiate an Erase or Program job and observe that no timeout failure is reported, even though the configured limit is far exceeded.

The timeout start time is now captured once per FSM operation — at the point the erase or program command is first issued — and held constant while the FSM remains in the same polling stage across subsequent Fls_MainFunction calls. This ensures the elapsed time is measured cumulatively over the full duration of the operation.

MCAL-36722

Fls

S2-Major

FLS: Failure scenarios in Program and Erase (Sector, Bank) not properly handled

C29xMCAL_01.04.01

When a failure occurs during a Program or Erase operation, the internal FSM state variables are not reset to their default values. The failed job is reported correctly, but any subsequent job may start from a stale state, leading to unexpected behavior or further failures.

1. Artificially introduce a failure in a single Erase (Sector or Bank) or Program operation.
2. Observe that the failure is reported correctly via the job error notification.
3. Initiate a subsequent Erase or Program operation.
4. Observe that the subsequent operation does not behave correctly due to stale FSM state carried over from the failed job.

Moved the FSM state variables for Program (write stage, PostFapiFsmReady flag) and Erase (sector erase stage, bank erase stage) into the driver object (Fls_DrvObj) so they are explicitly reset on driver initialization and at the start of each new job. Also consolidated the flash semaphore release in the erase job processing path to ensure the semaphore is always released regardless of which optional features (timeout supervision, erase verification) are enabled.

MCAL-36502

Can

S3-Minor

CAN: Transceiver delay offset and delay filter values are not handled according to AUTOSAR requirement

C29xMCAL_01.04.01

The CanControllerTrcvDelayCompensationOffset and TxDelayCompFilter configuration values are expected to be in nanoseconds (range 0–400) per the AUTOSAR SWS, but the driver was treating them as mtq units (range 0–127) and writing them directly to the MCAN_TDCR register. This results in incorrect transceiver delay compensation behavior when CAN FD Tx delay compensation is enabled.

1. Enable Tx Delay compensation in the CAN configuration.
2. Configure CanControllerTrcvDelayCompensationOffset and TxDelayCompFilter with values in the range 0–400 ns in EB Tresos.
3. Monitor the MCAN_TDCR_TDCF and MCAN_TDCR_TDCO registers.

Added proper unit conversion from nanoseconds to mtq (minimum time quantum) units before writing CanControllerTrcvDelayCompensationOffset and TxDelayCompFilter values to the MCAN_TDCR register, ensuring the transceiver delay compensation is applied correctly as per the AUTOSAR specification.

MCAL-35835

Can, CDD SENT

S3-Minor

CAN, CDD SENT: Pointer-list arrays incorrectly declared using CONST(Type*, memclass) instead of CONSTP2CONST

C29xMCAL_01.04.01

Config arrays holding pointers to const objects (e.g., baud-rate config lists, mailbox lists, SENT channel/MTP config lists) were declared with CONST(Type*, memclass), which expands to a non-const pointer to const data. This caused the linker to place these arrays in .bss/.data sections instead of const/rodata sections, resulting in memmap section check failures for CAN and CDD SENT. No functional behavior is affected at runtime.

1. Build any CAN or CDD SENT test or example.
2. Read the generated MAP file.
3. Observe that the MAP file reports unmapped sections (.bss.CanConfigSet_*_List, .data.CddSentConfig_*_List).

Replaced all CONST(Type*, memclass) declarations for pointer-list arrays with the correct CONSTP2CONST(Type, memclass, ptrclass) AUTOSAR macro in the EB Tresos generator templates (Can_Cfg.c, Can_PBcfg.c, Can_Cfg.h, Cdd_Sent_Cfg.c). Updated the corresponding struct field types in Can.h and Cdd_Sent.h from const Type** to const Type * const * to match, and updated the local variable in Cdd_Sent_Priv.c that receives a list element from P2VAR to P2CONST. All CAN and CDD SENT output files must be regenerated from EB Tresos to pick up the template fixes.

MCAL-35808

Mcal_Lib

S3-Minor

Dependency of Mcal_Lib_MemMap.h for MCAL drivers

C29xMCAL_01.04.01

Potential MemMap generation issues due to missing function documentation

Mcal_Lib_MemMap.h is included in sys_pmu.c.

Corrected the MCAL_Lib_Bswmd.arxml with Module definition and other required parameters to create the Module and generate MemMap in Davinci

MCAL-35347

CDD I2C

S2-Major

I2C: Cancel API is not functional

C29xMCAL_01.04.00

The I2C_Cancel API does not successfully cancel an ongoing I2C transfer in either polling or interrupt mode, which may cause the driver to hang and result in unexpected behavior in applications relying on transfer cancellation.

1. Start an I2C transfer.
2. Immediately cancel the transfer by invoking the I2C_Cancel API.
3. Observe that the cancellation does not take effect and the driver may hang.

Implemented the I2C_Cancel API to correctly abort an ongoing I2C transfer in both polling and interrupt modes, ensuring the driver returns to an idle state after cancellation.

MCAL-32321

All

S2-Major

All Modules: Link time optimization is not verified for all modules

C29xMCAL_01.03.00

Link time optimization (LTO) had not been verified across all modules, which could cause unexpected behavior or build issues if enabled.

1. Add -flto flag to compiler options.
2. Build the MCAL project.
3. Behavior is not verified there might be unexpected issues.

Verified link time optimization (LTO) across all MCAL modules. LTO is now supported and validated for all drivers.

MCAL-36814

All

S3-Minor

All Modules: MainFunction execution context incorrectly set to UNSPECIFIED in bswmd.arxml

C29xMCAL_01.04.01

The main function execution context in bswmd.arxml files for all MCAL modules was set to UNSPECIFIED instead of TASK. This may cause integration issues with BSW tooling that validates the execution context of scheduled main functions.

1. Open the bswmd.arxml file for any MCAL module.
2. Inspect the <EXECUTION-CONTEXT> element for the main function entry.
3. Observe that the context is set to UNSPECIFIED instead of TASK.

Updated all MCAL module bswmd.arxml files to set the main function execution context to TASK as required by the AUTOSAR specification.

MCAL-36584

All

S3-Minor

All Modules: BSWModuleEntry incorrectly uses expectedEntry instead of implementedEntry in bswmd.arxml

C29xMCAL_01.00.00
C29xMCAL_01.01.00
C29xMCAL_01.02.00
C29xMCAL_01.03.00
C29xMCAL_01.04.00
C29xMCAL_01.04.01

The bswmd.arxml files for all MCAL modules used a mix of expectedEntry and implementedEntry attributes for BSWModuleEntry elements. All entries should use implementedEntry to correctly reflect the implemented interface, which may cause validation failures in AUTOSAR tooling.

1. Open the bswmd.arxml file for any MCAL module.
2. Inspect the BSWModuleEntry elements.
3. Observe that some entries use expectedEntry instead of implementedEntry.

Replaced all expectedEntry attributes with implementedEntry in the bswmd.arxml files across all MCAL modules to correctly reflect the implemented BSW module interface.

MCAL-36562

CDD IPC

S3-Minor

CDD IPC: Incorrect IPC instances reserved when CddIpcReservedInstances is set to 1

C29xMCAL_01.03.00
C29xMCAL_01.04.00
C29xMCAL_01.04.01

When CddIpcReservedInstances is set to 1, the wrong IPC instances were being reserved — INST2 was skipped and INST3 was incorrectly included instead, resulting in non-continuous instance numbering. This causes incorrect IPC instances to be available for configuration in EB Tresos.

1. Open EB Tresos with the CDD IPC plugin.
2. Set CddIpcReservedInstances to 1.
3. Observe the available IPC instances — INST2 is missing and INST3 is incorrectly included.

Corrected the IPC instance reservation logic to ensure continuous and correct instance numbering when CddIpcReservedInstances is set to 1.

MCAL-35788

Mcal_Lib

S2-Major

Mcal_Lib: Symbol redefinition conflict for Mcalib_BromStatus and McalLib_DeviceCalibrationData when used alongside f29x_sdk

C29xMCAL_01.03.00

When MCAL and f29x_sdk are used together, Mcalib_BromStatus and McalLib_DeviceCalibrationData are defined as constants in both packages, causing a linker redefinition conflict. If a customer renames these symbols in MCAL to resolve the conflict, incorrect ADC trim values are loaded with no warning given, resulting in degraded MCU and CDD ADC performance.

1. Use MCAL together with f29x_sdk in the same project.
2. Observe linker redefinition errors for Mcalib_BromStatus and McalLib_DeviceCalibrationData.
3. Rename the symbols in MCAL to resolve the conflict.
4. Observe that MCU and CDD ADC produce unexpected results due to incorrect trim values being loaded.

Changed Mcalib_BromStatus and McalLib_DeviceCalibrationData in Mcal_Lib_BootRom.c from constant definitions to pointers referencing the reserved memory locations. This eliminates the redefinition conflict when used alongside f29x_sdk while ensuring the correct trim values are always accessed.

MCAL-37849

Can

S3-Minor

CAN: Non-sequential MCAN instances fail to function when preceding instances are not configured

C29xMCAL_01.04.01

CAN instances must be configured in sequential order to operate correctly. If earlier MCAN instances (e.g., MCAN A and MCAN B) are not configured, any higher-numbered instance (e.g., MCAN C) will fail to function. This prevents users from selectively enabling only the MCAN instances they need.

1. Open EB Tresos and create a CAN configuration.
2. Configure only MCAN C, leaving MCAN A and MCAN B unconfigured.
3. Build and run the application.
4. Observe that MCAN C does not function correctly despite being configured.

Updated the CAN driver to allow non-sequential MCAN instance configuration, so that any MCAN instance can be used independently without requiring all preceding instances to be configured.

MCAL-37887

Cdd_Adc

S3-Minor

CDD ADC: Temperature conversion APIs lack support for different voltage references in external reference mode

C29xMCAL_01.01.00
C29xMCAL_01.02.00
C29xMCAL_01.02.01
C29xMCAL_01.03.00
C29xMCAL_01.04.00
C29xMCAL_01.04.01

The Cdd_Adc_GetTemperatureC() and Cdd_Adc_GetTemperatureK() APIs did not support temperature calculation for different voltage references when using external reference mode, limiting their usability in systems with non-standard voltage references.

1. Configure ADC with external voltage reference mode using a non-standard voltage (e.g., 3.0V).
2. Call Cdd_Adc_GetTemperatureC() or Cdd_Adc_GetTemperatureK() to convert temperature sensor reading.
3. Observe that the temperature calculation is incorrect because the API cannot account for the actual external voltage reference value.

Added new Voltref parameter (float32) to Cdd_Adc_GetTemperatureC() and Cdd_Adc_GetTemperatureK() APIs to enable accurate temperature calculation for different voltage references. The parameter accepts internal voltage reference values (2.5F for 2.5V, 3.3F for 3.3V) or actual external voltage reference values.The Voltref value must exactly match the actual voltage reference being used.
Note: This is an API change. Existing code must be updated to include the Voltref parameter. Refer to the Migration Guide for detailed steps.

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.

1.9.2. New Known Issues

Key

Component/s

Severity

Summary

Affected Version

Impact

Steps to Reproduce

Workaround

-

-

-

-

-

-

-

-

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

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. CI/CD Strategy

F29H85x MCAL is also available on GitHub at https://github.com/TexasInstruments/f29h85x-mcal. The GitHub repository always reflects the leading and bleeding edge of MCAL development, providing early access to the latest features, fixes, and improvements as they are developed.

Disclaimer: The GitHub repository contains software that is not fully tested and may include bugs, errors, or defects that could cause system instability or unexpected behavior. Always review and validate code before use in any application.

Official releases are published under the Releases section of the GitHub repository. These correspond to the versioned releases documented in these release notes and have undergone the quality and testing criteria.

1.13. 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

Baseline Quality

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.14. Dependencies

This release has dependency on the following tools: