Search tips

apple banana
Find rows that contain at least one of the two words.

+apple +juice
Find rows that contain both words.

+apple macintosh
Find rows that contain the word 'apple', but rank rows higher if they also contain 'macintosh'.

+apple -macintosh
Find rows that contain the word 'apple' but not 'macintosh'.

+apple ~macintosh
Find rows that contain the word 'apple', but if the row also contains the word 'macintosh', rate it lower than if row does not. This is "softer" than a search for '+apple -macintosh', for which the presence of 'macintosh' causes the row not to be returned at all.

+apple +(>turnover >strudel)
Find rows that contain the words 'apple' and 'turnover', or 'apple' and 'strudel' (in any order), but rank 'apple turnover' higher than 'apple strudel'.

Find rows that contain words such as 'apple', 'apples', 'applesauce', or 'applet'.

"some words"
Find rows that contain the exact phrase 'some words' (for example, rows that contain 'some words of wisdom' but not "some noise words").

By continuing to use this site you agree to the use of cookies. For more information and to find out how to change this click here. Accept Cookies
Please enable cookies in your browser for this website.
Advanced search

How to Interpret Return Values of MICROSAR NvM

Last updated: 2019-11-06
How can I interpret return values of MICROSAR NvM?

Mostly the NvM maps the result delivered by the underlying abstraction directly to the NvM result as follows:

 MemIf_JobResultType  NvM_RequestResultType

All other MemIf_JobResultType values are not used/checked by the MICROSAR NvM.

Since the NvM result also depends on block configuration and the current request, the table above shall be extended to:

 NvM_RequestResultType Use cases

Default value after reset

  • (after NvM initialization. NvM_ReadAll, as part of the initialization, sets the value to the actual result).
  • Erase, invalidate, read or write request is finished successfully.

Redundant blocks:

  • at least one block read/written successfully,
  • both blocks erased/invalidated successfully.
  • All blocks processed successfully during NvM_ReadAll or NvM_WriteAll. Configuration block read successfully, and the identifier matches the one, which is currently compiled.
  • During extended runtime preparation (configuration update) the default data was loaded to RAM.

No valid data available in NV RAM

  • Erase, invalidate, read or write request which did not finish successfully. At least one block does not process successfully during NvM_ReadAll or NvM_WriteAll.
  • Configuration block read successfully, but the identifier does not match the one which is currently compiled.  


An asynchronous request is currently pending:

  • queued and waiting for processing
  • currently in processing.


No valid data available in NV RAM

  • Data read successfully, but the stored CRC does not match the recalculated one.
  • Requested block is inconsistent, it may contain corrupted data.
  • Since AUTOSAR 4.2.2: no data found by underlying abstraction.

No valid data available in NV RAM

  • Requested block invalidated previously, it does not contain any data.
  • MICROSAR memory stack: no data found by underlying abstraction.
 NVM_REQ_SKIPPED     Skipped block during NvM_ReadAll or NvM_WriteAll (not selected for the multi block, all dataset blocks during NvM_ReadAll, etc.).
 NVM_REQ_CANCELED The last asynchronous request was canceled.

The following value will only be used by specific MICROSAR NvM:

NvM versions ≥ 8.00.00 and newer (implementation version ≥ 6.00.00) support, older NvM versions do not support the following result:

 NvM_RequestResultType Explanation
 NVM_REQ_RESTORED_FROM_ROM_ Overwrites the actual result, e.g. if the CRC does not match and therefore the NvM loads the default values, the result is not NVM_REQ_INTEGRITY_FAILED, but NVM_REQ_RESTORED_FROM_ROM. The information about the actual result gets lost.

The following values are not used by the MICROSAR NvM:

 NvM_RequestResultType Explanation
 NVM_REQ_REDUNDANCY_FAILED Its usage is not described by AUTOSAR, the value was removed in AUTOSAR 4.3.

Some additional situations the user may face:

The NvM_ReadAll result is NVM_REQ_OK, but the configuration block (Block identifier 1) result is NVM_REQ_NOT_OK.

  • This happens if the configuration block is readable and the CRC matches, but the included configuration identifier does not match => NvM starts a configuration update and processes the blocks in extended or normal runtime preparation. The NvM_ReadAll result indicates that all blocks were processed successfully. The configuration block result indicates the configuration identifier mismatch and the configuration update scenario.

If the configuration block cannot be read or its CRC does not match, i.e. the data is not usable, the NvM_ReadAll result will not be NVM_REQ_OK. A configuration block with no or unusable data forces the NvM to configuration update.


  • Normally a block writes only results in NVM_REQ_OK or NVM_REQ_FAILED. In case the underlying abstraction delivers any other result, NvM will map the result to a NvM result as described above. The easiest way to treat all results other than NVM_REQ_OK as a write failure.

NvM reports error to DEM after reading from empty NV RAM or never written block.

  • Since AUTOSAR 4.2.2 specifies the MEMIF_BLOCK_INCONSISTENT to be used in case no data was found for the requested block (empty NV RAM/ block never written before), the NvM maps the result to NVM_REQ_INTEGRITY_FAILED and reports the related error to DEM, as specified in AUTOSAR standard.
  • In contrast the MICROSAR memory abstraction modules (AUTOSAR 4.0.3) use the MEMIF_BLOCK_INVALID result for not existing data, the NvM will not report any error to DEM, as specified in AUTOSAR standard.
  • However, both ways are possible, both inform the user about not available data in NV RAM.

If NvM result is one of the negative results, how do I know whether default data was loaded?

  • If a NvM block is configured with a ROM block, NvM will always load the ROM data to the block-related RAM buffer, if the read result is different from NVM_REQ_OK.
  • If a NvM block is configured with an initialization callback, NvM will always invoke the callback, if the read result is other than NVM_REQ_OK. In that case the user is responsible for RAM initialization.
  • In both cases the user must know that the block is configured with default data – ROM block or initialization callback.
Article Options
Views: 496
Rate this article: