Memory Abstraction Interface (MemIf)

MemIf leitet die Speicheraufträge des NVRAM Managers an Fee- oder Ea-Module weiter und verbirgt deren Anzahl hinter einer einheitlichen API SWS MemIf S. 7. Der Parameter DeviceIndex wählt das Modul; ist nur eines konfiguriert, wird er ignoriert und MemIf als Makrosatz umgesetzt SWS MemIf S. 17. Die Dienste nehmen Aufträge synchron an und reichen den Rückgabewert weiter, während die Speicheroperation asynchron darunter abläuft. Status und Ergebnis liefern MemIf_GetStatus und MemIf_GetJobResult. Bei aktiver Entwicklungsfehlererkennung liefern fehlerhafte Aufrufe E_NOT_OK bzw. MEMIF_JOB_FAILED.

mehr ›

Das Memory Abstraction Interface ersetzt die früheren Treiber-Schnittstellenschichten für Flash und EEPROM. Es erlaubt dem NVRAM Manager, über eine einheitliche API mehrere Abstraktionsmodule anzusprechen: die Flash EEPROM Emulation (Fee) und die EEPROM Abstraction (Ea) SRS MemHwAb S. 5. MemIf verbirgt die Anzahl dieser Module und bietet eine virtuelle Segmentierung auf einem linearen Adressraum SWS MemIf S. 7.

Kontextdiagramm: MemIf vermittelt zwischen NvM und Fee/Ea; Fertigmeldungen gehen direkt von Fee/Ea an den NvM. Quellen: SWS Fee S. 6, [SWS_MemIf_00047]

Eigene Speicherlogik hat MemIf nicht. Der Parameter DeviceIndex wählt das Modul; ist nur eines konfiguriert, wird er ignoriert und MemIf als Makrosatz umgesetzt. Bei mehreren Modulen erfolgt die Verteilung etwa über Funktionszeigertabellen SWS MemIf S. 17. In R20-11 ist DeviceIndex vom Typ uint8 [SWS_MemIf_00039]; spätere Fassungen verwenden uint16.

Die Dienste nehmen Aufträge synchron an und reichen den Rückgabewert des Moduls weiter [SWS_MemIf_00040]. Die Speicheroperation läuft danach asynchron in der Hauptfunktion der unteren Schicht. Den Abschluss erfährt der NvM per Callback aus Fee/Ea oder durch Polling von MemIf_GetJobResult SWS Fee S. 48. MemIf_GetStatus meldet UNINIT, IDLE, BUSY oder BUSY_INTERNAL [SWS_MemIf_00064]. Das Jobergebnis bezieht sich stets auf den letzten Auftrag und unterscheidet unter anderem abgebrochene, inkonsistente und ungültige Blöcke [SWS_MemIf_00065]. MemIf_SetMode wirkt auf alle Module zugleich [SWS_MemIf_00038].

Sequenzdiagramm: Synchrone Annahme über MemIf, asynchrone Ausführung im Treiber, Abschluss per Callback oder Polling. Quellen: SWS Ea S. 41, [SWS_MemIf_00040]

Im Fehlerfall meldet MemIf ungültige Geräteindizes und NULL-Zeiger als Entwicklungsfehler [SWS_MemIf_00006]. Die Dienste liefern dann E_NOT_OK, MemIf_GetJobResult liefert MEMIF_JOB_FAILED SWS MemIf S. 21. Laufzeitfehler des Speichers erkennen Fee bzw. Ea; der NvM liest sie im Polling-Betrieb als MEMIF_JOB_FAILED und ist für die Behebung zuständig ErrorDescription S. 58.

mehr ›

Rolle im Speicherstapel: Weiche zwischen NvM und Fee/Ea

Das Memory Abstraction Interface (MemIf) ersetzt die früheren Treiber-Schnittstellenschichten für Flash und EEPROM. Es erlaubt dem NVRAM Manager (NvM), über eine einzige API mehrere Speicherabstraktionsmodule anzusprechen: die Flash EEPROM Emulation (Fee) und die EEPROM Abstraction (Ea) SRS MemHwAb S. 5. Nach oben verbirgt MemIf, wie viele Fee- und Ea-Module darunter liegen. Es bietet eine virtuelle Segmentierung auf einem einheitlichen linearen Adressraum SWS MemIf S. 7. Fee und Ea liefern die blockbasierte Adressierung und eine „virtuell unbegrenzte“ Zahl von Lösch-Schreib-Zyklen. Deshalb muss der NvM nicht geändert werden, wenn Treiber oder Baustein wechseln SRS MemHwAb S. 5.

MemIf enthält selbst keine Speicherlogik. Seine API ist auf die API der Abstraktionsmodule abzubilden, und das funktionale Verhalten legen deren Spezifikationen bzw. die der Speichertreiber fest SWS MemIf S. 17. Entsprechend benötigt MemIf die Dienste der Abstraktionsmodule, für Ea etwa Ea_Read, Ea_Cancel, Ea_GetStatus und Ea_GetJobResult [SWS_MemIf_00047]. Optional nutzt es Det_ReportError [SWS_MemIf_00048]. Die in MemIf.h definierten Typen MemIf_StatusType, MemIf_JobResultType und MemIf_ModeType bilden das gemeinsame Vokabular des Stapels [SWS_MemIf_00064] [SWS_MemIf_00065] [SWS_MemIf_00066]. So liefert etwa Fls_GetJobResult direkt MemIf_JobResultType SWS Fls S. 36.

Die Abbildungen jüngerer Releases zeigen unterhalb von Ea und Fee zusätzlich die Module MemAcc und Mem SWS Ea S. 42. Für R20-11 dürfte vermutlich die ältere Übersicht maßgeblich sein, in der Fee auf den Flash-Treiber und Ea auf den EEPROM-Treiber aufsetzen SWS Fee S. 6. Für MemIf ist der Unterschied ohne Belang, da es nur bis zur Abstraktionsebene weiterleitet SWS MemIf S. 17. Frage Q-3c74a6029dd0d159 (offen)

Kontextdiagramm: MemIf liegt zwischen NvM und den Abstraktionsmodulen Fee/Ea; Fertigmeldungen erreichen den NvM direkt aus Fee/Ea. Quellen: SWS Fee S. 6, SRS MemHwAb S. 5, [SWS_MemIf_00047], [SWS_MemIf_00048]

Geräteauswahl über DeviceIndex: Makros oder Verteiltabelle

Der Parameter DeviceIndex wählt das Abstraktionsmodul und damit den Speicherbaustein. Ist nur ein Modul konfiguriert, wird er ignoriert SWS MemIf S. 17. In diesem Fall ist MemIf als Satz von Makros umzusetzen, etwa #define MemIf_Write(DeviceIndex, BlockNumber, DataPtr) Fee_Write(BlockNumber, DataPtr). Bei mehreren Modulen sind die Aufrufe über effiziente Mechanismen zu verteilen; als eine Lösung nennt die Spezifikation Tabellen von Funktionszeigern, die über DeviceIndex indiziert werden SWS MemIf S. 17. Ersetzt eine herstellerspezifische Bibliothek alle benötigten Fee- und Ea-Module, besteht MemIf nur aus Makros SRS MemHwAb S. 5.

In R20-11 ist DeviceIndex vom Typ uint8 [SWS_MemIf_00039] [SWS_MemIf_00041]. Spätere Fassungen der Spezifikation führen ihn als uint16 SWS MemIf S. 18. Normativ für dieses Release ist uint8.

Aktivitätsdiagramm: Die Anzahl der konfigurierten Abstraktionsmodule entscheidet zwischen Makro-Abbildung und Verteilung per DeviceIndex. Quellen: SWS MemIf S. 17, SRS MemHwAb S. 5

Auftragsablauf: synchrone Annahme, asynchrone Ausführung

Alle MemIf-Dienste sind synchron spezifiziert. Jeder ruft die gleichnamige Funktion des gewählten Moduls auf und gibt deren Rückgabewert zurück, so etwa Read, Write und InvalidateBlock [SWS_MemIf_00039] [SWS_MemIf_00040] [SWS_MemIf_00044]. Die eigentliche Speicheroperation läuft danach asynchron in der zyklisch aufgerufenen Hauptfunktion der unteren Schicht. Die Ea-Sequenz zeigt dazu eine Schleife über Eep_MainFunction im BSW-Task SWS Ea S. 41. Laut Fee-Spezifikation gilt dieses Muster auch für die übrigen asynchronen Dienste SWS Fee S. 48.

Vom Auftragsende erfährt der NvM je nach Stackkonfiguration auf einem von zwei Wegen. Entweder ruft das Abstraktionsmodul einen Callback wie NvM_JobEndNotification bzw. NvM_JobErrorNotification, oder der NvM pollt MemIf_GetJobResult SWS Fee S. 48 EXP ErrorDescription S. 45. MemIf selbst stellt keine Callback-Funktion bereit; seine API besteht aus den folgenden Diensten [SWS_MemIf_00038] [SWS_MemIf_00046].

Dienst	Service-ID	Rückgabe	Wirkung
MemIf_SetMode	0x01	–	ruft SetMode aller Abstraktionsmodule [SWS_MemIf_00038]
MemIf_Read	0x02	Std_ReturnType	liest Length Bytes des Blocks ab BlockOffset nach DataBufferPtr [SWS_MemIf_00039]
MemIf_Write	0x03	Std_ReturnType	schreibt einen Block [SWS_MemIf_00040]
MemIf_Cancel	0x04	–	bricht den laufenden Auftrag ab [SWS_MemIf_00041]
MemIf_GetStatus	0x05	MemIf_StatusType	Modulstatus [SWS_MemIf_00042]
MemIf_GetJobResult	0x06	MemIf_JobResultType	Ergebnis des letzten Auftrags [SWS_MemIf_00043]
MemIf_InvalidateBlock	0x07	Std_ReturnType	invalidiert einen Block [SWS_MemIf_00044]
MemIf_GetVersionInfo	0x08	–	Versionsinformation, reentrant [SWS_MemIf_00045]
MemIf_EraseImmediateBlock	0x09	Std_ReturnType	löscht einen Block [SWS_MemIf_00046]

Sequenzdiagramm: Ein Schreibauftrag wird synchron über MemIf angenommen, asynchron im Treiber ausgeführt und per Callback oder Polling abgeschlossen. Quellen: SWS Ea S. 41, SWS Fee S. 48, ErrorDescription S. 60, [SWS_MemIf_00040]

Status, Jobergebnis und Betriebsmodus

MemIf_GetStatus liefert den Status des gewählten Moduls [SWS_MemIf_00042]. Möglich sind MEMIF_UNINIT, MEMIF_IDLE, MEMIF_BUSY und MEMIF_BUSY_INTERNAL. Bei MEMIF_BUSY_INTERNAL ist das Abstraktionsmodul mit interner Verwaltung beschäftigt, während der Treiber busy oder idle sein kann [SWS_MemIf_00064]. Die Fee-Spezifikation konkretisiert die Bedingungen und nennt als Beispiel für interne Verwaltung die Reorganisation des Flashs (Garbage Collection) SWS Fee S. 30. Beim Flash-Treiber darf der Status schon vor der Initialisierung abgefragt werden und lautet dann MEMIF_UNINIT SWS Fls S. 35.

Zustandsdiagramm: Lebenszyklus des über MemIf_GetStatus sichtbaren Modulstatus. Quellen: [SWS_MemIf_00064], SWS Fee S. 30

MemIf_GetJobResult liefert das Ergebnis des letzten Auftrags [SWS_MemIf_00043] [SWS_MemIf_00065]. Lesen, Schreiben und Löschen teilen sich ein einziges Jobergebnis, sodass nur das des letzten Auftrags abfragbar ist. Mit der Annahme eines neuen Auftrags wird es auf MEMIF_JOB_PENDING gesetzt SWS Fls S. 36; Fee spricht vom letzten angenommenen Auftrag SWS Fee S. 31. Neben OK, FAILED und CANCELED gibt es zwei blockbezogene Ergebnisse. MEMIF_BLOCK_INCONSISTENT bedeutet, dass der Block korrupt oder nicht gefunden ist; MEMIF_BLOCK_INVALID bedeutet, dass er als ungültig markiert ist [SWS_MemIf_00065].

Zustandsdiagramm: Ein angenommener Auftrag steht auf PENDING und endet in genau einem der Endergebnisse. Quellen: [SWS_MemIf_00065], SWS Fls S. 36, SWS Fee S. 31

MemIf_SetMode hat als einziger Dienst keinen DeviceIndex und ruft SetMode aller Abstraktionsmodule auf [SWS_MemIf_00038]. Die Modi sind MEMIF_MODE_SLOW und MEMIF_MODE_FAST [SWS_MemIf_00066]. Bei den Treibern steht das für langsamen Lesezugriff bzw. normalen SPI-Zugriff einerseits und schnellen Lesezugriff bzw. SPI-Burst andererseits. Eep_SetMode darf nicht während einer laufenden Operation gerufen werden SWS Eep S. 34. Fls_SetMode weist bei aktiver Prüfung eine Anfrage im Busy-Zustand zurück SWS Fls S. 42. Interpretation: Da MemIf_SetMode alle Module erreicht, sollte es nur aufgerufen werden, wenn alle Geräte MEMIF_IDLE melden. Frage Q-d6ee630fca619042 (offen)

Abbrechen laufender Aufträge

MemIf_Cancel ruft die Cancel-Funktion des gewählten Moduls auf [SWS_MemIf_00041]. Der Abbruch selbst ist synchron, bezüglich der Hardware aber asynchron: Die Hardware kann noch nachlaufen, wenn der Aufruf bereits zurückgekehrt ist SWS Fee S. 45 SWS Ea S. 44. Das Jobergebnis lautet danach MEMIF_JOB_CANCELED [SWS_MemIf_00065], was Fee ausdrücklich als Fehlschlag wertet SWS Fee S. 31.

Für den Flash-Pfad zeigt die Treiberspezifikation die Kette MemIf_Cancel → Fee_Cancel → Fls_Cancel mit anschließenden Fehlerbenachrichtigungen. Sie fordert außerdem, Fls_Cancel nicht während einer laufenden Fls_MainFunction aufzurufen. Dafür gibt es zwei Wege: Die Jobfunktionen von NvM und Flash-Treiber werden synchronisiert, oder der Task der Fls_MainFunction wird nicht unterbrochen SWS Fls S. 58.

Sequenzdiagramm: Der Abbruch läuft synchron durch alle Schichten, die Fehlerbenachrichtigung folgt, danach meldet GetJobResult CANCELED. Quellen: SWS Fls S. 58, SWS Fee S. 45, [SWS_MemIf_00041]

Aufrufregeln, Reentranz und Einbettung in die BSW

Mit Ausnahme von MemIf_GetVersionInfo sind alle Dienste nicht reentrant [SWS_MemIf_00045] [SWS_MemIf_00040]. Parallele Aufrufe aus mehreren Kontexten müssen daher ausgeschlossen werden. Da Status und Jobergebnis je Modul nur den letzten Auftrag widerspiegeln, sollte der Aufrufer einen neuen Auftrag erst nach Abschluss des vorigen erteilen SWS Fls S. 36.

Das Memory-Mapping-Beispiel eines ICC2-Clusters „MEM“ führt MemIf gemeinsam mit dem NvM. Dort ist MemIf_SetMode als BswCalledEntity modelliert, und MemIf hat das Section-Präfix MEMIF SWS MemoryMapping S. 50. Der BSW Distribution Guide nennt MEMIF neben FLS und FEE als Beispiel für „Type I“; der Geltungsbereich lässt sich per SwAddrMethod mit lokalem Scope auf einen Kern begrenzen EXP BSWDistributionGuide S. 31. Vermutlich ist MemIf in Mehrkernsystemen damit kernlokal zu betreiben. Frage Q-d998fdc58e0bcddd (offen)

Verhalten im Fehlerfall

MemIf kennt zwei Entwicklungsfehler. MEMIF_E_PARAM_DEVICE (0x01) steht für einen falschen DeviceIndex, MEMIF_E_PARAM_POINTER (0x02) für einen NULL-Zeiger [SWS_MemIf_00006]. Gemeldet werden sie über das optionale Det_ReportError [SWS_MemIf_00048]. Spezifische Fehlercodes werden laut Tracing-Tabelle nicht über die API zurückgegeben SWS MemIf S. 12.

Ist die Entwicklungsfehlererkennung aktiv und wird ein Fehler erkannt, liefern Read, Write, InvalidateBlock und EraseImmediateBlock E_NOT_OK [SWS_MemIf_00039] [SWS_MemIf_00040] [SWS_MemIf_00044] [SWS_MemIf_00046]. MemIf_GetJobResult liefert in diesem Fall MEMIF_JOB_FAILED SWS MemIf S. 21. Sonst wird der Wert des Moduls unverändert weitergereicht.

Aktivitätsdiagramm: Parameterprüfung bei aktiver Entwicklungsfehlererkennung und Durchreichen des Modulergebnisses. Quellen: [SWS_MemIf_00006], [SWS_MemIf_00048], SWS MemIf S. 18, SWS MemIf S. 21

Laufzeitfehler des Speichers erkennt nicht MemIf, sondern Fee bzw. Ea; MemIf selbst reagiert nicht darauf („N/A“). Im Polling-Betrieb liest der NvM den Fehler über MemIf_GetJobResult als MEMIF_JOB_FAILED, und die Behebung liegt beim NvM ErrorDescription S. 58 ErrorDescription S. 60. Eine jüngere Fassung beschreibt diese Behebung näher. Danach erhöht der NvM bei Schreibaufträgen einen Wiederholzähler, bricht nach Überschreiten ab und meldet NVM_E_REQ_FAILED an den DEM EXP ErrorDescription S. 45. Für R20-11 ist dieses Detail hier nicht normativ belegt.

Weiterführende Detailbelege

• API-Definitionen mit Service-IDs, Reentranz und Rückgabewerten: [SWS_MemIf_00038] bis [SWS_MemIf_00046].
• Datentypen für Status, Jobergebnis und Modus: [SWS_MemIf_00064], [SWS_MemIf_00065], [SWS_MemIf_00066]; importierte Typen: [SWS_MemIf_00037].
• Abbildungsregeln (Makros, DeviceIndex, Verteilung): SWS MemIf S. 17.
• Benötigte und optionale Schnittstellen: [SWS_MemIf_00047], [SWS_MemIf_00048]; Fehlercodes: [SWS_MemIf_00006].
• Abläufe für Schreiben und Abbrechen: SWS Fee S. 48, SWS Fls S. 58.
• Fehlerkette bis zum NvM in R20-11: ErrorDescription S. 58.