NvMCU_SwModules Changes#
NvMCU_SwModules is a set of ASIL D-compliant software modules, developed according to the classic AUTOSAR standard architecture. The modules are delivered as source code along with DriveOS releases.
Customer projects build the production binary for MCU after integrating the NvMCU-SwModules with the AUTOSAR stack from their preferred vendor and other third-party applications. The NvMCU_SwModules architecture is flexible for customer projects to develop applications depending on the choice of MCU hardware vendor and board design.
Hardware and Platform Details#
DriveOS Release Platform |
SoC |
MCU |
NvMCU_SwModules |
Notes |
|---|---|---|---|---|
DRIVE OS 6.5.x |
Orin |
Infineon TC397 |
MCU SW Modules as AUTOSAR CDDs |
|
DriveOS 7.0.x |
Thor |
Renesas RH850 |
New static architecture: MCU SW components grouped as AUTOSAR SWCs and IoHwAbs modules to support multiple MCU vendors |
|
DriveOS 7.2.x |
Thor |
Renesas RH850 |
Support for SOME/IP based communication over Ethernet between MCU and SoC |
|
Infineon TC4x |
MCU Communication Coordinator (MCC for DU and IST) removed for production builds |
In DriveOS 7.2, NvMCU_SwModules introduces a new modular architecture to support multiple MCU variants with the same SW. Basic platform functionalities support dual SoC board design, and a service-oriented communication approach is supported over Ethernet.
Static Architecture of NvMCU_SwModules in DOS 7.2#
The static architecture is upgraded to support multiple MCU variants (Renesas, Aurix TC4x, and so on). The software modules are pure application software components without dependencies on MCAL or low-level driver interfaces.
The components are decoupled from lower-layer dependencies (such as NvM and GPIO) by creating a new IoHwAbs module, NvMCU_CmnCDD, which abstracts the underlying hardware and exposes all interfaces to customer applications via RTE.
These changes influence the MCU source code and folder structure delivered with DriveOS. The SWC and file names are modified to represent “SoC” instead of “Orin” and “Thor”, and customer projects must adapt accordingly.
SWC Naming Changes#
SWC names in 6.5.x |
SWC names in 7.2.x |
|---|---|
NvMCU_[Orin]PwrCtrl |
NvMCU_[SoC]PwrCtrl |
NvMCU_[Orin]VMON |
NvMCU_[SoC]VMON |
NvMCU_[Orin]TMON |
NvMCU_[SoC]TMON |
NvMCU_BootChainCfg |
NvMCU_BootChainCfg |
NvMCU_ISTMgr |
NvMCU_ISTMgr |
MCU_FoH |
MCU_FoH |
NvMCU_CmnCDD |
Following is an example of the NvMCU_SwModules software architecture in DriveOS 7.2 when integrated with customer applications.
Ethernet Communication Between MCU and SoC (Guest VM)#
DriveOS 7.x provides a framework for safe and secure communication between MCU and guest VM on the SoC (CCPLEX) over Ethernet using SOME/IP as the standard service-oriented communication protocol over Ethernet/UDP. This replaces the proprietary Common-IF interface and simple UDP-based communication recommended in DRIVE OS 6.x, with reference use-cases such as BootChain selection and IST result communication.
SOME/IP implementation on QNX/Linux is provided in DriveOS 7.2 with ASIL QM classification, while the MCU-side implementation is supplied by AUTOSAR vendors as a standard package.
Customer projects must adapt their applications to use SOME/IP over Ethernet and can add safety and security hardening via E2E and SecOC on top of SOME/IP, with reference sequences provided in NvMCU_SwModules.
Interface Changes#
The following table summarizes key interface changes between releases 6.x and 7.2.
Modules in DRIVE OS 6.x |
Interfaces in DriveOS 7.2 |
Migration Rationale |
|---|---|---|
All modules |
Most interfaces are updated with an additional SoC identifier parameter |
Required to support dual SoC board designs |
All modules |
MCU_ErrHandler_ErrorNotify deprecated; MCU_ErrHandler_ReportResult (R_CS_IMCU_ErrHandler_Operations) used instead |
New interface reports both PASS and FAIL to indicate completion and healed errors |
NvMCU_OrinPwrCtrl |
New service NVMCU_SOCPWRCTRL_REQ_WAIT_SAFE_SHDN |
Allows shutdown without waiting for GPIO notification and interacts with force shutdown behavior |
NvMCU_OrinPwrCtrl |
NVMCU_SOCPWRCTRL_REQ_TRIG_SHDN deprecated and split into NVMCU_SOCPWRCTRL_REQ_WAIT_SAFE_SHDN and NVMCU_SOCPWRCTRL_REQ_PRE_PWROFF |
Refined control over shutdown sequencing |
NvMCU_OrinPwrCtrl |
NVMCU_SOCPWRCTRL_REQ_EXIT_SC7 deprecated; replaced by NVMCU_SOCPWRCTRL_REQ_WAIT_SC7_ENTRY and NVMCU_SOCPWRCTRL_REQ_VRS10_SLEEP |
Improved modeling of low-power transitions |
NvMCU_OrinTMON |
New interface TMON_Program_Threshold combining TMON_Program_ISTThreshold and TMON_Program_DefaultThreshold |
Simplifies configuration of temperature monitoring thresholds |
NvMCU_BootChainCfg |
New interface BootChainCfg_InitConfig |
Supports dual SoC boot-chain configuration |
MCU_FoH |
Interface changes |
Enables support for dual SoC board designs |
Software Changes Driven by the MCU Architecture#
DriveOS supports Renesas RH850 on Thor-based platforms from 7.0.x onwards, and the move from Aurix TC397 introduces several architectural differences that affect the MCU software design.
MCU Firmware Update#
Renesas RH850 memory supports double map mode, where flash is split into two logical banks so that a new firmware image can be programmed to the inactive bank while the active bank continues running, enabling seamless and safer firmware updates.
The MCU firmware update package leverages this double-bank feature to reduce the risk of system failures during in-field updates.
ADC-based Voltage Monitoring for Board Power Rails#
Renesas RH850 provides ADC hardware units with five scan groups per unit at different priority levels, so the monitoring strategy for board supply rails depends on the hardware configuration.
The reference Board VMON implementation in DriveOS 7.x for NvMCU_SwModules differs significantly from the Aurix TC397 design, and customer projects must update implementations accordingly.