Data Storage Blocks

C

MotoHawk:Blocks:Convert Reference to Integer

This MotoHawk® block converts the custom reference_T data type, which is output by a MotoHawk Data Storage Definition Block, into a uint32. Note that using the value of a raw pointer is highly unpredictable, and not recommended. This is here primarily for debugging references, because Probes cannot be directly connected to a reference_T type.

D

MotoHawk:Blocks:Data Definition Block

This MotoHawk® block defines data to be accessed via a MotoHawk Data Read or Data Write block. The 'Data Name' provides a globally unique name, accessible from anywhere in the model. It is illegal to have duplicate names. 'Storage Class' identifies the behavior of the data on the target. Volatile data will return to its 'Initial Value' on every startup. NonVolatile data will be saved in EEPROM, and return to the last written value on startup. An additional signal output will be present when 'Output Data Reference' is checked, which is of data type 'reference_T'. This is a pointer to the data, and may be used by the Data Read and Write blocks, to perform pointer-based access to data structures.

Checking 'Attach a VarDec for visibility in MotoTune' will show similar parameters as the Calibration block. If unchecked, the variable will not be available from MotoTune. A Structure Instance can be defined with the data type "struct". A structure name must be provided and must match the structure name specified in a "Structure Declaration" block. MotoTune VarDecs for structures are not specified in this block, but can be specified with the "Create Structure VarDec" block.

MotoHawk:Blocks:Data Read Block

This MotoHawk® block reads a value from data defined by a MotoHawk Data Definition Block. The 'Data Source' may be resolved by name, or by explicitly providing a dynamic reference signal. If "Structure Name" is selected, then the name of the structure instance must be specified along with the name of the field. If "Structure Reference" is selected, then the field is selected and a structure reference is provided as an input. The 'Data Structure' may be a Scalar, Vector, or Matrix. If Vector or Matrix is selected, an option is available to either output the entire data structure as a vector or matrix signal, or to use zero-based index inputs to determine the appropriate item within a larger data structure. The selection for 'Data Structure' and 'Data Type' must match the definition. An error is given if this does not match when the data source is by name. However, if the source is by input reference, the tool will not provide static error checking.

If 'No operation when null reference is input' is checked, an explicit check for a null pointer will be done, and zero will be output from the block. If this is unchecked, null pointers will cause a crash on the target. Note that no type, bounds, or data structure checking is ever provided on the target. Such issues will be caught by simulation, with explicit warnings.

MotoHawk:Blocks:Data Reference

This MotoHawk® block outputs reference(s) to the given data by name(s), using the signal data type 'reference_T'. It may be used by the MotoHawk Data Read or Data Write blocks, to perform pointer-based access to data structures.

MotoHawk:Blocks:Data Write Block

This MotoHawk® block writes a value to data defined by a MotoHawk Data Definition Block. The 'Data Source' may be resolved by name, or by explicitly providing a dynamic reference signal. If "Structure Name" is selected, then the name of the structure instance must be specified along with the name of the field. If "Structure Reference" is selected, then the field is selected and a structure reference is provided as an input. The 'Data Structure' may be a Scalar, Vector, or Matrix. If Vector or Matrix is selected, an option is available to either output the entire data structure as a vector or matrix signal, or to use zero-based index inputs to determine the appropriate item within a larger data structure. The selection for 'Data Structure' and 'Data Type' must match the definition. An error is given if this does not match when the data source is by name. However, if the source is by input reference, the tool will not provide static error checking.

If 'No operation when null reference is input' is checked, an explicit check for a null pointer will be done, and zero will be output from the block. If this is unchecked, null pointers will cause a crash on the target. Note that no type, bounds, or data structure checking is ever provided on the target. Such issues will be caught by simulation, with explicit warnings.

MotoHawk:Blocks:Data Storage

This block describes MotoHawk® data storage.

F

MotoHawk:Blocks:Fixed NonVolatile Manager

This MotoHawk® block allows placement of data stores with a known order in the Nonvolatile portion of your controller’s memory. This block may be used when particular variable(s) of the controller software must be maintained, even through various controller software upgrades.

N

MotoHawk:Blocks:NonVolatile Definition Block

This MotoHawk® block configures the behavior of the Non-Volatile data in the module after programming. On shutdown (or when the Store NonVolatile Data block is used), the RAM copy of Non-Volatile data is stored in Serial EEPROM. On the next startup, the module will use the previously saved values.

When the module is started the first time after programming with a new .srz, there are two options:

• Try to use the previously stored values from the previous program
• Use the factory default values as stored in the .srz file

Note that the previously stored values may only be used if the same NonVolatile variables are available in the new program as in the old one. If the stored NonVolatile variables do not match up with those expected by the new program, they will be restored from factory defaults, regardless of this setting.

Changing the model name, adding or removing any NonVolatile variables, or modifying the name, data type or size of any NonVolatile variables will force reloading from factory defaults. Any other changes to the model will not force reloading from factory defaults, and may therefore be used by the new program.

MotoHawk:Blocks:NonVolatile Status

This MotoHawk® block outputs the current status of the NonVolatile memory. Note that there is always a Display variable indicating this status available in MotoTune called NonVolatileStatus.

0: NV Currently Loading from Factory FLASH to RAM - This is set while performing the copy from factory defaults in FLASH to the working copy in RAM

1: NV Currently Loading from EEPROM to RAM - This is set while performing the copy from stored EEPROM values to the working copy in RAM

2: NV Currently Storing from RAM to EEPROM - This is set while performing the copy from the working area in RAM to the serial EEPROM

3: NV Loaded Factory FLASH due to change Format ID - This occurs when the stored EEPROM values do not match the structure expected by the model.

4: NV Loaded Factory FLASH due to CRC Failure - This occurs if the last stored values are corrupt, due to a power failure during write or bad memory

5: NV Loaded Factory FLASH due to User Request - This occurs if the user requested that factory defaults be reloaded into RAM, even though the values in EEPROM are OK.

6: NV Loaded Last Stored Values from EEPROM - This normally occurs when the model restarts, and no errors occur

R

MotoHawk:Blocks:Restore All NonVolatile Data from Factory Defaults

When this MotoHawk® block is triggered, all original NonVolatile definitions are reloaded from FLASH. These are the values provided in the 'Initial Value' field of the MotoHawk Data Definition block.

MotoHawk:Blocks:Restore NonVolatile Data from Factory Default

When triggered, the named NonVolatile Data Store definition will be reloaded from FLASH. This is the value provided in the 'Initial Value' field of the MotoHawk Data Definition block.

S

MotoHawk:Blocks:Size Of Block

This MotoHawk® block will return the size of the specified VarDec. It will output either the number of bytes, the total number of elements (rows * columns), number of rows, or the number of columns based on the output format. The output port data type is selected via the output data type parameter.

MotoHawk:Blocks:Store NonVolatile Data

When this MotoHawk® block is triggered, all NonVolatile definitions are saved to EEPROM, for later restoration. Note that if your model contains a Main Power Relay block from the Extra Development Blocks library, it will perform this action at controlled shutdown, prior to switching off the relay.

MotoHawk:Blocks:Structure Declaration

This MotoHawk® block defines the fields for a structure, the default values for those fields, and what enumeration should be used for each field.

Concepts behind Structures

The structure declaration describes the format of the data that an application designer is trying to describe. It is composed of fields (or members) and a name. Each field name must be unique and has an associated data type.

Structure declarations do not allocate any memory or define any variables. It is only a definition. Since this is the case, there is no overhead during the code generation process when placing a structure declaration block into an application. To create a structure declaration in MotoHawk, select the MotoHawk Structure Declaration Block from the MotoHawk palette.

Container

A container is how a structure declaration goes from the virtual (the declaration) to the concrete. Essentially, the container declares a dynamically-sized bucket that structure instances can be linked to at the end of the code generation process. The container contains the link to the display/calibration tool. Since the container contains all of the instances, it's data parameter can explicitly set the order of the instances in the VarDec. In the first version of the structure blocks, the container was hidden from the user and the structure declaration name was used instead. However, this placed a requirement that only one container could exist per structure declaration. In addition, all structure instances that used a given structure declaration were required to have the same storage type. These restrictions have been lifted and now the container explicitly specifies all of these parameters. So linking multiple containers to the same structure declaration is now possible. To create a container in MotoHawk, select the MotoHawk Data Definition Block from the MotoHawk palette and select 'struct container' in the data type drop down list.

Structure Instance Definition

The structure instance is the same conceptually as the Fault Definition Block. The application designer scatters structure instance definitions throughout an application and links them to a given container. The instance names and the field names are used to access the data in the container. The container itself is not used directly. The benefit of performing operations in this manner is that one structure instance does not affect another structure instance. In fact, even the structure instances do not affect their container until the end of the code generation process. This allows for more localized models that can be easily componentized. This is a powerful construct when developing applications such as Freeze Frame, Fault Manager, or other dynamically-sized data storage applications. To create a structure instance, select the MotoHawk Data Definition Block from the MotoHawk palette and select 'struct' in the data type drop down list.

F.A.Qs

Q: Are volatile data stores protected against access by different, asynchronous threads In other words, if one has one task in the foreground, and another triggered on crankshaft events, both reading and writing to the same store, do the read/write blocks ensure that there is no data corruption if the events coincide? Also, can one connect busses to data stores or do they have to be pre-defined as structures?

A: The writing of a scalar (or single index of a vector) will always be completed and not interrupted. But, the writing of a large vector could be interrupted midway through. To prevent against this, you can use the MotoHawk Critical Region block to group lumps of code that must finish completely before possibly being interrupted.