1. F29H85x-MCAL-SDK 26.00.01 Release Notes

• Introduction

• Quick Start

• Device Support

• What Is Supported

• What Is Not Supported

• New In This Release

• Module Version Number

• Fixed In This Release

• Known Issues And Limitations

  • Limitations

  • New Known Issues

  • Existing Known Issues

• Quality Status

• Release Types

  • How to Identify Release Type

  • EA (Early Adopter)

  • STS (Short Term Support)

  • LTS (Long Term Support)

  • Release Type Comparison

• Software Bill of Materials

• Dependencies

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

   • Install all tools listed in the Dependencies section.

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:

   • Technical Support: E2E Forum

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

• MCAL / CDD:

  • Existing modules with enhancements:

    1. MCU:

       • Added Analog System Control (ASysCtl) support: Mcu_Init() now configures the analog subsystem (temperature sensor, analog reference, voltage regulator, brown-out reset, CMPSS mux, and internal test node) using a new Mcu_ASysCtlConfigType configuration structure generated by EB Tresos

       • Added new public ASysCtl APIs: Mcu_ASysCtl_ConfigureTemperatureSensor, Mcu_ASysCtl_ConfigureAnalogReference, Mcu_ASysCtl_ConfigureVoltageRegulator, Mcu_ASysCtl_ConfigureBrownOutReset, Mcu_ASysCtl_SelectCMPSSHNMuxValue, Mcu_ASysCtl_SelectCMPSSLNMuxValue, Mcu_ASysCtl_SelectInternalTestNode, Mcu_ASysCtl_CommitLock, Mcu_ASysCtl_ConfigADCGlobalSOC, and Mcu_ASysCtl_ForceADCGlobalSOC

       • Added Mcu_SysCtl_ConfigEPWMXLink API to configure the EPWM cross-link (EPWMXLINKCFG) register; CDD PWM now delegates EPWM cross-link configuration to this API instead of accessing the hardware register directly

       • Updated EB Tresos plugin (Mcu_TI_F29H85x) code generation templates (Mcu_Cfg.h, Mcu_Cfg.c, Mcu_PBcfg.c) to emit the Mcu_ASysCtlConfigType initializer and Mcu_ASysCtlTestNodeType enum from ResourceAllocator ASysCtl settings

    2. PORT:

       • Added Analog System Control (ASysCtl) support: Port_Init() now configures the AGPIOFILTER register using a new Port_ASysCtlConfigType configuration structure; Port_CommitConfiguration() applies the one-time write-lock to the ASYSCTL CONFIGLOCK register for AGPIOFILTER and AGPIOCTRL registers

       • Updated EB Tresos plugin (Port_TI_F29H85x) code generation templates (Port_Cfg.h, Port_Cfg.c, Port_PBcfg.c) and XDM/ARXML to include Port_ASysCtlConfigType and AGPIOFILTER configuration

    3. CDD ADC:

       • ASysCtl configuration (temperature sensor, analog reference, voltage regulator, brown-out reset, CMPSS mux) has been moved from the CDD ADC module to the MCU driver and ResourceAllocator plugin; existing configurations must be migrated to the ResourceAllocator XDM

       • Global software trigger functions Cdd_Adc_GlobalSwTrigger() and Cdd_Adc_SocGlobalSwTrigger() now delegate to the new Mcu_ASysCtl_ConfigADCGlobalSOC() and Mcu_ASysCtl_ForceADCGlobalSOC() MCU APIs instead of accessing hardware registers directly

       • Updated EB Tresos plugin (Adc_TI_F29H85x) to remove ASysCtl configuration from Cdd_Adc.xdm and Cdd_Adc.arxml; updated Cdd_Adc_Cfg.h and Cdd_Adc_Cfg.c templates accordingly

    4. Resource Allocator:

       • Added ASysCtl container with configurable sub-containers — TemperatureSensor, AnalogReference, VoltageRegulator, BrownOutReset, InternalTestNode — to expose analog system control parameters for user configuration across F29H85x, F29P32x, and F29P58x device variants

       • Added CMPSS Input Mux selection parameters under Cdd_Cmpss container

    5. CDD DMA:

       • Added Cdd_Dma_GetChannelPriority API to retrieve the current priority level of a DMA channel

       • Added Cdd_Dma_PeriodicReadback API to support periodic readback of DMA channel registers for safety mechanisms

• 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 SPRZ569D – NOVEMBER 2024 – REVISED MAY 2026; recommended actions for MCAL users 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.00
PORT	04.01.00
DIO	01.01.00
GPT	02.00.03
CAN	04.01.00
WDG	02.00.02
LIN	03.01.02
SPI	03.01.02
FLS	03.03.00
CDD ADC	05.00.00
CDD XBAR	03.02.00
CDD SENT	03.02.00
CDD PWM	03.01.02
CDD ECAP	03.02.00
CDD IPC	02.02.00
CDD UART	03.01.00
CDD I2C	01.04.00
CDD DMA	01.01.00
Resource Allocator	01.02.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-38556	Cdd_Dma	S3-Minor	CDD DMA: Inconsistent reentrancy declarations in BSWMD ARXML	C29xMCAL_26.00.00	The Cdd_Dma BSWMD ARXML file contained inconsistent reentrancy declarations between two sections. The BSW-CALLED-ENTITY section (lines 547-951) correctly declared 23 APIs as SINGLE-CORE-REENTRANT, while the BSW-MODULE-ENTRY section (lines 1328-1617) incorrectly declared the same APIs as non-reentrant (IS-REENTRANT=false). This inconsistency could lead to incorrect assumptions during system integration or AUTOSAR toolchain processing.	1. Open plugins/Dma_TI_F29H85x/generate_swcd/swcd/Cdd_Dma_BSWMD.arxml. 2. Compare the BSW-CALLED-ENTITY section (lines 547-951) with the BSW-MODULE-ENTRY section (lines 1328-1617). 3. Observe that APIs are marked as SINGLE-CORE-REENTRANT in one section but IS-REENTRANT=false in the other.	Updated the BSW-MODULE-ENTRY section to correctly mark 20 Cdd_Dma APIs as reentrant (IS-REENTRANT=true), ensuring consistency with the BSW-CALLED-ENTITY section declarations.
MCAL-38580	Cdd_Dma	S3-Minor	Channel priority update fails when CddDmaLockConfigurations is enabled	C29xMCAL_26.00.00	The Cdd_Dma_SetChannelPriority API is unable to update the priority of a channel when CddDmaLockConfigurations is configured as true.	1. Configure CddDmaLockConfigurations = true in the configurator. 2. Invoke the Cdd_Dma_SetChannelPriority API to modify the channel priority. 3. Verify whether the channel priority is updated.	Added configuration unlock and lock handling within the Cdd_Dma_SetChannelPriority API.
MCAL-37919	Mcu	S3-Minor	MCU: Compilation error in generated Mcu_PBcfg.c due to invalid .RegAddr initializer for DLTFifoRegs, Error_Aggregator, ESM, and Cdd_Xbar flag peripherals	C29xMCAL_26.00.00	The generated Mcu_PBcfg.c fails to compile when DLTFifoRegs, Error_Aggregator, ESM, or Cdd_Xbar flag peripheral instances are configured in the ResourceAllocator XDM. The MCU plugin template emitted the raw BaseAddr XDM field value verbatim instead of constructing the address as DEVCFG_BASE + SYSCTL_O_<instance>, causing a non-constant or out-of-scope expression that the compiler rejects.	1. Configure ResourceAllocator XDM with any DLTFifoRegs, Error_Aggregator, or ESM instance. 2. Run EB Tresos code generation. 3. Build the generated Mcu_PBcfg.c — compilation fails due to invalid .RegAddr initializer.	Updated the MCU plugin template for DLTFifoRegs, Error_Aggregator, ESM, and Cdd_Xbar flag peripheral entries to generate .RegAddr = (uint32)(DEVCFG_BASE + SYSCTL_O_<instanceName>), consistent with all other peripheral types.
MCAL-38559	Cdd_Dma	S3-Minor	CDD DMA: Project generation fails when no DMA channels are allocated to Cdd_Dma	C29xMCAL_26.00.00	The CddDmaChannel container enforced a minimum multiplicity of 1, preventing valid configurations where CPU1 handles only global DMA setup while CPU2/CPU3 manages channel allocation via SDK RTDMA. Attempting to generate the project without any channels configured on Cdd_Dma would fail.	1. In Resource Allocator, allocate DMA channels to CPU2/CPU3. 2. In Cdd_Dma for CPU1, leave the channel list empty (zero channels). 3. Attempt to generate the project. 4. Observe that generation fails due to the minimum channel count constraint.	Updated the CddDmaChannel container minimum multiplicity from 1 to 0 in Cdd_Dma.xdm, allowing CPU1 to use a valid zero-channel configuration.
MCAL-38598	Cdd_Dma	S3-Minor	CDD DMA: BurstSize, TransferSize, and WrapSize fields truncate maximum hardware values due to insufficient data types	C29xMCAL_26.00.00	The maximum configurable values for BurstSize, TransferSize, SrcWrapSize, and DestWrapSize were one less than what the hardware supports. The driver subtracts 1 from the API value before writing to the register. Since the previous types (uint8 for BurstSize, uint16 for TransferSize/WrapSize) could not represent that extra value, the hardware maximum register value was unreachable through the API.	1. Call Cdd_Dma_SetTransferSize(channelId, 255U, 1U) with maximum uint8 input for BurstSize. 2. Observe 254 written to BURSTSIZE register instead of hardware maximum 255. 3. Call Cdd_Dma_SetTransferSize(channelId, 1U, 65535U) with maximum uint16 input for TransferSize. 4. Observe 65534 written to TRANSFERSIZE register instead of hardware maximum 65535.	Updated the data types of BurstSize, TransferSize, SrcWrapSize, and DestWrapSize fields in the API configuration structures to use wider integer types, allowing the full hardware register range to be configured through the API.
MCAL-38989	Can	S2-Major	CAN: Spurious TxConfirmation triggered for buffers with a pending new transmission	C29xMCAL_26.00.00	When CanIf_TxConfirmation for buffer N triggers a Can_Write for buffer M (M > N) within the same ISR execution, the driver may fire a premature CanIf_TxConfirmation for buffer M. This happens because Can_CheckAllTxBuffers() uses a one-time snapshot of MCAN_TXBTO taken at ISR entry; the stale snapshot still shows TXBTO[M]=1 from the previous successful transmission, causing the loop to treat the newly queued buffer as already confirmed. This causes segmented or chained CAN frame sequences to stall permanently.	1. Configure CAN with multiple TX buffers. 2. In a CanIf_TxConfirmation callback for buffer N, call Can_Write to queue a new frame on buffer M (M > N). 3. Observe that a spurious CanIf_TxConfirmation is immediately fired for buffer M before the frame is actually transmitted.	Updated Can_CheckAllTxBuffers() to re-read MCAN_TXBAR and MCAN_TXBRP before issuing a CanIf_TxConfirmation, ensuring that buffers with a newly queued transmission are not incorrectly confirmed.
MCAL-38778	Can	S3-Minor	CAN: TX cancellation interrupt (TCF) not triggered when bus-off occurs during an outstanding transmission	C29xMCAL_26.00.00	When the CAN bus enters bus-off state while a transmission is outstanding and interrupt mode is configured, the driver may not receive the TX cancellation finished (TCF) interrupt for successfully cancelled frames. This occurs because the TXBCIE (TX Buffer Cancellation Finished Interrupt Enable) bits were not set alongside TXBTIE (TX Buffer Transmission Interrupt Enable) during driver initialization, preventing the hardware from generating the cancellation interrupt.	1. Configure CAN TX processing in INTERRUPT mode. 2. Trigger a bus-off condition while a transmission is pending. 3. Observe that the TCF interrupt is not generated for the cancelled transmission, leaving the TX buffer in an unconfirmed state.	Updated the CAN driver initialization to set TXBCIE bits together with TXBTIE bits, ensuring that TX cancellation finished interrupts are enabled for all configured TX buffers.
MCAL-37896	Can	S3-Minor	CAN: TX buffer queue/FIFO mode not aligned with CanMultiplexedTransmission configuration	C29xMCAL_26.00.00	The MCAN TX buffer mode register (MCAN_TXBC_TFQM) was hardcoded to 1 (priority-queue mode), causing the hardware to always transmit the message with the lowest CAN ID first regardless of submission order. The correct behavior is to select queue mode or FIFO mode based on the CanMultiplexedTransmission setting: when multiplexed transmission is enabled, priority-queue mode is appropriate; when disabled, FIFO order should be used.	1. Disable CanMultiplexedTransmission in the CAN configuration. 2. Queue multiple CAN messages with different IDs in a specific order. 3. Observe that messages are transmitted by lowest CAN ID first (queue mode) instead of in submission order (FIFO mode).	Removed the hardcoded txBufMode field and updated the driver to configure MCAN_TXBC_TFQM based on the CanMultiplexedTransmission parameter: set to 1 (queue mode) when CAN_CFG_MULTIPLEXED_TX is STD_ON, and 0 (FIFO mode) when STD_OFF.
MCAL-38751	Cdd_Sent	S3-Minor	CDD SENT: Slow channel interrupt silently dropped when fast channel interrupt fires simultaneously	C29xMCAL_26.00.00	Slow channel messages are silently lost whenever a fast channel interrupt is pending at the same time. Since the SENT hardware uses a single shared interrupt line for both fast and slow channel events, this is a normal operating condition — slow channel messages are routinely interleaved within fast channel frames. The lost interrupt cannot be retried because all interrupt flags are cleared unconditionally at the end of the ISR.	1. Configure CDD SENT with both fast and slow channel interrupts enabled. 2. Operate the SENT bus such that a slow channel message (RSLOW_DV) and a fast channel event (FIFO trigger or MTP data valid) are pending simultaneously. 3. Observe that the slow channel notification callback is not invoked even though a slow channel message was received.	Changed the fast and slow interrupt checks in Cdd_Sent_ProcessISR() from an if / else if structure to two independent if checks, ensuring both fast and slow interrupts are always evaluated and processed within the same ISR invocation. The error callback is now only invoked when neither fast nor slow interrupt flags are active.
MCAL-40406	Cdd_Sent	S3-Minor	CDD SENT: SENT_O_RCFG register overwrite during initialization clears CRC configuration bits	C29xMCAL_26.00.00	During Cdd_Sent_Init, the SENT_O_RCFG register was written using a plain assignment (=) instead of a masked field write. This overwrote all bits in the register — including the CRC configuration bits — with only the TTCLK field value, silently discarding any CRC settings that had been configured.	1. Configure CDD SENT with a non-default CRC setting in SENT_O_RCFG. 2. Call Cdd_Sent_Init. 3. Read back SENT_O_RCFG and observe that the CRC configuration bits have been cleared.	Replaced the raw register write to SENT_O_RCFG with a masked field write using McalLib_RegMFWriteRaw32, so that only the TTCLK field is updated during initialization and all other register bits are preserved.
MCAL-39918	Gpt	S3-Minor	GPT: EB Tresos reports “GptClockReferencePoint has not enough children” error when creating a new Gpt configuration project	C29xMCAL_26.00.00	Users cannot create new GPT configurations in EB Tresos due to a validation error in the plugin XDM schema.	1. Open EB Tresos Studio. 2. Create a new EB Tresos project. 3. Add the Gpt_TI_F29H85x plugin to the project. 4. Open the Gpt module configuration editor. 5. Navigate to GptDriverConfiguration. 6. Observe the “GptClockReferencePoint has not enough children” validation error in the Problems View.	Updated the GptClockReferencePoint container in Gpt.xdm to set VISIBLE and EDITABLE attributes to TRUE, allowing EB Tresos to correctly display and populate the required clock reference point children and resolve the validation error.
MCAL-38182	Cdd_Ecap	S3-Minor	CDD ECAP: ECAP example has incorrect documentation for GPIO loopback connection	C29xMCAL_26.00.00	The ECAP example configures the ECAP input pin in PORT as EPWM (GPIO0/EPWM1_A), but the ECAP module user guide incorrectly states to use GPIO1 as the ECAP input. The example runs without any external connection, but the documentation was not updated to reflect the correct GPIO pin used.	1. Run the ECAP example with external GPIO loopback. 2. Observe that the example uses GPIO0 (EPWM1_A) as the ECAP input pin. 3. Compare with the user guide which incorrectly references GPIO1 as the ECAP input.	Updated the ECAP module user guide to correctly document GPIO0 (EPWM1_A) as the ECAP input pin used in the example, aligning the documentation with the actual PORT configuration.
MCAL-38562	Cdd_Uart	S2-Major	CDD UART: Cdd_Uart_Deinit sets Cdd_Uart_IsInitialized to FALSE even when CDD_UART_E_BUSY is reported	C29xMCAL_26.00.00	When one or more UART HW units are busy (ongoing write/read transaction or non-empty FIFO), Cdd_Uart_Deinit reports CDD_UART_E_BUSY via DET but unconditionally sets Cdd_Uart_IsInitialized = FALSE at the end of the function. This causes the driver to appear uninitialized to all subsequent API callers even though the hardware was never properly de-initialized, preventing the application from cancelling the in-progress transaction and retrying Cdd_Uart_Deinit.	1. Initialize the UART driver by calling Cdd_Uart_Init. 2. Start a write transaction with a large buffer (> FIFO depth of 16 bytes). 3. Call Cdd_Uart_Deinit() while the write is still in progress — this unconditionally sets Cdd_Uart_IsInitialized = FALSE. 4. Observe that any subsequent API call (e.g., Cdd_Uart_Write) reports CDD_UART_E_UNINIT even though the driver was never properly de-initialized.	Fixed Cdd_Uart_Deinit to preserve the initialized state (Cdd_Uart_IsInitialized = TRUE) when Deinit is rejected due to busy units. Cdd_Uart_IsInitialized is now set to FALSE only when (FALSE == busyDetected), allowing the application to abort transactions and retry Cdd_Uart_Deinit as intended.
MCAL-40452	Can	S3-Minor	CAN: BASIC and FULL TX hardware object buffer ranges overlap when BASIC object index is lower than FULL object index	C29xMCAL_26.00.00, C29xMCAL_01.04.01, C29xMCAL_01.04.00, C29xMCAL_01.03.00, C29xMCAL_01.02.01, C29xMCAL_01.02.00	When at least one TX hardware object of type BASIC and at least one of type FULL are configured on the same CAN controller, and the index of the BASIC object is lower than the index of the FULL object, the hardware buffer ranges allocated for the FIFO (BASIC) and dedicated (FULL) buffers overlap. When both object types are configured in interrupt mode, some buffer elements may fail to complete transmission because interrupt enable bits and buffer-to-mailbox mappings are associated with an incorrect hardware buffer range.	1. Configure a CAN controller with at least one TX hardware object of type BASIC and at least one of type FULL, where the BASIC object index is lower than the FULL object index. 2. Configure both object types in interrupt mode. 3. Transmit messages using both BASIC and FULL objects. 4. Observe that some buffer elements fail to generate a transmission complete notification and subsequent transmissions are blocked.	Fixed the CAN driver to allocate hardware buffer indices for dedicated TX buffers and TX FIFO in software following the same order as the hardware: dedicated buffers are assigned the lower indices and the TX FIFO is assigned the higher indices. The FIFO interrupt enable bits and buffer-to-mailbox mappings are now computed based on this corrected allocation, ensuring all FIFO and dedicated buffer slots generate transmission complete interrupts without overlap.
MCAL-40501	Can	S3-Minor	CAN: TX FIFO buffer slot count mismatch in polling mode	C29xMCAL_26.00.00, C29xMCAL_01.04.01, C29xMCAL_01.04.00, C29xMCAL_01.03.00, C29xMCAL_01.02.01, C29xMCAL_01.02.00	In polling mode, the CAN driver only polls the first entry in the TX FIFO when checking for transmission completion, regardless of how many buffer slots are configured. All remaining FIFO buffer slots are never checked, leaving them permanently marked as busy and blocking any further CAN transmissions that attempt to use those slots.	1. Configure a CAN controller with a TX FIFO of more than one buffer slot in polling mode. 2. Transmit messages until all FIFO slots have been used at least once. 3. Observe that subsequent transmission requests are rejected with a busy status.	Fixed the CAN driver polling logic to iterate through all configured TX FIFO buffer slots when checking for transmission completion, ensuring every slot is correctly processed and released for subsequent use.

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
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	Issue occurs only if semaphore is already owned by CPU3 or another LINK on CPU1. However, the failure reported is the same as a true Flash hardware failure. Therefore, the application cannot distinguish between the two. It can re-initiate the Erase or Write job with the assumption that a semaphore claim failure resulted in the job failure. If the other CPU or LINK holding the semaphore relinquishes it, the job can proceed
MCAL-40515	Cdd_Uart	S3-Minor	CDD UART: Parity type selection (ODD/EVEN) not applied to hardware — UART_LCRH_EPS never written	C29xMCAL_26.00.00	When CddUartParityModeEnable = true is configured, the driver enables parity (UART_LCRH_PEN) but never writes the Even Parity Select bit (UART_LCRH_EPS). As a result, the hardware always uses odd parity regardless of the CddUartParityBit setting (CDD_UART_PARITY_EVEN or CDD_UART_PARITY_ODD). Applications that configure even parity will silently communicate with the wrong parity type, causing frame errors on the receiving peer.	1. Configure a CddUartConfig instance with CddUartParityModeEnable = true and CddUartParityBit = CDD_UART_PARITY_EVEN. 2. Generate code and build. 3. Connect the UART to a peer configured for even parity. 4. Observe parity errors on the peer — the F29H85x UART transmits with odd parity (hardware reset default).	Configure the peer device to use odd parity to match the hardware default. Avoid using CDD_UART_PARITY_EVEN until the fix is available.
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	When the SPI driver is configured for synchronous transmission at 20 MHz or above with the chip select pin set to SPIX_PTE (the SPI peripheral’s hardware Transmit Enable / chip select signal), the transfer fails and data is not received correctly. The same baudrate and configuration works correctly when chip select is managed via a DIO (GPIO) pin instead.	1. Configure the SPI driver with a baudrate of 20 MHz or above. 2. Set SpiCsSelection to the hardware CS option (SPIX_PTE) in the SPI configuration. 3. Call Spi_SyncTransmit() to initiate a synchronous transfer. 4. Observe that the SPI transfer fails — data is not received correctly.	Configure the chip select as a DIO (GPIO) pin (SpiCsSelection = CS_VIA_GPIO) instead of using the SPI peripheral’s hardware SPIX_PTE signal.

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

• CCS v20.05.00 or above version.

• C29Clang Compiler 2.2.0 LTS.

• EB Tresos (ACG 8.8.12)

• OpenSSL v3.x.x