Dio User Guide


This document details AUTOSAR BSW DIO module implementation

  • Supported AUTOSAR Release : 4.3.1
  • Supported Configuration Variants : Pre-Compile & Link Time
  • Vendor ID : DIO_VENDOR_ID (44)
  • Module ID : DIO_MODULE_ID (120)

The DIO module provides interfaces to external peripherals by abstracting the input and output pins on the microcontroller device as detailed in the AUTOSAR BSW DIO Driver Specification. Following sections highlight key aspects of this implementation which would be of interest to an integrator.

Dio Driver Architecture/Design

Please refer the DIO design, which is included as part of release (Dio Design Document)

Functional Description

Pin Mapping

The DIO driver provides an interface to external peripherals by abstracting the input and output pins on the microcontroller device. The DIO pins are general purpose in nature. zz and TDA4x have multiple DIO driver instances.

32 Pins are grouped into a port and channelId corresponds to sequential number starting with 0 for wakeup domain 0 and pin 0.

TDA4x can support up to 11 instances. These instances are generally associated with specific domain, e.g. wakeup, main domains. The following diagram is from the device specific TRM.

DIO Typical Application:DRA80x

Pin Mapping for SOCs

Please refer to the SOC User Manual for detail.

Back To Top


The Dio Driver implementation supports multiple configuration variants (refer section Introduction), the driver expects generated Dio_Cfg.h to be present as (File Structure). Please refer (Build) to specify path to generated configuration. The associated dio driver configuration generated files Dio_Cfg.c and Dio_Lcfg.c to be present as show (File Structure)

The generated configuration files should not be modified manually. The config tool Elektrobit Tresos should be used to modify the configuration files.

The following section details on the un-supported features and additional features added.

Variance from the specification

Direct Read Back

As the microcontroller currently doesn't support direct read back, the AUTOSAR requirement pertaining to direct read back has not been implemented.

Back To Top


This structure contains all post-build configurable parameters of the DIO driver. As post-build configuration is not supported, this structure has not been used in this implementation.

Implementation Specific Configurations

This driver implementation introduces configurable options listed below

Back To Top


Name DioDeviceVariant
Description Used to specific family of devices, the variant of the device being used will belong one or more family of devices. Please refer (Supported Device Families) to determine the family of device. Based on the family, the number of instances of Dio module supported could vary.
Container Name DioGeneral
Type Enumeration
Range TDA4x, etc… (new family of devices could be added in future)
Value Configuration Class VARIANT-PRE-COMPILE

Back To Top


Description This is the event ID for Dem event in the Dio_WritePort() API
Container Name DioDemEventParameterRef
Value Configuration Class VARIANT-PRE-COMPILE

Back To Top


Description This is the event ID for Dem event in the Dio_WriteChannel() API.
Container Name DioDemEventParameterRef
Value Configuration Class VARIANT-PRE-COMPILE

Back To Top


Name DioRegisterReadbackApi

Adds / Removes service API DioRegisterReadbackApi ()

Safety feature : Check some of the critical registers (corruption of which
could potentially break functionality of the Dio)

The expected usage: Periodically this service API is invoked and
checked for data-consistency. i.e. the values of the registers checked
in this API are not expected to change.

Also refer (Dio_RegisterReadback)

Container Name DioGeneral
Type Boolean
Value Configuration Class VARIANT-PRE-COMPILE

Back To Top

Non Standard Service APIs


To protect HW from un-intended re-configuration (corrupted / fault hardware), some of the critical registers are read periodically and checked. By an entity outside the driver, the values of these registers are not expected to change. This is an optional service API, which can be turned OFF (refer section DioRegisterReadbackApi)

Description Comments
Service Name Dio_RegisterReadback Can potentially be turned OFF (Refer to Design Document provided in CSP)
Syntax Std_ReturnType Dio_RegisterReadback(Dio_ChannelType ChannelId, Dio_RegisterReadbackType *DioRegRbPtr) Returns critical DIO registers of associated DIO module
Service ID NA
Sync / Async Sync
Reentrancy Non Reentrant
Parameter in ChannelId Channel Identifier
Parameters out DioRegRbPtr A pointer of type Dio_RegisterReadbackType, which holds the read back register values
Return Value Standard unsigned integer E_OK or E_NOT_OK in case of NULL buffer pointer.

Back To Top

Interrupt Configuration

The Driver doesn’t register any interrupts handler (ISR), it is expected that consumer of this driver registers the required interrupt handler.

Back To Top


The driver doesn't configure the functional clock and power for the Dio modules. Its expected that SBL powers-up the required modules. Please refer SBL documentation.

Back To Top

Build and Running the Application

Please follow steps detailed in section (Build) to build library or example.

Back To Top

Steps to run example application

Please follow the steps detailed in section (Running Examples) to build and run example. Back To Top

Memory Mapping

Various objects of this implementation (e.g. variables, functions, constants) are defined under different sections. The linker command file at (Examples Linker File (Select memory location to hold example binary)) defines separate section for these objects. When the driver is integrated, its expected that these sections are created and placed in appropriate memory locations. (Locations of these objects depend on the system design and performance needs)


Back To Top


This driver implementation has been validated with cache enabled. For optimal performance it is recommended to place (Memory Mapping) sections in cache enabled memory area.

Back To Top

Dependencies on SW Modules


This implementation depends on the DET in order to report development errors and can be turned OFF. Refer section (Development Error Reporting) for detailed error codes.

Back To Top


This implementation requires 1 level of exclusive access to guard critical sections. Invokes SchM_Enter_Dio_DIO_EXCLUSIVE_AREA_0 (), SchM_Exit_Dio_DIO_EXCLUSIVE_AREA_0 () to enter critical section and exit.

In the example implementation (File Structure SchM_Dio.c) , all the interrupts on CPU are disabled.

Back To Top

File Structure

Detailed Directory Structure
  1. Driver implemented by : Dio.h , Dio.c, Dio_Priv.h
  2. Example Configuration by : Dio_Cfg.h , Dio_Cfg.c and Dio_Lcfg.c
  3. Example Application by : DioApp.c

Back To Top

Error Handling

Development Error Reporting

Development errors are reported to the DET using the service Det_ReportError(), when enabled. The driver interface (Dio.h File Structure) lists the SID

Back To Top

Error codes

Type of Error Related Error code Value (Hex)
Invalid channel name requested DIO_E_PARAM_INVALID_CHANNEL_ID 0x0A
Parameter is NULL Pointer DIO_E_PARAM_CONFIG 0x10
Invalid Port Nam3 DIO_E_PARAM_INVALID_PORT_ID 0x14
API parameter checking: invalid channel DIO_E_PARAM_INVALID_GROUP 0x1F

Back To Top

Production Code Error Reporting

Production error are reported to DEM via the service DEM_ReportErrorStatus(). In addition to standard errors, this implementation reports "DIO_WRITE_CHANNEL_EVENT_ID" and "DIO_WRITE_PORT_EVENT_ID" for DEM events in channel and port writes.

Back To Top

Safety Diagnostic Features

GPIO1 - Software test of function using I/O loopback

DIO module does not support a distinct I/O loopback mode. However, it is possible to support I/O checking using normal functionality. To do this software generates output and reads back and checks for the same value in the input registers. The DIO MCAL driver provides the API - Dio_WritePort() and Dio_ReadPort() to implement this diagnostic feature.

GPIO3 - Periodic Software Readback of Static Configuration Registers / GPIO4 - Software Readback of Written Configuration

Software Readback of Written Configuration ensures that the configuration register are written with the expected value. Periodic readback of configuration registers can provide a diagnostic for inadvertent writes to these registers.

The DIO MCAL driver provides the API - Dio_RegisterReadback() to readback static and written configuration registers to implement this diagnostic feature.

Back To Top

API Description

The AUTOSAR BSW Dio Driver specification details the APIs required for Dio Driver. Please refer to (Refer to Design Document provided in CSP) for detailed API description. Also refer to (Non Standard Service APIs) for non-standard APIs which are included in this implemented.

Refer API Documentation for details Back To Top

Example Application

The example application demonstrates use of Dio module, the list below identifies key steps performed the example. The configuration file is present at (File Structure)

  • Initializes “Result Status Flag”
  • DioApp_Startup ()
    • Initial Setup of Control Module registers : Unlocking the pad configuration registers
      • In the upper and lower 32-bits for the required partitions, the write lock key must be written with the designated key value before write-protected partition registers can be modified.
      • A check is performed to ensure that the partitions are unlocked.
    • Configuration of Control Module registers : Pin multiplexing
      • As multiple pins are multiplexed, it is necessary to select the desired pin by configuring the pad config registers
      • In the specific pad configuration registers following bits need to be updated:
        • MUXMODE : This selects the correct signal for MUX selection (DIO pin)
        • PULLUDEN : This is an active low signal to enable pullup/pulldown in pad mode (Disable by selecting 1U)
        • RXACTIVE : This is to enable the receiver (Enable by selecting 1U)
        • DS_PULLUD_EN : This is an active low signal to enable pullup/pulldown in deep sleep mode(Disable by selecting 1U)
        • By writing 0x08050007U to the specific pad config registers in the control module the above registers can be updated as mentioned.
      • Further details can be found under Device Configuration > Control Module in TRM.
    • Initialize the DIO module instance and ports to be used by the example application
      • Select the required instance of DIO module
      • The following bank registers for an instance to be initialized as follows:
        • Direction Register : direction of DIO pin for LED is set as output(can be set as input(1U) or output(0U) depending on use case)
        • Set Output Drive State Register : initial value of output pin is updated with this register.
        • Clear Output Drive State Register : initial clearing value of output pin is updated with this register.
      • DIO relies on other entities to perform the above initialization steps.
  • DioApp_mainTest ()
    • Perform channel read/write confirm by checking the LED 18 ON EVM rev E2/3
    • Perform channel group read/write on initialized channel group
    • Perform port read/write on initialized ports
    • Perform flip channel on initialized channel
  • Checks for error status, stack corruption and prints result

Back To Top

Example Log

Sample Application - STARTS !!!

DIO MCAL Version Info
Vendor ID           : 44
Module ID           : 120
SW Major Version    : 0
SW Minor Version    : 1
SW Patch Version    : 0

Test A. Write and Read Channel
Channels written
Channel read DIO_PinLevel[0] = 0
Channel read DIO_PinLevel[1] = 1
Channel read DIO_PinLevel[2] = 0
DIO Service API Read-back Channel Succeeds !!!
Main Domain Channels written
Channel read DIO_PinLevel[0] = 0
Channel read DIO_PinLevel[1] = 1
Channel read DIO_PinLevel[2] = 0
DIO Service API Read-back Channel Main Domain Succeeds !!!

DIO Test A :Service API: Write/Read Channel completed

Test B. Write and Read Channel Group
DIO Service Read/Write Channel Group Read-back Succeeds !!!

DIO Test B : Service API : Write/Read Channel Group completed

Test C. Write and Read Port
DIO Service API Read-Back Port succeeds !!!
DIO Service API Read-Back Port Main Domain succeeds !!!

DIO Test C : Service API: Write/Read Port completed

Test D. Flip Channel
Pin Value Before Flip: 0
Pin Value After Flip: 1

DIO Test D : Service API: Flip Channel completed
Pin Value Before Flip: 1
Pin Value After Flip: 0

DIO Test D : Service API: Flip Channel Main Domain completed

Test E. Dio_RegisterReadback
DIO register readback compare Passed!!
DIO register readback compare Main Domain Passed!!

DIO Test E : Service API: Register Read-back completed
DIO Stack Usage: 784 bytes


DioApp: Sample Application - Completes successfully !!!


Back To Top

Document Revision History

Revision Date Author Description Status
0.1 10 Oct 2018 Vibha Pant First version Pending Review
0.2 22 Oct 2018 Vibha Pant Addressed review comments Approved
0.3 27 Dec 2018 Vibha Pant Pin Mux Information added Approved
0.4 16 Oct 2018 Sujith S Added Logs from J721E testing Approved
0.5 10 Jan 2020 Vibha Pant Modified Steps for Example App Approved
0.6 19 Jan 2020 Sunil M S Updates w.r.o porting AUTOSAR 4.3.1 Version Approved
0.7 02 Nov 2020 Nikki S J7200 updated Approved
0.8 17 Mar 2022 Rohit T Removed J721E & J7200 specific contents Approved
0.9 08 Dec 2022 Subham Swain Adding instances specific to J7AEP Approved