vector.com|Contact
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'.

apple*
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.
Search:
Advanced search

Standard Fee and SmallSectorFee

Last updated: 2019-01-29
Question:
Why does Vector offer two different Fee implementations, MICROSAR Standard Fee and SmallSectorFee?
Answer:

An obvious Fee implementation is to split the whole available flash memory into two logical sectors. Starting at the first logical sector, every new version of data will be stored to the next free page until the logical sector is filled (walking data). For garbage collection the logical sectors are switched, so that the latest version of every data is copied from the first to the second logical sector. Afterwards, the first one is erased. In general, both logical sectors are worked within alternating manner, so that one sector holds most recent data and the other one can be erased. 

When it comes to flash devices with physical sectors of a bigger size, it is essential to use the above mentioned Two-Logical-Sectors-strategy in the Fee implementation. This strategy is implemented in the MICROSAR Standard Fee.
 

 MCU Family  Physical Sector Size  Page Size
 S12XE  256 Byte – 1024 Byte   2 – 8 Byte
 TC2xx   1 kByte – 8kByte  8 Byte
 MPC56xx      16kByte – 128kByte  4 – 16 Byte
 Tricore 17xx   64kByte – 128kByte  128 – 256 Byte

  

In contrast, another approach may have advantages compared with this if the size of physical sectors is much smaller. The following sections deal with a flash device with 64 byte physical sectors and consequently, with the effect on FEE data management strategy.

From abstract point of view there are two classes of flash devices:
 

  • Big size but few number of physical sectors (e.g. 2 sectors each 32kByte) 
  • Small size but huge number of sectors (e.g. 1024 sectors each 64 Byte) 
     

Examples for the first group were already listed in the table above. Regarding the latter class, Renesas Electronics™ introduced the internal data flash RV40F on its RH850 platform, which features following hardware properties:
 

 RH850’s internal data flash properties   Size [Byte]
 Physical Sector  64
 Page      4

  

Depending on RH850 derivative, the internal data flash comes with either 32 KB or 64 KB respectively with 512 or 1024 physical sectors. 

Since a physical sector with 64 Byte is the smallest erasable unit of this flash device, it is worth to consider applying a static addressing scheme in FEE implementation for user data. Instead of spreading user data over two logical sectors as in the MICROSAR Standard Fee, every user block is assigned to a certain number of physical sectors, which are reserved only for this type of data. Each block can therefore be erased and re-written independently from other blocks. Hereafter, a concept is described which makes use of the hardware properties of such flash devices to address flash memories with small sectors more efficiently. This concept is implemented in the SmallSectorFee.

Usually the physical sector size is many times the size of a user data block. This requires that any update of user data will be stored in a walking manner within one physical sector until it is full. In consequence, user blocks are addressed dynamically, because they are always written to the next free address within a sector. 

Compared to physical sectors of size 16kByte – 128kByte (e.g. MPC56xx MCU family), sectors with 64 Byte offer the possibility of a static addressing scheme. Hereby, user data can be stored in a dedicated (preconfigured) sector, which is reserved for this user block only. 

The following figure depicts how sample user blocks are arranged in flash memory with static addresses.

The Memory Layout of Block Configuration with SmallSectorFee above simplifies, how user blocks are arranged statically in flash memory. Every user block is assigned to one or more physical flash sectors, but two user blocks never share one physical sector. Thus, user blocks respectively their physical sectors are independent from each other and can be erased and re-written without affecting other blocks. With this static addressing scheme, the SmallSectorFee is able to specifically erase and re-write single user blocks. 

A mechanism for walking data is also applied to the SmallSectorFee but is limited to the physical sectors which are reserved for a user block. In the memory layout above for example, UserBlock3 resides in only one physical sector but with three instance placeholders. First Instance1 is written, then Instance2 and last Instance3. By reserving space for three instances of this block it is possible to provide the expected writes of 300000 for this user block. UserBlock2 is spread over four physical sectors (address 0x040 – 0x13F) to achieve the expected number of writes. UserBlock1 is rarely written, thus one instance of this block is sufficient. 

Garbage collection is used to free space for single blocks to allow further write operations. Since the physical sectors are that small, user blocks can be erased specifically, so that the instance placeholders are cleared for upcoming write requests. Erasing the physical sectors of one user block does not affect other user blocks, which significantly improves data safety. Thus, availability of user data which was successfully written once will never be compromised by any action to other user blocks. On the other hand, only a certain number of block instances is reserved at configuration time. If all instances are already filled with data upon a write request, it is necessary to erase all physical sectors of this user block before the actual write job can be performed.

All physical sectors of a user block need to be erased if writing of new data is requested and all instances of the block are already filled with data.
 


 

Note:

The SmallSectorFee always returns the content of the instance which was written last. Hence, if a write job fails, a subsequent read will never return valid data. Nevertheless, if any user data is critical and has to be readable in every case, the according user block can be configured as redundant in NvM configuration.


Due to this static addressing scheme, the Fee performance is predictable and nearly constant for single user blocks, because the search for the most recent instance of a user block is limited to its reserved memory area (i.e. physical sectors). No matter how often a block is written, the overhead for searching the most recent version is almost constant. SmallSectorFee does not split the flash memory into two logical sectors as it would be necessary if the physical sectors of the flash device were bigger in size but smaller in quantity (e.g. 16kByte – 128kByte in MPC56xx MCU family). Thus, flash usage is substantially efficient. User blocks are aligned to physical sector boundaries and due to the small size of 64 Byte sectors, the overhead for padding bytes related to the alignment is quite small.
 


 
This picture illustrates, how the effectively used volume of a single user block depends on its payload size and the expected number of writes. The used volume increases if the overhead due to physical sector and page alignments decreases, e.g. if the user data perfectly fits into a physical sector, so that there is no need for padding bytes.

  

Reference:
Refer to Technical Reference of SmallSectorFee in order to check how the overhead for a block can be calculated.

With a high number of expected writes and payload, up to 95% of flash memory can be used effectively for user data. In summary, SmallSectorFee enables the user to store significantly more data in flash memory than another Fee implementation would do. It is still not predictable how much user data exactly fits to a certain flash device (e.g. 32KB or 64KB) because the flash usage depends on block configuration (data size and expected number of writes).
 
 
 
Article Options
2019-01-29
Views: 224
Error(s) occurred processing form.
Please complete all required fields. Fields marked with * are required.