EEPROM Abstraction (Ea)
Provides uniform access to external and internal EEPROM devices.
Funktionen — Übersicht
void Ea_Init (const Ea_ConfigType* ConfigPtr);Initializes the EEPROM abstraction module.void Ea_SetMode (MemIf_ModeType Mode);Function to switch the mode of the underlying EEPROM DriverStd_ReturnType Ea_Read (uint16 BlockNumber, uint16 BlockOffset, uint8* DataBufferPtr, uint16 Length);Reads Length bytes of block Blocknumber at offset Block Offset into the buffer Data Buffer Ptr.Std_ReturnType Ea_Write (uint16 BlockNumber, const uint8* DataBufferPtr);Writes the contents of the Data Buffer Ptr to the block Block Number.void Ea_Cancel (void);Cancels the ongoing asynchronous operation.MemIf_StatusType Ea_GetStatus (void);Service to return the Status.MemIf_JobResultType Ea_GetJobResult (void);Service to return the Job Result.Std_ReturnType Ea_InvalidateBlock (uint16 BlockNumber);Invalidates the block Block Number.void Ea_GetVersionInfo (Std_VersionInfoType* VersionInfoPtr);Service to get the version information of this module.Std_ReturnType Ea_EraseImmediateBlock (uint16 BlockNumber);Erases the block Block Number.void Ea_JobEndNotification (void);Service to report to this module the successful end of an asynchronous operation.void Ea_JobErrorNotification (void);Service to report to this module the failure of an asynchronous operation.void Ea_MainFunction (void);Service to handle the requested jobs and the internal management operations.void NvM_JobEndNotification (void);Function to be used by the underlying memory abstraction to signal end of job without error.void NvM_JobErrorNotification (void);Function to be used by the underlying memory abstraction to signal end of job with error.
Typen — Übersicht
struct Ea_ConfigTypeConfiguration data structure of the Ea module.
Funktionen & Typen — Detailansicht
function Ea_Init [SWS_Ea_00084] 📄 PDF
void Ea_Init (const Ea_ConfigType* ConfigPtr);
Initializes the EEPROM abstraction module.
The function Ea_Init serves to initialize the EEPROM Abstraction module ([SWS_Ea_00084]). It is provided via the header file Ea.h and puts the module into the operational state ([SWS_Ea_00084]).
According to the interface specification in [SWS_Ea_00084], the following properties and constraints apply to the call:
- Semantics and Service ID: The call is performed synchronously. The service ID
0x00is assigned to the service. - Reentrancy: The function is specified as non-reentrant (Non Reentrant) and therefore must not be executed concurrently.
- Parameters:
ConfigPtr(typeconst Ea_ConfigType*) serves as the input parameter, which references the selected configuration data set. There are neither input/output nor output parameters. - Return value: The function returns no return value (
void).
Regarding the call context, this entry contains no explicit specifications; initialization is typically expected to take place centrally during the startup phase of the ECU before other module functions are executed. Question Q-b2b40930e5fd0ee7 (open) Specific error codes, reactions in case of error, or notifications to DET and DEM are not listed in [SWS_Ea_00084].
This text was generated by an AI based on the AUTOSAR specification R20-11.
Implementer's Guide to follow (complexity I1)
function Ea_SetMode [SWS_Ea_00085] 📄 PDF
void Ea_SetMode (MemIf_ModeType Mode);
Function to switch the mode of the underlying EEPROM Driver
Usage and Semantics
The function Ea_SetMode serves to switch the operating mode of the underlying EEPROM driver ([SWS_Ea_00085]). It accepts the requested mode Mode of type MemIf_ModeType as an input parameter ([SWS_Ea_00085]). The function has no return value (void) and is available with the service ID 0x01 via the header file Ea.h ([SWS_Ea_00085]).
Execution is asynchronous (Asynchronous), so that the actual switching of the driver continues to be processed in the background after the call ([SWS_Ea_00085]).
Concurrency and Limitations
-
Reentrancy: The function is specified as non-reentrant (
Non Reentrant) ([SWS_Ea_00085]). Concurrent calls from different tasks or contexts must be prevented on the caller side. -
Call Context and Parameters: No input/output or pure output parameters may be passed; only the input parameter
Modeis provided ([SWS_Ea_00085]).
This text was created by an AI based on the AUTOSAR specification.
Implementer's Guide to follow (complexity I1)
function Ea_Read [SWS_Ea_00086] 📄 PDF
Std_ReturnType Ea_Read (uint16 BlockNumber, uint16 BlockOffset, uint8* DataBufferPtr, uint16 Length);
Reads Length bytes of block Blocknumber at offset Block Offset into the buffer Data Buffer Ptr.
Usage and Semantics
The function Ea_Read serves to read out user data from a specified logical EEPROM block via header Ea.h [SWS_Ea_00086]. Parameter Block Number addresses the logical block, which simultaneously determines its start address in the EEPROM [SWS_Ea_00086]. Parameter Block Offset defines the relative read offset within the block, while Length defines the number of bytes to be read [SWS_Ea_00086]. The destination data are written to the buffer referenced by Data Buffer Ptr [SWS_Ea_00086].
The call behaves asynchronously (Asynchronous): The return value E_OK signals exclusively that the EA module has accepted the job request, whereas E_NOT_OK indicates a rejection of the job [SWS_Ea_00086]. Interpretation: Since data transmission takes place asynchronously in the background, the referenced buffer likely needs to be provided unchanged and valid until full execution of the job. Question Q-34c9b29f373bd6cf (open)
Concurrency and Limitations
The interface is specified as non-reentrant (Non Reentrant) [SWS_Ea_00086]. Parallel calls from different execution contexts are consequently not permissible and must be synchronized on the caller side.
This usage note was generated automatically based on specification R20-11.
function Ea_Write [SWS_Ea_00087] 📄 PDF
Std_ReturnType Ea_Write (uint16 BlockNumber, const uint8* DataBufferPtr);
Writes the contents of the Data Buffer Ptr to the block Block Number.
The function Ea_Write initiates the asynchronous writing of data from a buffer to a logical EEPROM block [SWS_Ea_00087]. It is declared via the header file Ea.h and has the service ID 0x03 [SWS_Ea_00087].
Parameters and Return Value
BlockNumber(input,uint16): Designates the number of the logical block and simultaneously represents its start address in the EEPROM [SWS_Ea_00087].DataBufferPtr(input,const uint8*): Pointer to the buffer that contains the data to be written [SWS_Ea_00087].- Return value (
Std_ReturnType):E_OKindicates that the write job was accepted by the EA module for execution;E_NOT_OKmeans that the request was rejected [SWS_Ea_00087].
Concurrency and Limitations
The function is specified as non-reentrant (Non Reentrant) [SWS_Ea_00087]. Therefore, concurrent calls presumably must not occur uncoordinated without prior external synchronization. Question Q-a52fbcca6963c760 (open) Since the write process is executed asynchronously (Asynchronous) [SWS_Ea_00087], the caller will presumably need to keep the provided buffer DataBufferPtr unchanged in memory until complete termination of the job. Specific DET or DEM error codes are not named in the specification excerpt of the function.
This usage note was generated by an AI based on the specification of AUTOSAR Release R20-11.
function Ea_Cancel [SWS_Ea_00088] 📄 PDF
void Ea_Cancel (void);
Cancels the ongoing asynchronous operation.
The function Ea_Cancel aborts a currently running asynchronous operation of the EEPROM Abstraction module ([SWS_Ea_00088]). The service is provided via the header file Ea.h and has the service ID 0x04 ([SWS_Ea_00088]).
Regarding the calling behavior and the interface definition, the following characteristics apply ([SWS_Ea_00088]):
- Semantics: The call itself is synchronous (
Synchronous), although it aborts an ongoing asynchronous operation ([SWS_Ea_00088]). - Parameters and Return: The signature is
void Ea_Cancel(void). The function expects neither input, output, nor transfer parameters and has no return value ([SWS_Ea_00088]). - Reentrancy: The interface is defined as non-reentrant (
Non Reentrant) ([SWS_Ea_00088]). Consequently, it must not be called concurrently from multiple execution contexts or interrupting tasks.
Since Ea_Cancel does not accept job or block identifiers, the cancellation refers directly to the asynchronous overall operation currently being processed ([SWS_Ea_00088]). Specific error codes or feedback to detection mechanisms are not included in the specification data. Presumably, the call is typically performed by upper layers such as the Memory Abstraction Interface (MemIf) in order to terminate lengthy read, write, or erase operations prematurely in a targeted manner. Question Q-e441cbf6a5097568 (open)
This text was generated by an AI based on the AUTOSAR specification R20-11.
function Ea_GetStatus [SWS_Ea_00089] 📄 PDF
MemIf_StatusType Ea_GetStatus (void);
Service to return the Status.
function Ea_GetJobResult [SWS_Ea_00090] 📄 PDF
MemIf_JobResultType Ea_GetJobResult (void);
Service to return the Job Result.
function Ea_InvalidateBlock [SWS_Ea_00091] 📄 PDF
Std_ReturnType Ea_InvalidateBlock (uint16 BlockNumber);
Invalidates the block Block Number.
use
The function Ea_InvalidateBlock serves to invalidate a block specified by the logical block number [SWS_Ea_00091]. It has the service ID 0x07 and is provided via the header file Ea.h [SWS_Ea_00091]. As an input parameter, it accepts Block Number of type uint16; this designates the logical block number and at the same time indicates the start address of the respective block in the EEPROM [SWS_Ea_00091]. Input/output parameters or pure output parameters are not defined for this service [SWS_Ea_00091].
The call is executed as an asynchronous operation (Asynchronous) [SWS_Ea_00091]. A return value E_OK of type Std_ReturnType confirms to the caller that the EA module has accepted the job request for further processing [SWS_Ea_00091].
Error handling
If the EA module could not accept the requested job, the error value E_NOT_OK is returned [SWS_Ea_00091]. According to the specification, however, this return of E_NOT_OK occurs exclusively when DET is enabled [SWS_Ea_00091].
Concurrency and Limitations
The interface is specified as non-reentrant (Non Reentrant) [SWS_Ea_00091]. Interpretation: Callers are therefore presumably not allowed to call the function in parallel or in an interrupting manner, since no module-side reentrancy is guaranteed [SWS_Ea_00091]. Question Q-81d805517d2eac88 (open)
This usage note was generated automatically based on the specification of AUTOSAR Classic R20-11.
function Ea_GetVersionInfo [SWS_Ea_00092] 📄 PDF
void Ea_GetVersionInfo (Std_VersionInfoType* VersionInfoPtr);
Service to get the version information of this module.
function Ea_EraseImmediateBlock [SWS_Ea_00093] 📄 PDF
Std_ReturnType Ea_EraseImmediateBlock (uint16 BlockNumber);
Erases the block Block Number.
The function Ea_EraseImmediateBlock serves to erase a logical block in the EEPROM according to [SWS_Ea_00093].
- Usage and Semantics: The call is asynchronous ([SWS_Ea_00093]). Via the input parameter
Block Number, the number of the logical block is passed, which also designates the start address of this block in the EEPROM ([SWS_Ea_00093]). The return value is of typeStd_ReturnType:E_OKsignals that the requested job was accepted by the module ([SWS_Ea_00093]). - Error Handling: If the Default Error Tracer (DET) is enabled, the function returns
E_NOT_OKif the job could not be accepted by the EA module ([SWS_Ea_00093]). If DET is not enabled, according to the wording of the specification, noE_NOT_OKis expected to be returned in the event of an error. Question Q-5015a2135dbd4723 (open) - Concurrency and Constraints: The function is specified as non-reentrant (Non Reentrant) ([SWS_Ea_00093]). Callers must therefore ensure that parallel or overlapping calls are avoided. The declaration is available via the header file
Ea.h, and the service ID is0x09([SWS_Ea_00093]).
This text was created by an AI based on the AUTOSAR specification.
function Ea_JobEndNotification [SWS_Ea_00094] 📄 PDF
void Ea_JobEndNotification (void);
Service to report to this module the successful end of an asynchronous operation.
The function Ea_JobEndNotification serves to notify the module Ea of the successful completion of a previously initiated asynchronous operation [SWS_Ea_00094]. The interface is provided via the header Ea.h and has the service ID 0x10 [SWS_Ea_00094].
With regard to semantics and interface definition, the following properties apply according to [SWS_Ea_00094]:
- Signature and Parameters: The function expects no parameters (
void) and returns no return value (void). - Synchronicity: The call is processed synchronously.
- Error Handling: The interface exclusively reports successful completion; specific error codes or error messages are not defined for this notification in the element.
In terms of concurrency, Ea_JobEndNotification is specified as non-reentrant (Non Reentrant) [SWS_Ea_00094]. Callers must therefore ensure that no parallel or nested calls occur. Interpretation: The function is typically expected to be called by an underlying driver as soon as its asynchronous processing has finished, where the calling context presumably must ensure sequential execution without mutual preemption. Question Q-296b61b743e7c9b8 (open)
This usage note was generated by an AI based on the AUTOSAR R20-11 specification.
function Ea_JobErrorNotification [SWS_Ea_00095] 📄 PDF
void Ea_JobErrorNotification (void);
Service to report to this module the failure of an asynchronous operation.
The function Ea_JobErrorNotification serves as a notification interface to report the failure of a previously initiated asynchronous operation to the Ea module [SWS_Ea_00095]. It is available via the header file Ea.h and has the service ID 0x11 [SWS_Ea_00095].
With regard to interface specification and usage, the following properties apply:
- Parameters and return value: The function has neither pass-by parameters (neither in, out nor inout) nor a return value (signature
void Ea_JobErrorNotification(void)) [SWS_Ea_00095]. - Execution behavior and reentrancy: The call is processed synchronously, but is specified as non-reentrant (Non Reentrant) [SWS_Ea_00095]. Callers must therefore ensure that calls occur sequentially and do not overlap across parallel contexts.
- Interaction: Since the function signals the failure of an asynchronous job, the call is likely to be made typically by an underlying hardware abstraction module or a memory driver as soon as a job fails (interpretation). Question Q-810e76dee987a5a1 (open)
Specific error codes, development errors (DET), or production errors (DEM) are not defined for this service; separate error behavior for the call itself is not specified in the element.
This text was created by an AI. All technical statements are based exclusively on the specification data from AUTOSAR R20-11.
function Ea_MainFunction [SWS_Ea_00096] 📄 PDF
void Ea_MainFunction (void);
Service to handle the requested jobs and the internal management operations.
use
The function Ea_MainFunction serves to process requested jobs and handle internal management operations within the EEPROM Abstraction module [SWS_Ea_00096]. According to the interface definition void Ea_MainFunction(void), the function accepts no parameters and returns no return value to the caller [SWS_Ea_00096].
Call Context and Concurrency
The interface has the service ID 0x12 and is declared via the header file SchM_Ea.h [SWS_Ea_00096]. Interpretation: Due to its provision via SchM_Ea.h, the call is typically expected to occur cyclically by the schedule manager (BSW scheduler) in the task context in order to continuously continue the asynchronous processing of memory jobs in the background. Question Q-23f33a40a1e08c34 (open)
Error handling
Since Ea_MainFunction provides no return value, error states or job progress are not transmitted directly via the function call [SWS_Ea_00096]. Specific error codes as well as requirements for reporting to the development interface module (DET) or the diagnostic module (DEM) are not defined for this service in this specification extract.
This text was generated automatically. All information is based exclusively on the specification data of release R20-11.
function NvM_JobEndNotification [SWS_Ea_00099] 📄 PDF
void NvM_JobEndNotification (void);
Function to be used by the underlying memory abstraction to signal end of job without error.
Usage and Semantics
According to [SWS_Ea_00099], the callback function NvM_JobEndNotification serves the underlying memory abstraction to signal the successful end of a job without errors to upper-layer modules. The service has the signature void NvM_JobEndNotification(void); it expects neither input nor input/output parameters and returns no value [SWS_Ea_00099]. The execution is specified as synchronous, and the interface is provided via the header file NvM_MemIf.h [SWS_Ea_00099].
Concurrency and call conditions
Regarding runtime behavior, NvM_JobEndNotification is classified as non-reentrant (Non Reentrant) [SWS_Ea_00099]. Calling entities must therefore ensure that the notification is not called in an interrupting or parallel manner from multiple contexts. Interpretation: The memory abstraction layer is typically expected to execute the function within its cyclic main function or after completion of an asynchronous driver job as soon as it is established that the operation has ended without errors. Question Q-adabc07be0a3e7d2 (open)
Error Handling and Interaction
For this notification function, neither specific error codes nor development errors (DET) or production errors (DEM) are defined in [SWS_Ea_00099]. This is because the call exclusively indicates the error-free termination of a job [SWS_Ea_00099]. If an error occurs during a memory job, this notification is not called.
This text was generated by an AI based on the specification.
function NvM_JobErrorNotification [SWS_Ea_00100] 📄 PDF
void NvM_JobErrorNotification (void);
Function to be used by the underlying memory abstraction to signal end of job with error.
The notification function NvM_JobErrorNotification is used by the underlying memory abstraction (Memory Abstraction) to report the erroneous completion of a job to the NVRAM Manager [SWS_Ea_00100]. The declaration of this interface is provided via the header file NvM_MemIf.h [SWS_Ea_00100].
For calling and integrating the interface, the following properties apply according to specification [SWS_Ea_00100]:
-
Signature and Syntax: The function has the signature
void NvM_JobErrorNotification (void)[SWS_Ea_00100]. -
Parameters and Return Values: The function has neither input parameters (
Parameters (in): None), input/output parameters (Parameters (inout): None), nor output parameters (Parameters (out): None) and returns no value (Return value: None) [SWS_Ea_00100]. -
Synchronicity: The call is specified as synchronous (
Synchronous) [SWS_Ea_00100]. -
Concurrency: The function is specified as non-reentrant (
Non Reentrant) [SWS_Ea_00100]. Corresponding calls from the memory abstraction must therefore not occur concurrently or in an overlapping manner.
Specific error codes, parameters for error differentiation, or requirements for notifications to the Default Error Tracer (DET) or the Diagnostic Event Manager (DEM) module are not included in the definition [SWS_Ea_00100]. The function serves exclusively as a pure status report on the job result terminated with an error [SWS_Ea_00100].
This usage note was generated automatically and is based exclusively on the specification of AUTOSAR Classic R20-11.
type Ea_ConfigType [SWS_Ea_00190] 📄 PDF
Configuration data structure of the Ea module.
Request a governed re-review of this record. The record is not changed immediately.
- Record
AUTOSAR/AP/record/CP_MOD_Ea- Status
- unspecified
- Version
AUTOSAR/AP/record/CP_MOD_Ea@rel:R20-11#c220d147- Content hash
c220d147- Source
- https://www.autosar.org/fileadmin/standards/R20-11/CP/AUTOSAR_SWS_EEPROMAbstraction.pdf#nameddest=SWS_Ea_00084
gemini-3.8-flash-low· 2026-10-13 · German original