AUTOSAR_SWS_MemoryDriver

六月 30, 2025

Specification of Memory Driver

Introduction and Functional Overview

This specification describes the functionality, API and the configuration for the AUTOSAR Basic Software module Memory Driver (Mem).

The Memory Driver provides the basic services for accessing different kinds of memory devices like reading, writing, erasing and blank checking.

Although flash memory is still the most common non-volatile memory technology, the Memory Driver specification considers all relevant memory device technologies like EEPROM, phase change memory (PCM) and ferro electric RAM. To harmonize the memory access for the upper layers, the Memory Driver specification also covers access of RAM. Aside from microcontroller internal memory devices, the Memory Device specification can also be applied to external memory devices attached, e.g. via a serial peripheral interface.

In contrast to the Flash and EEPROM Driver specification, the Memory Driver specification explicitly covers also code memory access to support new use cases like background OTA software update which require code memory access.

Figure 1.1 shows an example architectural overview with different Memory Drivers and upper layers:

Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the Mem driver that are not included in the [1, AUTOSAR glossary].

Physical Segmentation

Figure 2.1 gives an overview of the physical segmentation and the according technical terms:

Constraints and Assumptions

The following constraints apply for the Mem driver:

The Mem driver only works on physical segments, i.e. pages/page bursts and sectors/sector bursts for flash memory.

The Mem driver expects any requests to be aligned to the physical segmentation, i.e. pages and sectors for flash memory.

Due to this constraints, Mem drivers can only be used in combination with the Memory Access Module.

Limitations

General Limitations

Block based memory devices like NAND flash devices are out of scope of this specification.

Implementation Limitations

The following implementation limitations apply for the Mem driver:

The Mem driver does not provide any strategy for write accesses smaller than the physical segmentation, i.e. pages and sectors for flash memory since it does not use any internal buffers.

The Mem driver does not provide mechanisms for providing data integrity (e.g. checksums, redundant storage, etc.).

The size of Mem driver service requests is limited to 32-Bits to avoid a resource overhead for 32-Bit microcontroller.

Memory Test Capabilities

The Mem driver does not provide any general APIs for performing background memory tests since the memory test capabilities are very hardware dependent. To implement memory tests, the Mem driver's hardware specific request service API can be used.

Applicability to Car Domains

The Mem driver can be used in any domain application that needs memory access to either store data or perform a software update.

Dependencies to Other Modules

SPI Driver

Typically, external memory devices are connected via a serial bus like SPI (serial peripheral interface). To access such devices, a driver for the SPI peripheral in the microcontroller is needed to access the external memory device. Depending on the implementation of the Mem driver, the SPI driver might be part of the Mem driver or the Mem driver uses an existing MCAL SPI handler/driver.

Requirements Tracing

The following tables reference the requirements specified in [3], [4], [5] and [2] and links to the fulfillment of these. Please note that if column "Satisfied by" is empty for a specific requirement this means that this requirement is not fulfilled by this document.

Functional Specification

This chapter defines the behavior of the Mem driver. The API of the module is defined in chapter 8, while the configuration is defined in 10.

Overview

The Mem driver's task is the low level memory access based on the physical segmentation of the underlying memory device technology. The API of the Mem driver is memory device technology independent and thus provides a memory device agnostic interface to the Memory Access Module upper layer. All high level functionality like cross-segment operations are handled by the Memory Access Module to keep the complexity and the footprint of the Mem drivers as small as possible.

Key Aspects

Harmonized, memory device agnostic upper layer interface

Support of code memories

Multi instance support

Dynamic activation of Mem drivers

64-Bit device support

Support of optional memory services

Generic interface for providing memory device specific services

Functional Elements

Job Management

[SWS_Mem_00057]

[SRS_MemHwAb_14050]

A Mem driver instance shall allow only one job request at a time.

Note:

Since the MemAcc module takes care about the job management of the upper layer, there is no need to implement a job queue in the Mem driver.

[SWS_Mem_00059]

[SRS_MemHwAb_14050]

If the Mem driver is not able to process a job request, e.g. due to a pending request or due to an invalid parameter, the job request shall be rejected by an E_NOT_OK return code.

[SWS_Mem_00066]

[SRS_BSW_00172]

All job requests triggered by asynchronous Mem driver services shall be executed within the Mem_MainFunction.

[SWS_Mem_00063]

[SRS_MemHwAb_14040]

If the memory hardware provides ECC information, the Mem driver shall check for uncorrectable ECC errors and set the job result code to MEM_ECC_UNCORRECTED and abort the current job processing.

Job Status/Job Results

The Mem driver provides the Mem_GetJobResult service to retrieve the current job processing status as well as the result of the last processed job. Once a new job is processed, the result of the last processed job gets overwritten by the current status/result.

[SWS_Mem_00029]

[SRS_MemHwAb_14040]

The Mem driver shall keep track of the job processing and the result of the last processed job.

[SWS_Mem_00030]

[SRS_MemHwAb_14040]

Once a job request is accepted, the job processing status shall be set to MEM_JOB_PENDING.

[SWS_Mem_00067]

[SRS_MemHwAb_14040]

After a job was successfully processed, the job processing status shall be set to MEM_JOB_OK.

[SWS_Mem_00031]

[SRS_MemHwAb_14040]

In case a pending job was not able to complete, the job processing status shall be set to MEM_JOB_FAILED.

[SWS_Mem_00076]

[SRS_MemHwAb_14040]

In case the job processing was completed but the results of the last Mem job didn't meet the expected result, e.g. a blank check operation was applied on a non-blank memory area, the job result shall be set to MEM_INCONSISTENT.

[SWS_Mem_00077]

[SRS_MemHwAb_14040]

If the memory hardware supplies ECC information, the Mem driver shall check for correctable ECC errors and, in the case of correctable ECC errors, continue with the job processing. After completion of the job, the job result shall be set to MEM_ECC_CORRECTED.

[SWS_Mem_00078]

[SRS_MemHwAb_14040]

In case the last memory operation didn't complete due to an uncorrectable ECC error, the job result shall be set to MEM_ECC_UNCORRECTED.

Job Suspend/Resume

To reduce delays for prioritizing memory accesses, the Mem driver provides services for suspending/resuming memory operations.

[SWS_Mem_00082]

[SRS_MemHwAb_14031]

In case a memory device provides a hardware-based suspend/resume mechanism, the Mem driver shall utilize the hardware capabilities to implement the Mem_Suspend and Mem_Resume services. If no hardware suspend/resume support is available, the Mem_Suspend and Mem_Resume services shall return E_MEM_SERVICE_NOT_AVAIL.

Note:

For the hardware-based suspend/resume operation, it is expected, that the suspend/resume operation is completely handled by the memory hardware (no persistance of any state information needed in software, etc.) and there is no restriction regarding the intermediate operation that is issued while the device is in suspend state. If the hardware does not provide such features, prioritization is only possible based on the physical memory segmentation.

Hardware Specific Services

To support memory device specific services, Mem driver implementations can provide hardware specific services.

Figure 9.1 shows a typical use case for using a hardware specific service to implement a hardware specific error handling.

Multi Memory Device Instance Support

[SWS_Mem_00060]

[SRS_MemHwAb_14043]

The Mem driver implementation shall support multiple instances of the same memory device.

Note:

For the OTA software update use case, multiple memory devices of the same type are used to expand the memory resources.

Dynamic Driver Activation

To support use cases where the Mem driver shall not be permanently available, i.e. to prevent accidental overwriting of memory areas, the Mem driver shall provide measures that allow dynamic activation or download of Mem drivers.

There are two options to support this use case:

Download of a Mem driver binary image into RAM

Copy/decrypt a Mem driver ROM binary image into RAM

Both options require that the Mem driver is compiled as a separate binary. In case the Mem driver binary is part of the application image, the Mem driver binary image should to be encrypted, e.g. by a XOR operation and only be decrypted in RAM if the Mem driver shall be activated. The download or decryption operation of the Mem driver must be implemented as a CDD and is not covered by this specification.

To provide interoperability of different Mem driver implementations, the Mem drivers need to build according to standardized binary image format. The Mem driver binary image format is defined in chapter 7.2.6.

[SWS_Mem_00039]

[SRS_MemHwAb_14045]

If built as a separate image, the Mem driver shall be completely self contained, i.e. it must not call any library or any other external functions.

Note:

Since the Mem driver is running in a different context than it was built, it must not depend on any external functions or libraries. Therefore, the development error detection mechanisms is not available in case the Mem driver is built as a separate binary.

Service Invocation

[SWS_Mem_00038]

[SRS_MemHwAb_14045]

[SRS_MemHwAb_14049]

The Mem driver shall provide two ways for the service function invocation:

Direct service invocation

Indirect service invocation by a function pointer table

Note:

Some use cases like OTA background software update might require dynamic Mem driver activation using the indirect service invocation while simple use cases like NVM data storage want to use direct service invocation.

Direct Invocation

In case the Mem driver service functions are directly invoked, the Mem driver is linked with the application software and the Mem driver service functions are directly called by the MemAcc module.

Indirect Invocation

The indirect service invocation is needed for the dynamic driver activation feature described in chapter 7.2.4.

Binary Image Format

This chapter specifies the Mem driver binary image format. The binary image format is split into five parts:

Header, containing management information

Service function pointer table

Service function implementation

Delimiter

Figure 7.1 shows an overview of the Mem driver binary image:

[SWS_Mem_00040]

[SRS_MemHwAb_14045]

Since Mem drivers are always hardware/CPU specific, the byte order of data fields and address information within the Mem driver binary shall follow the standard CPU byte order.

Note:

Avoid unnecessary address/data format conversions.

Header

[SWS_Mem_00041]

[SRS_MemHwAb_14045]

[SRS_MemHwAb_14049]

The header part of the Mem driver binary shall follow the structure defined in table 7.1. The size of the address information depends on the configured MemAcc_AddressType (4 or 8 bytes).

Unique ID

[SWS_Mem_00042]

[SRS_MemHwAb_14045]

[SRS_MemHwAb_14049]

The unique identifier is used for unique identification of Mem drivers. The format of the unique identifier shall follow the structure defined in table 7.2.

[SWS_Mem_00043]

[SRS_MemHwAb_14045]

[SRS_MemHwAb_14049]

The ABI version of a Mem driver following this specification shall be 0001.

Header Address

[SWS_Mem_00044]

[SRS_MemHwAb_14045]

[SRS_MemHwAb_14049]

The header address is used for development error checks to verify the consistency of the linked Mem driver binary image with the location of the RAM buffer which is used for execution of the Mem driver. In case of a relocatable/position independent Mem driver binary, the header address shall be set to zero, otherwise, the header address shall hold the physical start address of the Mem driver binary.

Flags

[SWS_Mem_00045]

[SRS_MemHwAb_14045]

[SRS_MemHwAb_14049]

The flag part of the Mem driver header is a bit-field which holds additional information for develop error checks. The format of the flag bit-field shall follow the structure defined in table 7.3.

Delimiter Address

[SWS_Mem_00046]

[SRS_MemHwAb_14045]

[SRS_MemHwAb_14049]

The delimiter address part of the Mem driver header is used for development error checks to verify that the Mem driver binary is complete by checking the delimiter pattern linked to the end of the Mem driver binary. In case of a relocatable/position independent Mem driver binary, the delimiter address shall be set to zero, otherwise, the delimiter address shall hold the physical address of the delimiter pattern.

Service Function Pointer Table

[SWS_Mem_00073]

[SRS_MemHwAb_14045]

[SRS_MemHwAb_14049]

The function pointer table is a standardized structure used to reference the Mem driver service functions. The format of function pointer table shall follow the structure defined in table 7.4.

[SWS_Mem_00048]

[SRS_MemHwAb_14045]

[SRS_MemHwAb_14049]

The size of the Mem driver function pointers shall be machine/CPU specific.

Note:

The system integrator has to ensure to use the same memory model for the Mem driver and the MemAcc module.

Delimiter

The delimiter field marks the end of the Mem driver binary image. The format of the delimiter field shall follow the unique identifier defined in paragraph 7.2.6.1.1.

[SWS_Mem_00051]

[SRS_MemHwAb_14045]

[SRS_MemHwAb_14049]

The value of the delimiter field shall be the ones' complement of the unique identifier value.

Optional Services

Since not all Mem driver services are relevant for all memory device technologies, the Mem driver provides mechanisms to indicate to the MemAcc module which services are available.

Independent, if a service is relevant, the Mem driver shall provide all standard services as defined in chapter 8.3.

[SWS_Mem_00070]

[SRS_MemHwAb_14039]

In case a service is not relevant for a specific memory device technology, the service shall always return E_MEM_SERVICE_NOT_AVAIL.

Module Handling

Initialization

The Mem driver is initialized via Mem_Init. Except for Mem_GetVersionInfo, Mem_MainFunction and Mem_Init, the API functions of the Mem driver may only be called after the module has been properly initialized.

Scheduling

Since most of the Mem driver services are asynchronous services, the Mem_MainFunction needs to be cyclically triggered. Since Mem driver don't need to measure times or do any timing supervision, there is no need to call the Mem_MainFunction with a fixed cycle.

ECC Handling

Handling ECC errors is very hardware specific but typically a non-maskable interrupt is triggered by the ECC circuit. Dealing with ECC errors has to be done on a system level as the error reaction needs to be handled on system level as well.

To propagate memory ECC errors to the upper layer, the Mem driver provides the Mem_PropagateError API which can be called by the system ECC error handler to forward ECC errors.

Figure 9.2 shows an example ECC handling sequence to illustrate the usage of the Mem_PropagateError API.

General Design Rules

[SWS_Mem_00033]

[SRS_BSW_00323]

[SRS_BSW_00167]

[SRS_BSW_00004]

The Mem driver shall check static configuration parameters statically (at the latest during compile time) for correctness.

[SWS_Mem_00088]

[RS_BRF_01000]

The Mem driver shall not verify the result of a write or erase operation.

Note:

Consistency checks shall be implemented by the upper layers, e.g., by reading back the data or performing an explicit blank check.

Address Alignment

[SWS_Mem_00035]

[SRS_MemHwAb_14036]

The Mem driver shall not perform any sort of address or length alignment in case physical segmentation needs to be considered, e.g. for flash memory.

Note:

The MemAcc module takes care about alignment/splitting Mem service requests according to the configure physical segmentation.

64-Bit Support

[SWS_Mem_00036]

[SRS_MemHwAb_14046]

The Mem driver shall inherit the size of Mem_AddressType from MemAcc_AddressType to support memories larger than 4GBytes.

Note:

This requirement applies for all Mem drivers, independent if the physical memory size is less than 4GBytes.

[SWS_Mem_00037]

[SRS_MemHwAb_14046]

If the maximum physical memory size of a device does not exceed 4GBytes, the Mem driver shall perform an explicit cast and work internally with a 32-Bit address type.

Note:

Avoid resource overhead on 32-Bit microcontroller.

Error Classification

Development Error Types

[SWS_Mem_00052]

[SRS_BSW_00385]

The development error types defined for Mem are listed in table Table 7.5.

Transient Faults

[SWS_Mem_00065]{DRAFT}

[SRS_BSW_00452]

The Mem driver does not use transient faults. In case the memory device supports extended error checks, the Mem driver shall indicate them to the upper layer using the normal fault handling.

Note:

Simplify system design by just having one fault handling mechanism.

API Specification

[SWS_Mem_00074]

[SWS_BSW_00101]

[SWS_BSW_00102]

[SWS_BSW_00103]

[SWS_BSW_00171]

The Mem driver API names, type definitions and file naming scheme shall follow the standard AUTOSAR BSW Module implementation prefix with vendorId and vendorApiInfix.

Imported Types

In this chapter all types included from the following files are listed.

[SWS_Mem_10020]

[SRS_BSW_00415]

Type Definitions

Mem_AddressType

[SWS_Mem_10002]

[SRS_MemHwAb_14046]

Mem_ConfigType

[SWS_Mem_10000]

[SRS_BSW_00414]

Mem_DataType

[SWS_Mem_10003]

[SRS_MemHwAb_14051]

Mem_InstanceIdType

[SWS_Mem_10004]

[SRS_MemHwAb_14043]

Mem_JobResultType

[SWS_Mem_10019]

[SRS_MemHwAb_14040]

Mem_LengthType

[SWS_Mem_10007]

[SRS_MemHwAb_14046]

Mem_HwServiceIdType

[SWS_Mem_10026]

[SRS_MemHwAb_14042]

Function Definitions

Synchronous Functions

Mem_Init

[SWS_Mem_10008]

[SRS_MemHwAb_14037]

[SWS_Mem_00001]

[SRS_MemHwAb_14037]

[SRS_MemHwAb_14047]

The service Mem_Init shall initialize the Mem driver internal states and set the Mem driver job processing state to MEM_JOB_OK.

[SWS_Mem_00087]

[SWS_BSW_00050]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Init shall raise the development error MEM_E_PARAM_POINTER if the configPtr argument is not a NULL pointer.

Note:

The configuration pointer configPtr is currently not used and shall therefore be set to a NULL pointer value.

Mem_DeInit

[SWS_Mem_10018]

[SRS_MemHwAb_14037]

[SWS_Mem_00079]

[SRS_MemHwAb_14031]

The service Mem_DeInit shall cancel any ongoing flash operations in the hardware and de-initialize the Mem driver internal states.

Mem_GetVersionInfo

[SWS_Mem_10009]

[SRS_BSW_00003]

[SWS_Mem_00002]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_GetVersionInfo shall raise the development error MEM_E_PARAM_POINTER if the versionInfoPtr argument is a NULL pointer.

Mem_GetJobResult

[SWS_Mem_10011]

[SRS_MemHwAb_14040]

[SWS_Mem_00090]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_GetJobResult shall check that the provided instanceId is consistent with the configuration. If this check fails, Mem_GetJobResult shall raise the development error MEM_E_PARAM_INSTANCE_ID.

Mem_Suspend

[SWS_Mem_10024]{DRAFT}

[SRS_MemHwAb_14034]

[SWS_Mem_00080]

[SRS_MemHwAb_14031]

The service Mem_Suspend shall suspend any ongoing flash operations using an according hardware mechanism.

[SWS_Mem_00083]

[SRS_MemHwAb_14031]

In case a suspend operation is already in pending, Mem_Suspend shall reject the request by returning E_NOT_OK without further actions.

[SWS_Mem_00085]

[SRS_BSW_00406]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Suspend shall check that the Mem driver has been initialized. If this check fails, Mem_Suspend shall raise the development error MEM_E_UNINIT.

[SWS_Mem_00091]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Suspend shall check that the provided instanceId is consistent with the configuration. If this check fails, Mem_Suspend shall raise the development error MEM_E_PARAM_INSTANCE_ID.

Mem_Resume

[SWS_Mem_10025]{DRAFT}

[SRS_MemHwAb_14034]

[SWS_Mem_00081]

[SRS_MemHwAb_14031]

The service Mem_Resume shall resume a flash operations that was suspended by the service Mem_Suspend.

[SWS_Mem_00084]

[SRS_MemHwAb_14031]

In case no suspend operation is pending, Mem_Resume shall reject the request by returning E_NOT_OK without further actions.

[SWS_Mem_00086]

[SRS_BSW_00406]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Resume shall check that the Mem driver has been initialized. If this check fails, Mem_Resume shall raise the development error MEM_E_UNINIT.

[SWS_Mem_00092]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Resume shall check that the provided instanceId is consistent with the configuration. If this check fails, Mem_Resume shall raise the development error MEM_E_PARAM_INSTANCE_ID.

Mem_PropagateError

[SWS_Mem_10015]

[SRS_MemHwAb_14053]

[SWS_Mem_00019]

[SRS_BSW_00406]

If development error detection is enabled by MemDevErrorDetect, the service Mem_PropagateError shall check that the Mem driver has been initialized. If this check fails, Mem_PropagateError shall raise the development error MEM_E_UNINIT.

[SWS_Mem_00020]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_PropagateError shall check that the provided instanceId is consistent with the configuration. If this check fails, Mem_PropagateError shall raise the development error MEM_E_PARAM_INSTANCE_ID.

[SWS_Mem_00061]

[SRS_MemHwAb_14053]

If the Mem_PropagateError service is called, the Mem driver shall set the job result code to MEM_ECC_UNCORRECTED and cancel the current job processing.

Asynchronous Functions

Mem_Read

[SWS_Mem_10012]

[SRS_MemHwAb_14038]

[SRS_MemHwAb_14039]

[SWS_Mem_00003]

[SRS_BSW_00406]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Read shall check that the Mem driver has been initialized. If this check fails, Mem_Read shall raise the development error MEM_E_UNINIT.

[SWS_Mem_00004]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Read shall check that the provided instanceId is consistent with the configuration. If this check fails, Mem_Read shall raise the development error MEM_E_PARAM_INSTANCE_ID.

[SWS_Mem_00005]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Read shall raise the development error MEM_E_PARAM_POINTER if the destinationDataPtr argument is a NULL pointer.

[SWS_Mem_00006]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Read shall raise the development error MEM_E_PARAM_ADDRESS if the address defined by sourceAddress is invalid.

[SWS_Mem_00072]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Read shall raise the development error MEM_E_PARAM_LENGTH if the read length defined by length is invalid.

[SWS_Mem_00007]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Read shall raise the development error MEM_E_JOB_PENDING if a previous Mem job is still being processed.

Mem_Write

[SWS_Mem_10013]

[SRS_MemHwAb_14038]

[SRS_MemHwAb_14039]

[SWS_Mem_00008]

[SRS_BSW_00406]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Write shall check that the Mem driver has been initialized. If this check fails, Mem_Write shall raise the development error MEM_E_UNINIT.

[SWS_Mem_00009]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Write shall check that the provided instanceId is consistent with the configuration. If this check fails, Mem_Write shall raise the development error MEM_E_PARAM_INSTANCE_ID.

[SWS_Mem_00010]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Write shall raise the development error MEM_E_PARAM_POINTER if the sourceDataPtr argument is a NULL pointer.

[SWS_Mem_00011]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Write shall raise the development error MEM_E_PARAM_ADDRESS if the address defined by targetAddress is invalid.

[SWS_Mem_00012]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Write shall raise the development error MEM_E_PARAM_LENGTH if the write length defined by length is invalid.

[SWS_Mem_00013]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Write shall raise the development error MEM_E_JOB_PENDING if a previous Mem job is still being processed.

Mem_Erase

[SWS_Mem_10014]

[SRS_MemHwAb_14038]

[SRS_MemHwAb_14039]

[SWS_Mem_00014]

[SRS_BSW_00406]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Erase shall check that the Mem driver has been initialized. If this check fails, Mem_Erase shall raise the development error MEM_E_UNINIT.

[SWS_Mem_00015]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Erase shall check that the provided instanceId is consistent with the configuration. If this check fails, Mem_Erase shall raise the development error MEM_E_PARAM_INSTANCE_ID.

[SWS_Mem_00016]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Erase shall raise the development error MEM_E_PARAM_ADDRESS if the address defined by targetAddress is invalid.

[SWS_Mem_00017]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Erase shall raise the development error MEM_E_PARAM_LENGTH if the read length defined by length is invalid.

[SWS_Mem_00018]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_Erase shall raise the development error MEM_E_JOB_PENDING if a previous Mem job is still being processed.

Mem_BlankCheck

[SWS_Mem_10016]

[SRS_MemHwAb_14038]

[SRS_MemHwAb_14039]

[SWS_Mem_00021]

[SRS_BSW_00406]

If development error detection is enabled by MemDevErrorDetect, the service Mem_BlankCheck shall check that the Mem driver has been initialized. If this check fails, Mem_BlankCheck shall raise the development error MEM_E_UNINIT.

[SWS_Mem_00022]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_BlankCheck shall check that the provided instanceId is consistent with the configuration. If this check fails, Mem_BlankCheck shall raise the development error MEM_E_PARAM_INSTANCE_ID.

[SWS_Mem_00023]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_BlankCheck shall raise the development error MEM_E_PARAM_ADDRESS if the address defined by targetAddress is invalid.

[SWS_Mem_00024]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_BlankCheck shall raise the development error MEM_E_PARAM_LENGTH if the read length defined by length is invalid.

[SWS_Mem_00025]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_BlankCheck shall raise the development error MEM_E_JOB_PENDING if a previous Mem job is still being processed.

Mem_HwSpecificService

[SWS_Mem_10017]{DRAFT}

[SRS_MemHwAb_14038]

[SRS_MemHwAb_14039]

[SRS_MemHwAb_14056]

[SWS_Mem_00068]

[SRS_BSW_00406]

If development error detection is enabled by MemDevErrorDetect, the service Mem_HwSpecificService shall check that the Mem driver has been initialized. If this check fails, Mem_HwSpecificService shall raise the development error MEM_E_UNINIT.

[SWS_Mem_00026]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_HwSpecificService shall check that the provided instanceId is consistent with the configuration. If this check fails, Mem_HwSpecificService shall raise the development error MEM_E_PARAM_INSTANCE_ID.

[SWS_Mem_00027]

[SRS_BSW_00323]

If development error detection is enabled by MemDevErrorDetect, the service Mem_HwSpecificService shall raise the development error MEM_E_PARAM_POINTER if the dataPtr or lengthPtr argument is a NULL pointer.

Callback Notifications

There are no callback functions to lower layer modules provided by the Mem driver since this module is at the lowest (software) layer.

Scheduled Functions

Mem_MainFunction

[SWS_Mem_10010]

[SRS_MemHwAb_14038]

Expected Interfaces

In this chapter all interfaces required from other modules are listed.

Mandatory Interfaces

This section defines all interfaces, which are required to fulfill the core functionality of the module.

[SWS_Mem_10022]

[SRS_BSW_00415]

Optional Interfaces

This section defines all interfaces, which are required to fulfill an optional functionality of the module.

[SWS_Mem_10021]

[SRS_BSW_00415]

Sequence Diagrams

Hardware Specific Error Handling

ECC Handling Example Sequence

Configuration Specification

In general, this chapter defines configuration parameters and their clustering into containers. In order to support the specification chapter 10.1 describes fundamentals. It also specifies a template (table) you shall use for the parameter specification. We intend to leave chapter 10.1 in the specification to guarantee comprehension.

Chapter 10.2 specifies the structure (containers) and the parameters of the module MEM.

Chapter 10.3 specifies published information of the module MEM.