AUTOSAR_SWS_EEPROMAbstraction

七月 02, 2025

Specification of EEPROM Abstraction

Introduction and functional overview

This specification describes the functionality, API and configuration of the EEPROM Abstraction Layer (see Figure 1).

The EEPROM Abstraction (EA) abstracts from the device specific addressing scheme and segmentation and provides the upper layers with a virtual addressing scheme and segmentation as well as a "virtually" unlimited number of erase cycles.

Acronyms and abbreviations

Acronyms and abbreviations which have a local scope and therefore are not contained in the AUTOSAR glossary must appear in a local glossary.

Dependencies to other modules

This module depends on the capabilities of the underlying EEPROM driver as well as the configuration of the NVRAM manager.

Requirements traceability

Functional specification

General behavior

[SWS_Ea_00137]

[SRS_MemHwAb_14001]

The EEPROM Abstraction (EA) shall only accept one job at a time, i.e. the module shall not provide a queue for pending jobs (that's the job of the NVRAM Manager).

Note:

Since the NvM is the only caller for this module and in order to keep this module reasonably small, the modules functions shall not check, whether the module is currently busy or not. It is the responsibility of the NvM to serialize the pending jobs and only start a new job after the previous one has been finished or canceled.

Addressing scheme and segmentation

The EEPROM Abstraction (EA) provides upper layers with a 32bit virtual linear address space and uniform segmentation scheme. This virtual 32bit addresses consists of

a 16bit block number - allowing a (theoretical) number of 65536 logical blocks

a 16bit block offset - allowing a (theoretical) block size of 64Kbyte per block

The 16bit block number represents a configurable (virtual) paging mechanism. The values for this address alignment can be derived from that of the underlying EEPROM driver and device. This virtual paging is configurable via the parameter EA_VIRTUAL_PAGE_SIZE.

[SWS_Ea_00075]

[SRS_MemHwAb_14001]

[SRS_MemHwAb_14005]

The configuration of the Ea module shall be such that the virtual page size (defined in EA_VIRTUAL_PAGE_SIZE) is an integer multiple of the physical page size, i.e. it is not allowed to configure a smaller virtual page than the actual physical page size.

Example:

The size of a virtual page is configured to be eight bytes, thus the address alignment is eight bytes. The logical block with block number 1 is placed at physical address x. The logical block with the block number 2 then would be placed at x+8, block number 3 would be placed at x+16.

Note:

This specification requirement allows the physical start address of a logical block to be calculated rather than making a lookup table necessary for the address mapping.

[SWS_Ea_00005]

[SRS_MemHwAb_14001]

Each configured logical block shall take up an integer multiple of the configured virtual page size (see also Chapter 10.2.3, configuration parameter EA_VIRTUAL_PAGE_SIZE).

Example:

If the virtual page size is configured to be eight bytes, logical blocks can be of size 8, 16, 24, 32, - bytes but not e.g. 10, 20, 50, - bytes.

[SWS_Ea_00068]

[SRS_MemHwAb_14001]

Logical blocks must not overlap each other and must not be contained within one another.

Example:

The address alignment / virtual paging is configured to be eight bytes by setting the parameter EA_VIRTUAL_PAGE_SIZE accordingly. The logical block number 1 is configured to have a size of 32 bytes (see Figure 2). This logical block would use exactly 4 virtual pages. The next logical block thus would get the block number 5, since block numbers 2, 3 and 4 are "blocked" by the first logical block. This second block is configured to have a size of 100 bytes, taking up 13 virtual pages and leaving 4 bytes of the last page unused. The next available logical block number thus would be 17.

[SWS_Ea_00006]

[SRS_MemHwAb_14026]

The block numbers 0x0000 and 0xFFFF shall not be configurable for a logical block (see chapter 10.2.3, EaBlockNumber for details).

Address calculation

[SWS_Ea_00007]

[SRS_MemHwAb_14009]

Depending on the implementation of the EA module and the exact address format used, the functions of the EA module shall combine the 16bit block number and 16bit block offset to derive the physical EEPROM address needed for the underlying EEPROM driver.

Note:

The exact address format needed by the underlying EEPROM driver and therefore the mechanism how to derive the physical EEPROM address from the given 16bit block number and 16bit block offset depends on the EEPROM device and the implementation of the EEPROM device driver and can therefore not be specified in this document.

[SWS_Ea_00066]

[SRS_MemHwAb_14005]

Only those bits of the 16bit block number, that do not denote a specific dataset or redundant copy shall be used for address calculation.

Note:

Since this information is needed by the NVRAM manager, the number of bits to encode this can be configured for the NVRAM manager with the parameter NVM_DATASET_SELECTION_BITS.

Example:

Dataset information is configured to be encoded in the four LSB's of the 16bit block number (allowing for a maximum of 16 datasets per NVRAM block and a total of 4094 NVRAM blocks). An implementer decides to store all datasets of a logical block directly adjacent and using the length of the block and a pointer to access each dataset. To calculate the start address of the block (the address of the first dataset) she/he uses only the 12 MSB's, to access a specific dataset she/he adds the size of the block multiplied by the dataset index (the four LSB's) to this start address (Figure 3).

Limitation of erase / write cycles

[SWS_Ea_00079]

[SRS_MemHwAb_14012]

The configuration of the Ea module shall define the expected number of erase/write cycles for each logical block in the configuration parameter EaNumberOfWriteCycles.

[SWS_Ea_00080]

[SRS_MemHwAb_14002]

If the underlying EEPROM device or device driver does not provide at least the configured number of erase/write cycles per physical memory cell (given in the parameter EepAllowedWriteCycles), the EA module shall provide mechanisms to spread the erase/ write access such that the physical device is not overstressed. This shall also apply to all management data used internally by the EA module.

Example:

The logical block number 1 is configured for an expected 500.000 write cycles, the underlying EEPROM device and device driver are only specified for 100.000 erase cycles. In this case the EA module has to provide (at least) five separate memory areas and alternate the access between those areas internally, so that each physical memory location is only erased for a maximum of the specified 100.000 cycles.

Handling of "immediate" data

Blocks, containing immediate data, have to be written instantaneously, i.e. such blocks shall be writable without the need, to first erase the corresponding memory area (e.g. by using pre-erased memory). An ongoing lower priority read / erase / write or compare job shall be canceled by the NVRAM manager before immediate data is written.

Note:

A running operation on the hardware (e.g. writing one page or erasing one sector) can usually not be aborted once it has been started. The maximum time of the longest hardware operation thus has to be accepted as delay even for immediate data.

Example:

Three blocks with 10 bytes each have been configured for immediate data. The EA module / configuration tool reserves these 30 bytes (plus the implementation specific overhead per block / page if needed) for use by this immediate data only. That is this memory area shall not be used for storage of other data blocks.

Now, the NVRAM manager has requested the EA module to write a data block of 100 bytes. While this block is being written a situation occurs that one (or several) of the immediate data blocks need to be written. Therefore the NVRAM manager cancels the ongoing write request and subsequently issues the write request for the (first) block containing immediate data. The cancelation of the ongoing write request is performed synchronously by the EA module and the underlying EEPROM driver that is the write request for the immediate data can be started without any further delay. However, before the first bytes of immediate data can be written, the EA module respectively the underlying EEPROM driver have to wait for the end of an ongoing hardware access from the previous write request (e.g. writing of a page, erasing of a sector, transfer via SPI, ...).

Managing block consistency information

[SWS_Ea_00046]

[SRS_MemHwAb_14014]

The Ea module shall manage for each block the information, whether this block is "correct" from the point of view of the EA module or not. This consistency information shall only concern the internal handling of the block, not the block's contents.

[SWS_Ea_00047]

[SRS_MemHwAb_14014]

When a block write operation is started the EA module shall mark the corresponding block as inconsistent1 . Upon the successful end of the block write operation, the EA module shall mark the block as consistent (again).

Note:

This internal management information should not be mixed up with the validity information of a block which can be manipulated by using the Ea_InvalidateBlock service, i.e. the EA module shall be able to distinguish between an inconsistent block and a block that has been deliberately invalidated by the upper layer.

Buffer Alignment

[SWS_Ea_00197]

[ ]

The Ea shall align internal buffers to the EaBufferAlignmentValueRef.

[SWS_Ea_00198]

[ ]

The Ea shall align read request to the EaMinimumReadPageSize.

Error classification

Development Errors

[SWS_Ea_91001]

[ ]

Runtime Errors

[SWS_Ea_91002]

[ ]

API specification

Imported Types

[SWS_Ea_00083]

[SRS_BSW_00392]

[SWS_Ea_00117]

[SRS_BSW_00392]

The types mentioned in SWS_Ea_00083 shall not be changed or extended for a specific EA module or hardware platform.

Type definitions

[SWS_Ea_00190]

[SRS_BSW_00414]

Function definitions

Ea_Init

[SWS_Ea_00084]

[SRS_BSW_00101]

[SWS_Ea_00191]

[SRS_BSW_00414]

The configuration pointer ConfigPtr shall always have a NULL_PTR value.

Note:

the Configuration pointer ConfigPtr is currently not used and shall therefore be set NULL_PTR value.

[SWS_Ea_00017]

[SRS_BSW_00101]

The function Ea_Init shall shall set the module state from MEMIF_UNINIT to MEMIF_BUSY_INTERNAL once it starts the module's initialization.

[SWS_Ea_00128]

[SRS_BSW_00406]

If initialization is finished within Ea_Init, the function Ea_Init shall set the module state from MEMIF_BUSY_INTERNAL to MEMIF_IDLE once initialization has been successfully finished.

Note:

The Ea module's environment shall not call the function Ea_Init during a running operation of the EA module.

Ea_Read

[SWS_Ea_00086]

[SRS_MemHwAb_14029]

[SWS_Ea_00021]

[SRS_MemHwAb_14007]

[SRS_MemHwAb_14009]

The function Ea_Read shall take the block number and offset and calculate the corresponding memory read address.

Note:

The address offset and length parameter can take any value within the given types range, this allows reading of an arbitrary number of bytes from an arbitrary address inside a logical block.

[SWS_Ea_00072]

[RS_BRF_01048]

The EA module shall execute the read operation asynchronously within the EA module's main function.

[SWS_Ea_00022]

[SRS_MemHwAb_14029]

If the current module status is MEMIF_IDLE or if the current module status is MEMIF_BUSY INTERNAL, the function Ea_Read shall accept the read request, copy the given / computed parameters to module internal variables, initiate a read job, set the EA module status to MEMIF_BUSY, set the job result to MEMIF_JOB_PENDING and return with E_OK.

[SWS_Ea_00179]

[SRS_MemHwAb_14029]

If the current module status is MEMIF_UNINIT or MEMIF_BUSY, the function Ea_Read shall reject the job request and return with E_NOT_OK.

[SWS_Ea_00130]

[SRS_BSW_00406]

If development error detection for the module EA is enabled: the function Ea_Read shall check if the module state is MEMIF_UNINIT. If this is the case, the function Ea_Read shall reject the read request, raise the development error EA_E_UNINIT and return with E_NOT_OK.

[SWS_Ea_00167]

[SRS_BSW_00323]

The function Ea_Read shall check if the module state is MEMIF_BUSY. If this is the case, the function Ea_Read shall reject the read request, raise the runtime error EA_E_BUSY and return with E_NOT_OK.

[SWS_Ea_00147]

[SRS_BSW_00323]

If development error detection is enabled for the module: the function Ea_Read shall check whether the given block number is valid (i.e. inside the configured range). If this is not the case, the function Ea_Read shall reject the read request, raise the development error EA_E_INVALID_BLOCK_NO and return E_NOT_OK.

[SWS_Ea_00168]

[SRS_BSW_00323]

If development error detection is enabled for the module: the function Ea_Read shall check that the given block offset is valid (i.e. that it is less than the block length configured for this block). If this is not the case, the function Ea_Read shall reject the read request, raise the development error EA_E_INVALID_BLOCK_OFS and return with E_NOT_OK.

[SWS_Ea_00169]

[SRS_BSW_00323]

If development error detection is enabled for the module: the function Ea_Read shall check that the given length information is valid, i.e. that the requested length information plus the block offset do not exceed the block end address (block start address plus configured block length). If this is not the case, the function Ea_Read shall reject the read request, raise the development error EA_E_INVALID_BLOCK_LEN and return with E_NOT_OK.

[SWS_Ea_00170]

[SRS_BSW_00323]

If development error detection is enabled for the module: the function Ea_Read shall check that the given data pointer is valid (i.e. that it is not NULL). If this is not the case, the function Ea_Read shall reject the read request, raise the development error EA_E_PARAM_POINTER and return with E_NOT_OK.

[SWS_Ea_00158]

[SRS_MemHwAb_14029]

[SRS_BSW_00323]

If a read request is rejected by the function Ea_Read, i.e. requirements SWS_Ea_00130, SWS_Ea_00147, SWS_Ea_00167, SWS_Ea_00168, SWS_Ea_00169, SWS_Ea_00170 or SWS_Ea_00179 apply, the function Ea_Read shall not change the current module status or job result.

Ea_Write

[SWS_Ea_00087]

[SRS_MemHwAb_14010]

[SWS_Ea_00024]

[SRS_MemHwAb_14006]

[SRS_MemHwAb_14009]

The function Ea_Write shall take the block number and calculate the corresponding memory write address. The block offset shall be fixed to zero for this address calculation.

[SWS_Ea_00151]

[SRS_MemHwAb_14010]

The function Ea_Write shall set the length parameter for the write job to the length configured for this logical block.

[SWS_Ea_00025]

[SRS_MemHwAb_14013]

If the current module status is MEMIF_IDLE or if the current module status is MEMIF_BUSY INTERNAL, the function Ea_Write shall accept the write request, copy the given / computed parameters to module internal variables, initiate a write job, set the EA module status to MEMIF_BUSY, set the job result to MEMIF_JOB_PENDING and return with E_OK.

[SWS_Ea_00181]

[SRS_MemHwAb_14010]

If the current module status is MEMIF_UNINIT or MEMIF_BUSY, the function Ea_Write shall reject the job request and return with E_NOT_OK.

[SWS_Ea_00026]

[RS_BRF_01048]

The EA module shall execute the write job of the function Ea_Write asynchronously within the EA module's main function.

[SWS_Ea_00131]

[SRS_BSW_00406]

If development error detection for the module EA is enabled: the function Ea_Write shall check if the module state is MEMIF_UNINIT. If this is the case, the function Ea_Write shall reject the write request, raise the development error EA_E_UNINIT and return with E_NOT_OK.

[SWS_Ea_00171]

[SRS_BSW_00406]

The function Ea_Write shall check if the module state is MEMIF_BUSY. If this is the case, the function Ea_Write shall reject the write request, raise the runtime error EA_E_BUSY and return with E_NOT_OK.

[SWS_Ea_00148]

[SRS_BSW_00323]

If development error detection for the module EA is enabled: the function Ea_Write shall check whether the given block number is valid (i.e. inside the configured range). If this is not the case, the function Ea_Write shall reject the write request, raise the development error EA_E_INVALID_BLOCK_NO and return with E_NOT_OK.

[SWS_Ea_00172]

[SRS_BSW_00323]

If development error detection is enabled for the module: the function Ea_Write shall check that the given data pointer is valid (i.e. that it is not NULL). If this is not the case, the function Ea_Write shall reject the write request, raise the development error EA_E_PARAM_POINTER and return with E_NOT_OK.

[SWS_Ea_00159]

[SRS_MemHwAb_14010]

[SRS_BSW_00323]

If a write request is rejected by the function Ea_Write, i.e. requirements SWS_Ea_00131, SWS_Ea_00171, SWS_Ea_00148, SWS_Ea_00172 or SWS_Ea_00181 apply, the function Ea_Write shall not change the current module status or job result.

Ea_Cancel

[SWS_Ea_00088]

[SRS_MemHwAb_14031]

[SWS_Ea_00132]

[SRS_BSW_00406]

If development error detection for the module EA is enabled: the function Ea_Cancel shall check if the module state is MEMIF_UNINIT. If this is the case, the function Ea_Cancel shall raise the development error EA_E_UNINIT and return to the caller without changing any internal variables.

[SWS_Ea_00077]

[SRS_MemHwAb_14031]

If the current module status is MEMIF_BUSY (i.e. the request to cancel a pending job is accepted by the function Ea_Cancel), the function Ea_Cancel shall call the cancel function of the underlying EEPROM driver.

[SWS_Ea_00078]

[SRS_MemHwAb_14031]

If the current module status is MEMIF_BUSY (i.e. the request to cancel a pending job is accepted by the function Ea_Cancel), the function Ea_Cancel shall reset the EA module's internal variables to make the module ready for a new job request. I.e. the function Ea_Cancel shall set the job result to MEMIF_JOB_CANCELED and the module status to MEMIF_IDLE.

[SWS_Ea_00160]

[SRS_MemHwAb_14031]

If the current module status is not MEMIF_BUSY (i.e. the request to cancel a pending job is rejected by the function Ea_Cancel), the function Ea_Cancel shall not change the current module status or job result.

[SWS_Ea_00173]

[SRS_BSW_00323]

If the current module status is not MEMIF_BUSY (i.e. there is no job to cancel and therefore the request to cancel a pending job is rejected by the function Ea_Cancel), the function Ea_Cancel shall raise the runtime error EA_E_INVALID_CANCEL.

Ea_GetStatus

[SWS_Ea_00089]

[RS_BRF_01048]

[SWS_Ea_00034]

[ ]

The function Ea_GetStatus shall return MEMIF_UNINIT if the module has not (yet) been initialized.

[SWS_Ea_00156]

[ ]

The function Ea_GetStatus shall return MEMIF_IDLE if the module is neither processing a request from the upper layer nor is it doing an internal management operation.

[SWS_Ea_00157]

[ ]

The function Ea_GetStatus shall return MEMIF_BUSY if it is currently processing a request from the upper layer.

[SWS_Ea_00073]

[ ]

The function Ea_GetStatus shall return MEMIF_BUSY_INTERNAL, if an internal management operation is currently ongoing.

Note:

Internal management operation may e.g. be a re-organization of the used EEPROM memory (garbage collection). This may imply that the underlying device driver is - at least temporarily - busy.

Ea_GetJobResult

[SWS_Ea_00090]

[RS_BRF_01048]

[SWS_Ea_00134]

[SRS_BSW_00406]

If development error detection for the module EA is enabled: the function Ea_GetJobResult shall check if the module state is MEMIF_UNINIT. If this is the case, the function Ea_GetJobResult shall raise the development error EA_E_UNINIT and return with MEMIF_JOB_FAILED.

[SWS_Ea_00035]

[SRS_BSW_00406]

The function Ea_GetJobResult shall return the status of the last job requested by the NVRAM manager.

[SWS_Ea_00174]

[RS_BRF_01048]

Only those jobs which have been requested directly by the upper layer shall have influence on the job result returned by the function Ea_GetJobResult. I.e. jobs which are issued by the EA module itself in the course of internal management operations shall not alter the job result.

Note:

To facilitate this, the EA module may have to implement a second set of local variables to store the data for internal jobs.

Note:

Internal management operations (e.g. "garbage collection") will only be invoked in the context of jobs requested from the NvM. Whether they have to be done before or after the requested job is the decision of the modules implementor and shall not be detailed in this specification.

Ea_InvalidateBlock

[SWS_Ea_00091]

[SRS_MemHwAb_14028]

[SWS_Ea_00036]

[SRS_MemHwAb_14009]

The function Ea_InvalidateBlock shall take the block number and calculate the corresponding memory block address.

[SWS_Ea_00037]

[SRS_MemHwAb_14028]

Depending on implementation, the function Ea_InvalidateBlock shall invalidate the block <BlockNumber> by either calling the erase function of the underlying device driver or changing some module internal management information accordingly.

Note:

How exactly the requested block is invalidated depends on the module's implementation and will not be further detailed in this specification. The internal management information has to be stored in NV memory since it has to be resistant against resets. What this information is and how it is stored is not further detailed by this specification.

[SWS_Ea_00135]

[SRS_BSW_00323]

If development error detection for the module Ea is enabled: the function Ea_InvalidateBlock shall check if the module state is MEMIF_UNINIT. If this is the case, the function Ea_InvalidateBlock shall reject the invalidation request, raise the development error EA_E_UNINIT and return with E_NOT_OK.

[SWS_Ea_00175]

[SRS_BSW_00323]

The function Ea_InvalidateBlock shall check if the module state is MEMIF_BUSY. If this is the case, the function Ea_InvalidateBlock shall reject the invalidation request, raise the runtime error EA_E_BUSY and return with E_NOT_OK.

[SWS_Ea_00194]

[SRS_MemHwAb_14028]

The function Ea_InvalidateBlock shall check if the module state is MEMIF_IDLE or MEMIF_BUSY_INTERNAL. If this is the case the module shall accept the invalidation request, set the Ea module status to MEMIF_BUSY, set the job result to MEMIF_JOB_PENDING and return E_OK to the caller.

[SWS_Ea_00195]

[RS_BRF_01812]

The Ea module shall execute the block invalidation request asynchronously within the Ea module's main function.

[SWS_Ea_00149]

[SRS_BSW_00323]

If development error detection for the module EA is enabled: the function Ea_InvalidateBlock shall check whether the given block number is valid (i.e. it has been configured). If this is not the case, the function Ea_InvalidateBlock shall reject the request, raise the development error EA_E_INVALID_BLOCK_NO and return with E_NOT_OK.

[SWS_Ea_00161]

[SRS_BSW_00323]

If an invalidation request is rejected by the function Ea_InvalidateBlock, i.e. requirements SWS_Ea_00135, SWS_Ea_00149 or SWS_Ea_00175 apply, the function Ea_InvalidateBlock shall not change the current module status or job result.

Ea_GetVersionInfo

[SWS_Ea_00092]

[SRS_BSW_00407]

[SWS_Ea_00164]

[SRS_BSW_00323]

If development error detection for the module EA is enabled: the function EA_GetVersionInfo shall check that the given data pointer is valid (i.e. that it is not NULL). If this is not the case, the function Ea_GetVersionInfo shall raise the development error EA_E_PARAM_POINTER.

Ea_EraseImmediateBlock

[SWS_Ea_00093]

[SRS_MemHwAb_14032]

Note:

The function Ea_EraseImmediateBlock shall only be called by e.g. diagnostic or similar system services to pre-erase the area for immediate data if necessary.

[SWS_Ea_00063]

[SRS_MemHwAb_14009]

[SRS_MemHwAb_14032]

The function Ea_EraseImmediateBlock shall take the block number and calculate the corresponding memory block address. The block offset shall be fixed to zero for this address calculation.

[SWS_Ea_00064]

[SRS_MemHwAb_14032]

The function Ea_EraseImmediateBlock shall ensure that the EA module can write immediate data. Whether this involves physically erasing a memory area and therefore calling the erase function of the underlying driver depends on the implementation.

[SWS_Ea_00136]

[SRS_BSW_00406]

If development error detection for the module EA is enabled: the function Ea_EraseImmediateBlock shall check if the module state is MEMIF_UNINIT. If this is the case, the function Ea_EraseImmediateBlock shall reject the erase request, raise the development error EA_E_UNINIT and return with E_NOT_OK.

[SWS_Ea_00176]

[SRS_BSW_00323]

The function Ea_EraseImmediateBlock shall check if the module state is MEMIF_BUSY. If this is the case, the function shall reject the erase request, raise the runtime error EA_E_BUSY and return with E_NOT_OK.

[SWS_Ea_00152]

[SRS_BSW_00323]

If development error detection for the module EA is enabled: the function Ea_EraseImmediateBlock shall check whether the given block number is valid (i.e. it has been configured). If this is not the case, the function Ea_EraseImmediateBlock shall reject the erase request, raise the development error EA_E_INVALID_BLOCK_NO and return with E_NOT_OK.

[SWS_Ea_00065]

[SRS_BSW_00323]

[SRS_MemHwAb_14032]

If development error detection for the EA module is enabled, the function Ea_EraseImmediateBlock shall check whether the addressed logical block is configured as containing immediate data (configuration parameter EaImmediateData == TRUE). If not, the function Ea_EraseImmediateBlock shall reject the erase request, raise the deleopment error EA_E_INVALID_BLOCK_NO and return with E_NOT_OK.

[SWS_Ea_00162]

[SRS_BSW_00323]

If an erase request for an immediate block is rejected by the function Ea_EraseImmediateBlock, i.e. requirements SWS_Ea_00136, SWS_Ea_00176, SWS_Ea_00152 or SWS_Ea_00065 apply, the function Ea_EraseImmediateBlock shall not change the current module status or job result.

Call-back notifications

This chaper lists all functions provided by the Ea module to lower layer modules.

Note:

Depending on the implementation of the modules making up the NV memory stack, callback routines provided by the EA module may be called on interrupt level. The implementation of the EA module therefore has to make sure that the runtime of those routines is reasonably short, i.e. since callbacks may be propagated upward through several software layers. Whether callback routines are allowable / feasible on interrupt level depends on the project specific needs (reaction time) and limitations (runtime in interrupt context). Therefore system design has to make sure that the configuration of the involved modules meets those requirements.

Ea_JobEndNotification

[SWS_Ea_00094]

[RS_BRF_01064]

The underlying EEPROM driver shall call the function Ea_JobEndNotification to report the successful end of an asynchronous operation.

[SWS_Ea_00153]

[RS_BRF_01064]

If the job result is currently MEMIF_JOB_PENDING, the function Ea_JobEndNotification shall set the job result to MEMIF_JOB_OK, else it shall leave the job result untouched.

[SWS_Ea_00051]

[RS_BRF_01064]

The function Ea_JobEndNotification shall perform any necessary block management operations and shall call the corresponding callback routine of the upper layer module (Ea_NvMJobEndNotification).

[SWS_Ea_00200]

[ ]

The function Ea_JobEndNotification shall perform any necessary block management and error handling operations and shall call the corresponding callback routine of the upper layer module (Ea_NvMJobErrorNotification).

Note:

The function Ea_JobEndNotification shall be callable on interrupt level.

Scheduled functions

These functions are directly called by the Basic Software Scheduler. The following functions shall have no return value and no parameter. All functions shall be non reentrant.

Ea_MainFunction

[SWS_Ea_00096]

[SRS_BSW_00373]

Note:

The cycle time for the function Ea_MainFunction should be the same as that configured for the underlying EEPROM driver.

[SWS_Ea_00178]

[SRS_BSW_00406]

If the module initialization (started in the function Ea_Init) is completed in the module's main function, the function Ea_MainFunction shall set the module status from MEMIF_BUSY_INTERNAL to MEMIF_IDLE once initialization of the module has been successfully finished.

[SWS_Ea_00056]

[RS_BRF_01048]

The function Ea_MainFunction shall asynchronously handle the read / write / erase / invalidate jobs requested by the upper layer and internal management operations.

[SWS_Ea_00074]

[SRS_MemHwAb_14028]

The function Ea_MainFunction shall check, whether the block requested for reading has been invalidated by the upper layer module. If so, the function Ea_MainFunction shall set the job result to MEMIF_BLOCK_INVALID and call the job error notification function if configured.

[SWS_Ea_00104]

[SRS_MemHwAb_14032]

[SRS_MemHwAb_14015]

[SRS_MemHwAb_14016]

The function Ea_MainFunction shall check the consistency of the logical block being read before notifying the caller. If an inconsistency of the block is detected (see SWS_Ea_00046 and SWS_Ea_00047) or if the requested block can't be found, the function Ea_MainFunction shall set the job result to MEMIF_BLOCK_INCONSISTENT and call the error notification routine of the upper layer if configured.

Note:

In this case the upper layer shall not use the contents of the data buffer.

[SWS_Ea_00188]

[SRS_MemHwAb_14014]

If an internal management operation has been suspended because of a job request from the upper layer, the function Ea_MainFunction shall resume this internal management operation once the job requested by the upper layer has been finished.

[SWS_Ea_00189]

[SRS_MemHwAb_14014]

If an internal management operation has been aborted because of a job request from the upper layer, the function Ea_MainFunction shall restart this internal management operation once the job requested by the upper layer has been finished.

Expected Interfaces

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

Mandatory Interfaces

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

[SWS_Ea_00097]

[RS_BRF_01056]

Optional Interfaces

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

[SWS_Ea_00098]

[RS_BRF_01056]

Configurable interfaces

In this chapter all interfaces are listed where the target function could be configured. The target function is usually a callback function. The names of this kind of interfaces are not fixed because they are configurable.

Note:

Depending on the implementation of the modules making up the NV memory stack, callback routines invoked by the EA module may be called on interrupt level.

The implementor of the module providing these routines therefore has to make sure that their runtime is reasonably short, i.e. since callbacks may be propagated upward through several software layers. Whether callback routines are allowable / feasible on interrupt level depends on the project specific needs (reaction time) and limitations (runtime in interrupt context). Therefore system design has to make sure that the configuration of the involved modules meets those requirements.

[SWS_Ea_00099]

[SRS_BSW_00385]

[SWS_Ea_00054]

[RS_BRF_01064]

The Ea module shall call the function defined in the configuration parameter EaNvMJobEndNotification upon successful end of an asynchronous read operation after performing all necessary internal management operations. Successful end of an asynchronous read operation implies the read job is finished and the result is OK.

[SWS_Ea_00141]

[RS_BRF_01064]

The Ea module shall call the function defined in the configuration parameter EaNvMJobEndNotification upon successful end of an asynchronous write operation after performing all necessary internal management operations. Successful end of an asynchronous write operation implies the write job is finished, the result is OK and the block has been marked as valid.

[SWS_Ea_00142]

[RS_BRF_01064]

The Ea module shall call the function defined in the configuration parameter EaNvMJobEndNotification upon successful end of an asynchronous erase operation after performing all necessary internal management operations. Successful end of an asynchronous erase operation implies the erase job for immediate data is finished and the result is OK (see SWS_Ea_00064).

[SWS_Ea_00143]

[RS_BRF_01064]

The Ea module shall call the function defined in the configuration parameter EaNvMJobEndNotification upon successful end of an asynchronous block invalidation operation after performing all necessary internal management operations. Successful end of an asynchronous block invalidation operation implies the block invalidation job is finished and the result is OK (i.e. the block has been marked as invalid).

[SWS_Ea_00100]

[SRS_BSW_00385]

[SWS_Ea_00055]

[RS_BRF_01064]

The Ea module shall call the function defined in the configuration parameter EaNvMJobErrorNotification upon failure of an asynchronous read operation after performing all necessary internal management and error handling operations. Failure of an asynchronous read operation implies the read job is finished and has failed (i.e. block invalid or inconsistent).

[SWS_Ea_00144]

[RS_BRF_01064]

The Ea module shall call the function defined in the configuration parameter EaNvMJobErrorNotification upon failure of an asynchronous write operation after performing all necessary internal management and error handling operations. Failure of an asynchronous write operation implies the write job is finished and has failed and block has been marked as inconsistent.

[SWS_Ea_00145]

[RS_BRF_01064]

The Ea module shall call the function defined in the configuration parameter EaNvMJobErrorNotification upon failure of an asynchronous erase operation after performing all necessary internal management and error handling operations. Failure of an asynchronous erase operation implies the erase job for immediate data is finished and has failed (see SWS_Ea_00064).

[SWS_Ea_00146]

[RS_BRF_01064]

The Ea module shall call the function defined in the configuration parameter EaNvMJobErrorNotification upon failure of an asynchronous block invalidation operation after performing all necessary internal management and error handling operations. Failure of an asynchronous block invalidation operation implies the block invalidation job is finished and has failed.

Sequence diagrams

Note:

For a vendor specific library the following sequence diagrams are valid only insofar as they show the relation to the calling modules (Ecu_StateManager resp. memory abstraction interface). The calling relations from a memory abstraction module to an underlying driver are not relevant / binding for a vendor specific library.

Ea_Init

The following figure shows the call sequence for the Ea_Init routine. It is different from that of all other services of this module as it is not called by the NVRAM manager and not called via the memory abstraction interface.

Ea_Write

The following figure shows as an example the call sequence for the Ea_Write service. This sequence diagram also applies to the other asynchronous services of this module.

Ea_Cancel

The following figure shows as an example the call sequence for a canceled Ea_Write service. This sequence diagram shows that Ea_Cancel is asynchronous w.r.t. the underlying hardware while itself being synchronous.