MotoHawk:Blocks:Target Definition

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.

The target selected within this block selects destination hardware.

Module Cross Reference

The Module Cross Reference Chart provides cross reference between the MCS modules and part numbers. You can click on a specific ECU target to see available IO and functionality supported in MotoHawk software.

Target Cross Reference

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 ECU, 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 [../MotoHawk_topics/_auto/CrossReference.xhtml 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 [ApplicationMonitorDefinition.html 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.

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.

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

Parameter Field	Values	Comments/Description
[../MotoHawk_topics/_auto/CrossReference.xhtml Target]	Drop-down list	Pick Target ECU for model.
Memory Layout	DEV, PROD, DEV+PROD	Select intended ECU memory usage - some ECUs 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
Build Directory (absolute, relative to model, or current directory if empty)	Text, single-quote enclosed	(Optional) Specify the local directory for build 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 "."
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 "."
ECU-Related (when Target selection is an ECU)
Foreground Stack Size (Time-Based)	Numeric	Used for temporary variables in 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 in MotoTune (System | Memory).
Foreground Stack Size (Angle-Based)	Numeric	Used for temporary variables in 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. Note: if this is 0 all angle based variables go into the periodic foreground stack. Run-time stack usage can be monitored in MotoTune (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 55xx targets any positive integer will work. Run-time stack usage can be monitored in MotoTune (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 in MotoTune (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 55xx targets any positive integer will work. Run-time stack usage can be monitored in MotoTune (System | Memory).
Application Interrupt Stack Size	Numeric	Sets the stack size for application driven interrupts. Only available on S12 and 55xx targets. Run-time stack usage can be monitored in MotoTune (System | Memory).
Shutdown Stack Size	Numeric	Sets the stack for the shutdown tasks. Only available on S12 and 55xx targets. Run-time stack usage can be monitored in MotoTune (System | Memory).
Heap Size	Numeric	Generally used for resource (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 55xx targets using CodeWarrior or GHS any positive integer will work. Run-time stack usage can be monitored in MotoTune (System | Memory).
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.
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.
S12 and 55xx Target Specific (when Target selection has a S12 or 55xx processor)
Foreground Stack Margin [bytes]	Numeric	This triggers the [./ApplicationMonitorDefinition2ndGeneration.html 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 [./ApplicationMonitorDefinition2ndGeneration.html 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 [./ApplicationMonitorDefinition2ndGeneration.html 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 [./ApplicationMonitorDefinition2ndGeneration.html 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 [./ApplicationMonitorDefinition2ndGeneration.html 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 [./ApplicationMonitorDefinition2ndGeneration.html 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 [./ApplicationMonitorDefinition2ndGeneration.html 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 [./ApplicationMonitorDefinition2ndGeneration.html Application Monitor Definition 2nd Generation] when less than this number of bytes are free in the heap.
Component-Related (when Target selection is "Component")
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.