Memory Regions

MotoHawk™ provides a blockset that allows the user to control the behaviour and sizes of various memories. This allows the application to compartmentalise memory, associate behaviour to different regions of memory, improve control access and allow more optimal memory allocation via the exposure of memories that were otherwise hidden and/or reserved for use by specialized and/or system only purposes purposes, and (where applicable) improve non-volatile memory endurance.

• Memory Regions
• Overview
• Constraints
• Managing Non Volatile Legacy
• Behaviors
  • Buffered NV
  • General Purpose RAM

Overview

The Memory Map Definition allows a Memory Resource to be divided into regions and the Memory Region Definition block allows a behaviour and it's options to be associated with an individual region.

For example, each NonVolatile memory region can be saved at different times and rates, have different levels of access protection and buffering. Each available behaviour has different configurable features.

Constraints

• The Memory Resources available are target specific.
• A Memory Resource of the same name (Eg: EEPROM/FLASH) may have different block sizes in different targets.
• Behaviors available are target specific.
• Configuration options for each Behaviour can vary.
• Behaviour options for a specific behaviour may not be consistent across targets. Typically the difference arises when a an option is not applicable for the selected resource.
• A Memory Resource consists of a number of blocks of varying size. Therefore configuring a region to a specific number of bytes is not always possible.
• FixedNonVolatiles can only be stored in a region named 'SERIAL_EE' and it's behaviour is not configurable. If FixedNonVolatiles are to be used, then the user must ensure that the region 'SERIAL_EE' exists for legacy compatibility reasons.

Care must be taken when porting between targets. The user should check the Memory Map Definition to ensure that the allocated sizes are correct. Also each Memory Region Definition should be checked to ensure that the desired Behaviour is available and the Options correct.

Managing NonVolatile Legacy

Prior to Memory Region support, most targets supported a single NonVolatile region internally named 'SERIAL_EE'. The region name was never exposed as it was assumed by default. This region was subdivided into two types. NonVolatile and FixedNonVolatile as described in the NonVolatile Storage help.

The original blockset is fully supported, and the user may continue to use NonVolatiles as before, ignoring Memory Region functionality entirely. Memory Region functionality can also be used to reduce the size of the default 'SERIAL_EE' area and declare new regions in the freed memory.

Some targets use what has become a legacy device driver. This driver by default is Single Buffered, although it can be configured to be double buffered using the Buffered EEPROM Definition Block. More recent targets use the BufferedNV behaviour for NonVolatiles and FixedNonVolatiles that only supports double buffering but does otherwise include all of the features of the legacy driver in addition to being Memory Region compatible and more robust.

The user now has the option to:

1. Continue using the NonVolatile system as before as it is backward compatible
2. Force a target to use a particular behaviour for the default 'SERIAL_EE' region.
3. Split the NonVolatile memory into additional regions and configure an alternative behaviors for the new regions whilst continuing to use the existing 'SERIAL_EE' region as before using it's default driver.
4. Split the NonVolatile memory into regions and configure all regions to use specific behaviors.

Note: When re-configuring region sizes, existing NV data may not be retained on re-programming

Option 1 - Continue unchanged

The user can continue using the blocks listed in the NonVolatile Storage Block Summary. whilst ensuring the 'Use Memory Region' checkboxes are clear.

Option 2 - Force the use of a specific driver on the default 'SERIAL_EE' region

When a target by default supports the legacy NonVolatile behaviour, it is possible to re-configure it to use an alternative (e.g. BufferedNV) by using memory Regions.

• Use a Memory Map Definition to declare a single region named 'SERIAL_EE' on a compatible resource that consumes all of the available blocks.
• Use a Memory Region Definition to configure a behaviour (e.g. BufferedNV) for the 'SERIAL_EE' region.
• Remove from the model any existing NonVolatile Definition block.

Option 3 - Use a combination of NonVolatile blockset and Memory regions

Use a Memory Map Definition block to configure a region named 'SERIAL_EE' alongside custom regions on a non-volatile capable device. The custom region behaviors are configured using Memory Region Definition blocks.

The NonVolatile Definition block is used to configure the operation of the 'SERIAL_EE' region. 'Use Memory Regions' can be selected on the block, but the Memory Region Name must be 'SERIAL_EE'. If 'Use Memory Regions' is clear then the 'SERIAL_EE' region is used by default. The target uses the legacy NV behavior if that was its default configuration. The original default memory driver will be used.

Option 4 - Arbitrarily define name, location and behaviour for all NonVolatile regions.

Use a Memory Map Definition block to configure any number of regions and name them as desired. Configure the behaviour for each region using Memory Region Definition blocks. All accessor blocks must have 'Use Memory Regions' checked and the appropriate memory region name given.

Available Memory Region Behaviours

Here follows a list of behaviours that support Memory Regions. Not all Behaviours are available on all targets or Memory Resources.

• Buffered NV
• General Purpose RAM

BufferedNV

BufferedNV (Buffered Non-Volatile) is a behavior designed to work the NonVolatile Storage class.

The BufferedNV behaviour is available on most NonVolatile Storage devices. It features double buffering with CRC Checks to protect against data corruption upon an unexpected reset during a store operation

BufferedNV loads NonVolatile contents to RAM on startup and DataStore access is therefore fast. Data is saved back to the NonVolatile memory upon issuing a Store NonVolatile block. The current status is determined using the NonVolatile Status Get block.

When using Memory Regions The NonVolatile Definition block becomes superceeded and all conviguration options are available within the Memory Region Definition block when behaviour is selected to be BufferedNV.

Basic Operation

On Startup

Each data bank contains an Age value, FormatID and a CRC. The bank with the most recent Age is queried first, and the data is checked against the stored CRC and FormatID. If the match is good, then this data is loaded and becomes active. If the CRC is not matched, then the alternate bank is accessed and it's CRC and FormatID are checked. If the match is good, the data is loaded and becomes active. However if this CRC check also failed, then the Factory defaults as configured by the application are loaded. The status of the above operation is reflected in the NonVolatile Status.

On Store

The NonVolatileStore process can take some time and therefore it is configured to execute is a predefined task. The task used is configured by the ControlCore OS Definition block. If undefined, the default task is 'SHUTDOWNTask'. For this reason data coherency needs to be considered. See special considerations below.

The data is stored into the bank with the oldest Age value. A progressive CRC is calculated on the data as it is stored and saved. Once the data is verified, the bank is marked as valid and contains the newest Age value.

In Mirror mode, the above operation is executed twice on Store and data is saved in both banks. This takes longer and halves the device endurance on devices subject to wear.

Instrumentation Parameters

A number of parameters are available for instrumentation that are grouped in the tool by the 'Group' parameter and whose Read and Write access levels can be set. [Name] refers to the given region name.

Display Parameters

• [Name]_Age : Number of saves to the Region. If the Behaviour is changed from BufferedNV this value will likely be reset. Otherwise the value is preserved across programming events. This parameter is useful when checking that the endurance of the NonVolatile device is not exceeded.
• [Name]_CRCNVData : CRC of Data.
• [Name]_NVFormatID : Unique ID represents the 'layout' of the data. Will change when NV parameters are added or removed.
• [Name]_NVStatus : Status equivalent to using the NonVolatile Status block.
• [Name]_RestoreNVDefaultsCount : Number of times Restore Defaults has been issued.

Calibration Parameters

• [Name]_NVRestoreOnStartup : Selects whether to restore all NV in [Name] region from factory defaults on next startup
• [Name]_NVRestoreOnFirstStartup : Selects whether to restore all NV in [Name] region from factory defaults the first time the application boots after programming.

Special considerations

The user should be aware that the Store NonVolatile block takes a finite time. The application is permitted to continue executing, and therefore to mantain Data Coherency the user must avoid altering NonVolatile data during the store process. It is possible to use the NonVolatile Status Get block to determine if a Store NonVolatile operation is in progress.

A Time Slice (ms) parameter is provided to force the Store NonVolatile operation to yield to the Idle task and will resume after Idle has executed. This prevents the Starvation Timer Watchdog from triggering. Starvation can be an issue particularly at startup if the NV Memory is large and requires a full initialisation.

The NonVolatile Store task used can be selected using the ControlCoreOSDefinition Block when Advanced Tasking is enabled.

Associated Blocks

• NonVolatile Status
• Store NonVolatile
• Restore NonVolatile
• DataStore Definition
• Calibration Definition
• Prelookup Index Search
• Lookup Table 1D
• Lookup Table 2D

BufferedNV Option Parameters

Parameter Field	Values	Comments/Description
NV Action After Programming	Drop down	Following a reprogramming event: TryToLoadPrevious attempts to load the last set of values. RestoreDefaults restores data to the factory defaults configured in the application
Mirror	Drop down	When true, both banks of the NonVolatile store are saved one after the other on an Store NonVolatile operation. This will halve the endurance of the device (if applicable) but ensures that on startup both banks contain the most recent data.
Time Slice	Numeric (ms)	A Store NonVolatile can take a significant time to complete. The task that it executes in will always execute at a priority above Idle and therefore can cause the Starvation Timer Watchdog to expire if it takes too long. When the Store has been executing for longer than 'Time Slice', it is forced to yield to Idle and will only resume after the Idle task has completed an execution pass. To never yield use a time that is greater than the Starvation Time.
Read Level	0-8	Sets security level (1 lowest, 8 highest) for instrumentation read access. A setting of zero indicates unsecured access is allowed.
Write Level	0-8 or (Read Only)	Sets security level (1 lowest, 8 highest) for instrumentation write access. A setting of zero indicates unsecured access is allowed. Read only prevents write access.
Group (Instrumentation)	Alpha-numeric text, single-quote enclosed	Defines the folder name and hierarchy to be used by a suitable instrumentation tool. Use "|" character between folder names to delineate subfolder structure.

General Purpose RAM

The General Purpose RAM behavior is a memory region behavior associated with Volatile data storage. It includes all explicit Volatile Storage, but also caters for implicit storage required by the software system (RTOS, device driver etc) and also by Embedded Coder. For instance, consider a 1/z block, which implicitly requires static memory to implement the delay. This static storage must be declared and (until now) was implicitly assigned to a particular memory region. Memory Region's General Purpose RAM behavior allows aspects of this allocation to now be controlled by the developer.

The primary purpose behind the General Purpose RAM Memory behavior is to allow memory to be compartmentalised, and to allow memory to be declared across multiple memory devices that may not be contiguous and/or may have have intrinsic behavior associated with the memory that makes it more suited for use in a particular area. Attributes that can distinguish one memory from another include:

• Whether it supports ECC (Error Code Correction) or not. A memory that supports ECC is more suited to critical variables, so a developer employing an MCU (Micro Controller Unit) that supports memory with ECC as well as memory without it may desire to locate memory required by non-critical functions to the memory that is not ECC capable. Memory Regions make such an allocation possible.
• Speed of access or locality of the memory. For instance a memory in a multi-core MCU may allow all cores to access a particular memory, but priortise and optimize access by one particular core. A developer that wishes to take advantage of such capability needs the ability to allocate memory with this in mind.

Only memories capable of supporting a Volatile Storage class can be assigned a General Purpose RAM Memory Region behavior. Attempting to include Memory Regions with this behavior in (say) a Non-Volatile Memory Map or have (say) a Non-Volatile data store reference a Memory Region with the General Purpose RAM behavior will result in errors during Simulink model check.

General Purpose RAM Option Parameters

Parameter Field	Values	Comments/Description
Use For Default Storage	Checkbox	Memory declarations like static memory allocated by a device driver or Simulink block that does not explicitly specify a memory region are allocated to the default memory region. It is ambiguous to assign more than one memory region to default storage and it is typically an error condition to fail to assign a memory region as default storage. It is considered typical because a module's memory devices might not be completely remapped by the application and/or regions may have been named such that they imply default operation. It is recommended to be as explicit as possible. This option is only visible for memory resources that can support such behavior and will be hidden otherwise.
Use For System Storage	Checkbox	System storage refers to certain memory storage related to the instantiation of the software system. For example, some aspects of the tasking kernel require a region of system storage. It can be ambiguous to assign more than one memory to system storage, however multicore modules may require one allocation per core. A build will warn when ambiguous assignments exist and error if system storage definition is inappropriate. Assignments are module specific. This option is only visible for memory resources that can support such behavior and will be hidden otherwise.
Use For Bulk System Storage	Checkbox	Bulk system storage refers to certain memory storage related to the instantiation of the software system when a large (bulk) memory. For example, some ethernet drivers assume a bulk storage device exists and will designate certain variables be declared in this region. This checkbox allows a developer to identify that a remapped region can be used for such system storage. This option is only visible for memory resources that can support such behavior and will be hidden otherwise.
Use For High Performance Storage	Checkbox	Some CPUs allow a portion of their memory to be considered high performance. For example, MPC5xxx MCUs designate that a Small Data Area (SDA) shall exist and associate a register (R13) to reduce the number of instructions required to read or write variables kept in the SDA region. Some drivers will explicitly declare variables to be located in this region. This checkbox allows a developer to identify that a remapped region can be used by the system to house these variables. This option is only visible for memory resources that can support such behavior and will be hidden otherwise.