DEENESPTFRRUARHIKOZHNL

EEPROM Abstraction (Ea)

ModulEa (EEPROM Abstraction)
BSW-Modul-ID40
Standard-Header#include "Ea.h"
SWS-SpezifikationAUTOSAR_SWS_EEPROMAbstraction.pdf
ClusterMemory Services

Module guideAI-GENERATED

Maps logical memory blocks to EEPROM addresses and processes read and write jobs asynchronously.
AI-GENERATED unreviewed Model: claude-opus-5-5 · Effort: high · Temperature: not controllable · Prompt: 55a6c103b1ca Provenance Open questions (4)
Causal anchor: R20-11 Valid from R20-11 Synthesized for this specification release.
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

Maps logical memory blocks to EEPROM addresses and processes read and write jobs asynchronously.

The EEPROM Abstraction maps logical blocks of NvM to addresses of an EEPROM and uses the Eep driver in R20-11. Read, write, invalidation, and erase jobs are accepted synchronously and executed asynchronously in the cyclically called Main Function ([SWS_Ea_00096]). The module reports completion or failure via callback to NvM or via the job result. A write operation always affects the entire block. Only in R20-11 do Ea_SetMode and a synchronous Ea_Cancel still exist ([SWS_Ea_00088]).

The EEPROM Abstraction (Ea) maps logical blocks to EEPROM addresses. It is located between MemIf and the EEPROM driver Eep; the block number designates at the same time the start address of the block ([SWS_Ea_00087]). Downward, Ea in R20-11 uses the Eep services for reading, writing, erasing, cancelling, and mode switching ([SWS_Ea_00097]). Only starting with R21-11 does MemAcc replace the Eep driver and Ea_SetMode is omitted (SWS EA p. 1).

ea_kontext EcuM EcuM Ea Ea EcuM->Ea Ea_Init(ConfigPtr) SchM BSW Scheduler SchM->Ea Ea_MainFunction() Diag Diagnose-/Systemdienst Diag->Ea Ea_EraseImmediateBlock NvM NvM MemIf MemIf NvM->MemIf MemIf_Read / MemIf_Write / MemIf_Cancel / MemIf_SetMode MemIf->Ea Ea_Read, Ea_Write, Ea_Cancel, Ea_SetMode Ea->NvM NvM_JobEndNotification / NvM_JobErrorNotification Eep Eep Ea->Eep Eep_Read, Eep_Write, Eep_Erase, Eep_Cancel, Eep_SetMode, Eep_GetStatus, Eep_GetJobResult Det DET Ea->Det Det_ReportRuntimeError, Det_ReportError (optional) Eep->Ea Ea_JobEndNotification / Ea_JobErrorNotification

Context diagram: Ea between NvM/MemIf and Eep, initialized by EcuM and driven by the BSW Scheduler. Sources: [SWS_Ea_00084], [SWS_Ea_00096], [SWS_Ea_00097]

After Ea_Init with a pointer to the configuration set ([SWS_Ea_00084]), Ea_GetStatus reports one of the states MEMIF_IDLE, MEMIF_BUSY, or MEMIF_BUSY_INTERNAL ([SWS_Ea_00089]). The last one represents internal management such as garbage collection (SWS EA p. 28).

Read, write, invalidation, and immediate erase are asynchronous. E_OK only confirms that the job was accepted. Execution takes place in the cyclically called Ea_MainFunction ([SWS_Ea_00086], [SWS_Ea_00096]). Reading is possible with an arbitrary offset and arbitrary length. Writing always affects the entire block with offset zero (SWS EA p. 25). That the write job also starts in the Main Function is an interpretation.

write job via EaNvMMemIfEaEepBSW SchedulerUse Case: Auftragsannahme (synchron)MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr)Ea_Write(BlockNumber, DataBufferPtr)address from BlockNumber, offset 0length = configured block lengthBlock als inkonsistent markierenE_OKE_OKUse Case: Asynchrone AbarbeitungEa_MainFunction()Eep_Write(...)Assumption: driver job is started in Ea_MainFunctionloopbis Treiberauftrag beendetEep_MainFunction()Ea_JobEndNotification()Block als konsistent markierenJobergebnis MEMIF_JOB_OKNvM_JobEndNotification()

Sequence diagram: synchronous acceptance, asynchronous execution via Eep, and feedback via callback to NvM. Sources: SWS Eep p. 50, [SWS_Ea_00094], [SWS_Ea_00099]

Ea_Cancel is synchronous in R20-11 ([SWS_Ea_00088]). The module reports errors via the codes EA_E_UNINIT to EA_E_INVALID_CANCEL ([SWS_Ea_91001], [SWS_Ea_91002]). Depending on the configuration, hardware errors reach NvM via one of two paths:

  • via querying the job result MEMIF_JOB_FAILED,
  • via the callback NvM_JobErrorNotification.

Recovery is handled in each case by NvM (ErrorDescription p. 48).

Role in the Memory Stack: from Logical Block to EEPROM Address

The EEPROM Abstraction (Ea) is located in the memory stack between the Memory Abstraction Interface (MemIf) and the EEPROM driver (Eep). Toward the upper layer, it provides block-oriented services. The block number designates a logical block and at the same time its start address in the EEPROM ([SWS_Ea_00086], [SWS_Ea_00087]). MemIf forwards read and write jobs to the abstraction module selected by the parameter DeviceIndex and passes through its return value (SWS MemIf p. 18, SWS MemIf p. 19).

Downward, Ea in R20-11 uses the services of the EEPROM driver: Eep_Read, Eep_Write, Eep_Erase, Eep_Cancel, Eep_GetStatus, Eep_GetJobResult, and Eep_SetMode. In addition, there is Det_ReportRuntimeError ([SWS_Ea_00097]). Det_ReportError is an optional interface ([SWS_Ea_00098]). The imported types Eep_AddressType, Eep_LengthType, MemIf_StatusType, MemIf_JobResultType, and MemIf_ModeType reflect this embedding ([SWS_Ea_00083]).

Regarding release classification: According to the change history, Ea_SetMode is omitted starting with R21-11. In addition, Ea_Cancel becomes asynchronous, buffer alignment is added, and MemAcc replaces Eep as the lower layer (SWS EA p. 1). For R20-11, therefore, Eep as lower layer and Ea_SetMode as service still apply. The rules for buffer alignment (SWS EA p. 19) do not apply to R20-11.

ea_kontext EcuM EcuM Ea Ea EcuM->Ea Ea_Init(ConfigPtr) SchM BSW Scheduler SchM->Ea Ea_MainFunction() Diag Diagnose-/Systemdienst Diag->Ea Ea_EraseImmediateBlock NvM NvM MemIf MemIf NvM->MemIf MemIf_Read / MemIf_Write / MemIf_Cancel / MemIf_SetMode MemIf->Ea Ea_Read, Ea_Write, Ea_Cancel, Ea_SetMode Ea->NvM NvM_JobEndNotification / NvM_JobErrorNotification Eep Eep Ea->Eep Eep_Read, Eep_Write, Eep_Erase, Eep_Cancel, Eep_SetMode, Eep_GetStatus, Eep_GetJobResult Det DET Ea->Det Det_ReportRuntimeError, Det_ReportError (optional) Eep->Ea Ea_JobEndNotification / Ea_JobErrorNotification

Context diagram: Ea mediates between NvM/MemIf above and the driver Eep below. EcuM initializes the module, the BSW Scheduler drives it cyclically, and DET receives error reports. Sources: [SWS_Ea_00084], [SWS_Ea_00096], [SWS_Ea_00097], [SWS_Ea_00098], [SWS_Ea_00099], [SWS_Ea_00100], SWS EA p. 34

Startup and Module States

Ea_Init initializes the module synchronously and is non-reentrant. ConfigPtr points to the selected configuration set ([SWS_Ea_00084]). Ea_ConfigType is a structure with implementation-specific elements ([SWS_Ea_00190]). According to the sequence diagram in the specification, the ECU State Manager calls Ea_Init during startup (SWS EA p. 47). Since it is only a single call, it appears as a transition in the state diagram below.

Ea_GetStatus returns the operating state synchronously as MemIf_StatusType ([SWS_Ea_00089]):

  • MEMIF_UNINIT: Before initialization.
  • MEMIF_IDLE: neither a job nor internal management is running.
  • MEMIF_BUSY: An upper-layer job is being processed.
  • MEMIF_BUSY_INTERNAL: an internal management operation is running, such as a reorganization of the EEPROM memory (garbage collection). In doing so, the driver can also be temporarily busy.

The states are described in SWS EA p. 28. The module accepts a write job in the MEMIF_IDLE state and also in the MEMIF_BUSY_INTERNAL state (SWS EA p. 25).

ea_status start MEMIF_UNINIT MEMIF_UNINIT start->MEMIF_UNINIT MEMIF_IDLE MEMIF_IDLE MEMIF_UNINIT->MEMIF_IDLE Ea_Init(ConfigPtr) MEMIF_BUSY MEMIF_BUSY MEMIF_IDLE->MEMIF_BUSY Auftrag angenommen (Ea_Read, Ea_Write, ...) MEMIF_BUSY_INTERNAL MEMIF_BUSY_INTERNAL MEMIF_IDLE->MEMIF_BUSY_INTERNAL interne Verwaltung startet (z. B. Garbage Collection) MEMIF_BUSY->MEMIF_IDLE job finished (success/error) or Ea_Cancel MEMIF_BUSY_INTERNAL->MEMIF_IDLE interne Verwaltung beendet MEMIF_BUSY_INTERNAL->MEMIF_BUSY Ea_Write angenommen

State diagram: Life cycle of the module status from MEMIF_UNINIT via MEMIF_IDLE to MEMIF_BUSY and MEMIF_BUSY_INTERNAL, respectively. A write job is accepted from within internal management. Sources: [SWS_Ea_00084], [SWS_Ea_00089], SWS EA p. 28, SWS EA p. 25, SWS EA p. 27

Accepting Jobs and Processing Them in Ea_MainFunction

Ea_Read, Ea_Write, Ea_InvalidateBlock, and Ea_EraseImmediateBlock are asynchronous. E_OK only means that the module has accepted the job. E_NOT_OK means that it has rejected it ([SWS_Ea_00086], [SWS_Ea_00087], [SWS_Ea_00091], [SWS_Ea_00093]). Until the result is available, Ea_GetJobResult reports the value MEMIF_JOB_PENDING ([SWS_Ea_00090]).

The actual work is performed by Ea_MainFunction, available via SchM_Ea.h ([SWS_Ea_00096]). The Basic Software Scheduler calls the function directly. It has neither parameters nor a return value and is not reentrant (SWS EA p. 36).

ea_annahme start d1 Modul initialisiert? (Status ≠ MEMIF_UNINIT) start->d1 d2 Status MEMIF_BUSY? d1->d2 yes e1 report EA_E_UNINIT return E_NOT_OK d1->e1 no d3 block number, offset, length, pointer valid? d2->d3 no (IDLE or BUSY_INTERNAL) e2 report EA_E_BUSY return E_NOT_OK d2->e2 yes e3 report EA_E_INVALID_BLOCK_NO / _OFS / _LEN or EA_E_PARAM_POINTER return E_NOT_OK d3->e3 no ok accept parameters status MEMIF_BUSY job result MEMIF_JOB_PENDING return E_OK d3->ok yes mf Abarbeitung in Ea_MainFunction ok->mf hinweis Assumption: order of checks hinweis->d1 betrifft

Activity diagram: Checks upon accepting a job and their error codes. The checking order is an assumption. Sources: [SWS_Ea_91001], [SWS_Ea_91002], [SWS_Ea_00089], [SWS_Ea_00090], SWS EA p. 25

Ea_Read calculates the read address from the block number and offset. Offset and length may take any value within their type range, allowing any number of bytes to be read from any position in the block. The read operation explicitly executes asynchronously in the Main Function (SWS EA p. 24).

Ea_Write calculates the write address from the block number with a fixed offset of zero. The function sets the length to the length configured for the block (SWS EA p. 25). A write operation therefore always affects the entire block ([SWS_Ea_00087]). The diagram for the write job shows the further path via Eep_Write, the cyclic Eep_MainFunction, Ea_JobEndNotification, and NvM_JobEndNotification (SWS Eep p. 50).

Interpretation: For reading, starting the driver job in Ea_MainFunction is explicitly required. Question Q-50dcdf4156855a99 (open) The same is likely to apply to writing, because Ea_MainFunction processes the requested jobs ([SWS_Ea_00096]). In the case of a vendor-specific library, the sequence diagrams are binding only for the relationship to the calling modules, not for the calls to the driver (SWS EA p. 45).

write job via EaNvMMemIfEaEepBSW SchedulerUse Case: Auftragsannahme (synchron)MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr)Ea_Write(BlockNumber, DataBufferPtr)address from BlockNumber, offset 0length = configured block lengthBlock als inkonsistent markierenE_OKE_OKUse Case: Asynchrone AbarbeitungEa_MainFunction()Eep_Write(...)Assumption: driver job is started in Ea_MainFunctionloopbis Treiberauftrag beendetEep_MainFunction()Ea_JobEndNotification()Block als konsistent markierenJobergebnis MEMIF_JOB_OKNvM_JobEndNotification()

Sequence diagram: A write job is accepted synchronously, executed asynchronously via the driver, and reported to the NvM via callback. Sources: SWS Eep p. 50, SWS MemIf p. 19, [SWS_Ea_00087], [SWS_Ea_00094], [SWS_Ea_00099]

Block Management: Address Mapping, Consistency, and Invalidation

Fig. 7.1 compares virtual and physical memory. The block number (16 bits) and offset (16 bits) form a virtual address, so that a block can span up to 64 KiB. Physically, the blocks are aligned to the configured virtual page size EA_VIRTUAL_PAGE_SIZE; unused virtual space occupies no memory (SWS EA p. 23).

Ea maintains dedicated consistency information for each block. At the start of a write process, the block is considered inconsistent; after successful completion, it is considered consistent again. Ea must be able to distinguish an inconsistent block from an intentionally invalidated block (SWS EA p. 19, version R24-11). For the caller, both cases become visible via the job results MEMIF_BLOCK_INCONSISTENT and MEMIF_BLOCK_INVALID ([SWS_Ea_00090]).

Ea_InvalidateBlock invalidates the block BlockNumber ([SWS_Ea_00091]). Depending on the implementation, this occurs via the driver's erase function or via internal management information, which must then be stored non-volatilely (SWS EA p. 31).

Ea_EraseImmediateBlock erases a block ([SWS_Ea_00093]). The function is intended for diagnostic or comparable system services that pre-erase the area for immediate data. It calculates the address with an offset of zero. It ensures that Ea can write immediate data (SWS EA p. 34).

Operating Mode, Cancellation, and Notifications

In R20-11, Ea_SetMode switches the mode of the EEPROM driver using the parameter Mode of type MemIf_ModeType. The service is asynchronous and not reentrant ([SWS_Ea_00085]). The shortened signature without parameters in the API elements deviates from this; the service description is authoritative. The diagrams show the chain NvM → MemIf_SetMode → Ea_SetMode → Eep_SetMode (SWS EA p. 42). From R21-11 onwards, the service is omitted (SWS EA p. 1).

mode switch with Ea_SetMode (R20-11)NvMMemIfEaEepMemIf_SetMode(MemIf_ModeType)Ea_SetMode(MemIf_ModeType)Eep_SetMode(MemIf_ModeType)Eep_SetMode()Ea_SetMode()MemIf_SetMode()Ea_SetMode only up to R20-11, removed as of R21-11

Sequence diagram: A mode change is passed through from the NvM via MemIf and Ea to the driver (only up to R20-11). Sources: [SWS_Ea_00085], SWS EA p. 52, SWS EA p. 42

Ea_Cancel cancels the running asynchronous job and is synchronous in R20-11 ([SWS_Ea_00088]). The subsequent document section describes the service as asynchronous; for R20-11, the requirement applies. In terms of content, according to this passage: in state MEMIF_BUSY, Ea calls the driver's cancel function and resets its internal variables. The job result is then MEMIF_JOB_CANCELED (SWS EA p. 27). MemIf forwards the cancellation (SWS MemIf p. 20). A cancellation without a pending job yields EA_E_INVALID_CANCEL ([SWS_Ea_91002]).

cancellation of a job using Ea_CancelNvMMemIfEaEepMemIf_Cancel(DeviceIndex)Ea_Cancel()altStatus MEMIF_UNINIT (DET aktiv)EA_E_UNINIT meldenInternal variables unchangedStatus MEMIF_BUSYEep_Cancel()Returnreset internal variablesJobergebnis MEMIF_JOB_CANCELEDready for new jobno job pendingEA_E_INVALID_CANCEL meldenReturnReturn

Sequence diagram: Ea_Cancel branches depending on the module status into driver cancellation, error notification, or return without modification. Sources: [SWS_Ea_00088], [SWS_Ea_91002], [SWS_Ea_00097], SWS EA p. 27, SWS MemIf p. 20

The lower layer reports the success or failure of an asynchronous job via Ea_JobEndNotification or Ea_JobErrorNotification ([SWS_Ea_00094], [SWS_Ea_00095]). Ea then signals NvM_JobEndNotification or NvM_JobErrorNotification from NvM_MemIf.h to the NvM ([SWS_Ea_00099], [SWS_Ea_00100]). MemIf does not provide any callbacks itself (SWS MemIf p. 24).

Callbacks can run at interrupt level. Their execution time must therefore remain short, and the system design must align the configuration accordingly (SWS EA p. 35). Ea_GetVersionInfo is the only service that is reentrant ([SWS_Ea_00092]).

Behavior in the event of an error

The error codes are listed in two tables.

  • First table ([SWS_Ea_91001]): EA_E_UNINIT (0x01), EA_E_INVALID_BLOCK_NO (0x02), EA_E_INVALID_BLOCK_OFS (0x03), EA_E_PARAM_POINTER (0x04), and EA_E_INVALID_BLOCK_LEN (0x05).
  • Second table ([SWS_Ea_91002]): EA_E_BUSY (0x06) and EA_E_INVALID_CANCEL (0x08).

EA_E_INIT_FAILED was removed with R20-11 (SWS EA p. 1). Interpretation: The first table likely covers development errors via the optional Det_ReportError, the second runtime errors via Det_ReportRuntimeError ([SWS_Ea_00097], [SWS_Ea_00098]). Question Q-8443a03d306e4143 (open)

With development error detection active, the following applies in the uninitialized state: Ea_GetJobResult reports EA_E_UNINIT and returns MEMIF_JOB_FAILED (SWS EA p. 30). Ea_Cancel reports EA_E_UNINIT and returns without modifying internal variables (SWS EA p. 27). Ea_GetVersionInfo reports EA_E_PARAM_POINTER in case of a NULL pointer (SWS EA p. 32). Ea_InvalidateBlock and Ea_EraseImmediateBlock return E_NOT_OK only when DET is active ([SWS_Ea_00091], [SWS_Ea_00093]).

Hardware errors are detected by the EEPROM driver. The response of Ea is implementation-specific. Depending on the configuration, it is reported in one of two ways: via polling with the job result MEMIF_JOB_FAILED or via the callback NvM_JobErrorNotification. Recovery is handled by the NvM (ErrorDescription p. 48, [SWS_Ea_00095], [SWS_Ea_00100]). For the polling path, the error description specifies Eep_GetJobResult. That Ea polls this function in its Main Function is presumably intended, but not explicitly specified. Question (open)

The job result distinguishes the error types finely ([SWS_Ea_00090]):

  • MEMIF_JOB_CANCELED: Cancellation, considered failed.
  • MEMIF_JOB_FAILED: The job has failed.
  • MEMIF_BLOCK_INCONSISTENT: The block may contain corrupted data.
  • MEMIF_BLOCK_INVALID: The block was invalidated; the operation cannot be executed.
notification of a driver errorNvMEaEepEep detects error in asynchronous jobaltKonfiguration: Callback-BenachrichtigungEa_JobErrorNotification()implementierungsspezifische ReaktionNvM_JobErrorNotification()Konfiguration: PollingEep_GetJobResult()MEMIF_JOB_FAILEDAnnahme: Abfrage in Ea_MainFunctionEa_GetJobResult()MEMIF_JOB_FAILEDRecovery: task of NvM

Sequence diagram: Depending on the configuration, a driver error reaches the NvM via callback or by polling the job result. Sources: ErrorDescription p. 48, [SWS_Ea_00095], [SWS_Ea_00100], [SWS_Ea_00090], [SWS_Ea_00097]

Further detailed evidence

AI-generated guide based on the R20-11 requirements and document sections provided in the payload. Document sections from later releases are identified; in case of discrepancies, the requirement prevails. Statements marked as interpretations are non-normative.

EEPROM Abstraction (Ea)

Provides uniform access to external and internal EEPROM devices.

Funktionen — Übersicht

Typen — Übersicht

Funktionen & Typen — Detailansicht

function Ea_Init [SWS_Ea_00084] 📄 PDF

void Ea_Init (const Ea_ConfigType* ConfigPtr);

Initializes the EEPROM abstraction module.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 758621a616a5 Provenance Open questions (1)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

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 0x00 is assigned to the service.
  • Reentrancy: The function is specified as non-reentrant (Non Reentrant) and therefore must not be executed concurrently.
  • Parameters: ConfigPtr (type const 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

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: a4f6e1f8e66c Provenance
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

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 Mode is 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.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 43bc307f1243 Provenance Open questions (1)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

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.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 41c9f0ddc8f3 Provenance Open questions (2)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

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_OK indicates that the write job was accepted by the EA module for execution; E_NOT_OK means 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.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 7fde513694e7 Provenance Open questions (1)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

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.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 2c1c29a1fe37 Provenance Open questions (1)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

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_EraseImmediateBlock [SWS_Ea_00093] 📄 PDF

Std_ReturnType Ea_EraseImmediateBlock (uint16 BlockNumber);

Erases the block Block Number.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 11c26d81184d Provenance Open questions (1)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

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 type Std_ReturnType: E_OK signals 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_OK if 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, no E_NOT_OK is 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 is 0x09 ([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.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 234afd19dc30 Provenance Open questions (2)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

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.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 9e75b5e5784e Provenance Open questions (1)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

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.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 982c19d62ccc Provenance Open questions (1)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

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.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 5f055de9eae0 Provenance Open questions (1)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

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.

AI-GENERATED unreviewed Model: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 6fbe1fe6a235 Provenance
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original

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.

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

Initialization and status

Ea_GetStatus function

Service to return the Status.

MemIf_StatusType Ea_GetStatus (void);

Service to get the version information of this module.

void Ea_GetVersionInfo (Std_VersionInfoType* VersionInfoPtr);
Ea_Init function

Initializes the EEPROM abstraction module.

void Ea_Init (const Ea_ConfigType* ConfigPtr);

Services

Ea_Cancel function

Cancels the ongoing asynchronous operation.

void Ea_Cancel (void);

Erases the block Block Number.

Std_ReturnType Ea_EraseImmediateBlock (uint16 BlockNumber);

Service to return the Job Result.

MemIf_JobResultType Ea_GetJobResult (void);

Invalidates the block Block Number.

Std_ReturnType Ea_InvalidateBlock (uint16 BlockNumber);

Service to report to this module the successful end of an asynchronous operation.

void Ea_JobEndNotification (void);

Service to report to this module the failure of an asynchronous operation.

void Ea_JobErrorNotification (void);
Ea_Read function

Reads Length bytes of block Blocknumber at offset Block Offset into the buffer Data Buffer Ptr.

Std_ReturnType Ea_Read (uint16 BlockNumber, uint16 BlockOffset, uint8* DataBufferPtr, uint16 Length);
Ea_SetMode function

Function to switch the mode of the underlying EEPROM Driver

void Ea_SetMode (MemIf_ModeType Mode);
Ea_Write function

Writes the contents of the Data Buffer Ptr to the block Block Number.

Std_ReturnType Ea_Write (uint16 BlockNumber, const uint8* DataBufferPtr);

Function to be used by the underlying memory abstraction to signal end of job without error.

void NvM_JobEndNotification (void);

Function to be used by the underlying memory abstraction to signal end of job with error.

void NvM_JobErrorNotification (void);

Cyclic

Service to handle the requested jobs and the internal management operations.

void Ea_MainFunction (void);

Types

Configuration data structure of the Ea module.