Target Definition

Place this MotoHawk™ block somewhere in each MotoHawk code-generation model, typically at the top level, to select the type of module to be used by the model. The block allows key operating parameters to be defined for use by the module including the stack sizes used by ControlCore's Tasking Kernel.

This block is also used to create a MotoHawk component.

Supported Targets and Target Information

Click here for a list of supported targets and target information

Block ID

motohawk_target_def

Library

MotoHawk_lib

Description

The Target Definition block is placed initially by default; it is good practice to select the required target module, as a first step, if different than the one initially displayed. This is required in order to specify the type of ECU to be programmed, and predetermines the availability of appropriate parameters in certain blocks (double-click on a block to edit the parameters).

The target cross reference assists selection of Target based on hardware.

If "Component" is selected as the Target type, the model and contained components and implied algorithms are stored as a usable model subsystem analogous to a program function or subroutine.  The component can be placed in a model; it is pre-compiled and thus takes less build time and space. Use of components is most strategically advantageous when a larger model requires extravagant compilation times; in this case portions of the model might be sectioned off and complied as component pieces.  Components can be encrypted and passphrase protected for security purposes.

Stack and Heap Allocations

What is Stack?  Each task within the application has an area of memory associated with it from which automatic variables within functions are allocated. As the application progresses through each function call (which itself makes further function calls), each local variable within that function reserves an area of stack to hold its value. The maximum stack needed for the task is theoretically the sum of the stack allocations made at the deepest level in the function call tree. There are some useful metrics taken by the ControlCore™ operating system and can be monitored under the folder: System | Memory | [TASK_NAME]TaskStackMinBytesFree, where TASK_NAME is usually FGND, BGND, ApplicationInterrupt, etc.

It is the application designer's responsibility to ensure adequate stack allocation.
The operation of the software is not deterministic when there is inadequate stack and the software may suffer from unexpected resets due to the CPU Operating Properly watchdog intervention. The application monitor may be used as a debugging aid to a module experiencing inadequate stack allocation.

How does ControlCore™ determine stack depth?  The tasking kernel fills each task stack with a predetermined pattern during stack creation. It then periodically counts (while idle) the number of bytes, starting from the end of the stack, that still contain the prestored pattern. As stack is used the prestored value is overwritten and thus the count is representative of the minimum bytes free metric.

Note: It is possible that a non-zero minimum bytes free metric is provided by ControlCore™, but the stack allocation is still too small. In this case, there is a possibility that a function call allocates past the end of the stack, corrupting the data beyond the end of the stack, and yet some small block at the very end of the stack still has the known pattern present. A function that allocates an array to the stack, but doesn't modify every element of that array during its execution is an example where the stack was allocated but the known pattern may remain present.

Before determining the "proper" stack allocations, Woodward recommends a very large stack allocation be made (due to memory constraints this may need to be done one task at a time). The application should be run such that all alternate code paths of the application have executed, and a margin of safety applied to the experimentally determined maximum stack depth.

The Task Info block can be used by an application to query stack usage and a custom stack monitor can be included in the application.

What is Heap?  Heap is a global area of memory from which dynamic allocations of memory may be made. Unlike stack, areas of heap are reserved (allocated and freed) in a manner which is not necessarily synchronous to the function calls made by the application. The pattern of allocation and size of blocks is not known until run time. The ControlCore™ operating system has a metric for heap usage which can be monitored from the same location as the stack metrics described above.

Block Parameters

Target Definition

Parameter Field Values Comments/Description
Target Drop-down list Pick Target ECU for model
Memory Layout DEV, PROD, DEV+PROD Select intended ECU memory usage  - some modules have development (DEV) versions with additional memory configuration, as differing from the intended production usage (PROD).
Floating Point Type single(32), double(64), disabled Select the memory usage for floating point values storage

Target OS

Parameter Field Values Comments/Description
Use Advanced Target OS Configuration Check Box Checking this option will allow the developer to have greater control over the configuration of the OS that will execute on the target. The Module-Related options will not be visible when this option is checked and instead those options will be configured via separate blocks like the ControlCore OS Definition block. This option will only be visible if the selected target supports such configuration.
Target OS Drop-down The type of OS that executes on the Target. If disabled then the Target OS is fixed based upon the selected Target.
Module-Related (only visible when Target selection is a Module and Use Advanced Target OS Configuration is not checked)
Foreground Stack Size (Time-Based) Numeric Used for temporary variables required by the foreground periodic events. On 5xx targets must be a multiple of 8 bytes with a minimum of 512 bytes. On S12 or 55xx targets any positive integer will work. Run-time stack usage can be monitored by instrumentation tools (System | Memory).
Foreground Stack Size (Angle-Based) Numeric Used for temporary variables required by foreground angle events (Hires, _30 ...). On 5xx targets must be a multiple of 8 bytes and have a minimum of 512 bytes or be 0 bytes. On S12 or 55xx targets any positive integer will work. If this is set to zero then the Foreground Angle Task is not created, which will result in all the application's angle based events being serviced at the same execution priority as the Foreground time based events. Run-time stack usage can be monitored by instrumentation tools (System | Memory).
Background Stack Size Numeric Used for temporary variables in background periodic events. On 5xx targets must be a multiple of 8 bytes with a minimum of 1024 bytes. On S12 or 5xxx targets any positive integer will work. Run-time stack usage can be monitored by instrumentation tools (System | Memory).
Idle Stack Size Numeric Used for temporary variables in idle events. On 5xx targets must be a multiple of 8 bytes with a minimum of 512 bytes. On S12 or 55xx targets any positive integer will work. Run-time stack usage can be monitored by instrumentation tools (System | Memory).
Interrupt Stack Size Numeric Used for temporary variables during an interrupt (CAN message, crank tooth) . On 5xx targets must be a multiple of 8 bytes with a minimum of 512 bytes. On S12 or 5xxx targets any positive integer will work. Run-time stack usage can be monitored by instrumentation tools (System | Memory).
Application Interrupt Stack Size Numeric Sets the stack size for application driven interrupts. Only available on S12 and 5xxx targets. Run-time stack usage can be monitored by instrumentation tools (System | Memory).
Shutdown Stack Size Numeric Sets the stack for the shutdown tasks. Only available on S12 and 5xxx targets. Run-time stack usage can be monitored by instrumentation tools (System | Memory).
Heap Size Numeric Generally used for resources (PWM) and queue overflows. For GCC on 5xx targets Heap must be a multiple of 128 bytes, and must be at least 1024 bytes. For GHS on 5xx targets Heap must be a multiple of 2048 bytes, and must be at least 2048 bytes. For the S12 or 5xxx targets using CodeWarrior or GHS any positive integer will work. Run-time stack usage can be monitored by instrumentation tools (System | Memory).
Foreground Stack Margin [bytes] Numeric This triggers the Application Monitor Definition 2nd Generation when less than this number of bytes are free in the periodic foreground stack.
Foreground Angle Stack Margin [bytes] Numeric This triggers the Application Monitor Definition 2nd Generation when less than this number of bytes are free in the angle based foreground stack.
Background Stack Margin [bytes] Numeric This triggers the Application Monitor Definition 2nd Generation when less than this number of bytes are free in the background stack.
Idle Stack Margin [bytes] Numeric This triggers the Application Monitor Definition 2nd Generation when less than this number of bytes are free in the idle stack.
Interrupt Stack Margin [bytes] Numeric This triggers the Application Monitor Definition 2nd Generation when less than this number of bytes are free in the interrupt stack.
Application Interrupt Stack Margin [bytes] Numeric This triggers the Application Monitor Definition 2nd Generation when less than this number of bytes are free in the application interrupt stack.
Shutdown Stack Margin [bytes] Numeric This triggers the Application Monitor Definition 2nd Generation when less than this number of bytes are free in the shutdown stack.
Heap Margin [bytes] Numeric This triggers the Application Monitor Definition 2nd Generation when less than this number of bytes are free in the heap.

Component

Parameter Field Values Comments/Description
Component Name Alpha-numeric text, single-quote enclosed Name for Component block. No special characters, such as spaces, dashes, commas (underscore allowed)
Component Image Alpha-numeric text, single-quote enclosed Source file for image that appears in component block (file must be placed in component folder).
Security Level Select type of security for Component access.
  No Encryption No encryption applied
  Encrypt Embedded Build - Allow Simulation Access to build prevented (without passphrase), simulation allowed
  Encrypt Entire Package Passphrase required for simulation and use
Build Passphrase Alpha-numeric text, single-quote enclosed Passphrase required for access to component build (for simulation)
Wrapper Passphrase Alpha-numeric text, single-quote enclosed Passphrase required for access to component (for any use).
Allow multiple instances of the component (less efficient) Check box (enable) Enable use of multiple component instances in a single model.

Files

Parameter Field Values Comments/Description
DLL Filename Text, single-quote enclosed (Optional) Specify the name for .dll file(s) - if unspecified, the model name is used. Do not include the file extension (.dll) in the entry. If you would like to utilize a MotoTune DLL name of greater than 13 characters, a version of MotoTune 8.13.8 or greater must be used. Prior to this point MotoTune only supported up to a 13 character DLL name.

Only visible when a component has not been selected.
SRZ Filename Text, single-quote enclosed (Optional) Specify the name for .srz file(s) - if unspecified, the model name is used. Do not include the file extension (.srz) in the entry.

Only visible when a component has not been selected.
Component Directory (absolute, relative to model, or current directory if empty) Text, single-quote enclosed (Optional) Specify the local directory for component file(s). If empty, the current directory will be used. If specified, it may be an absolute path, or be relative to the current model location by starting with "."  

Only visible when a component is in use.