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.
Click here for a list of supported targets and target information
motohawk_target_def
MotoHawk_lib
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.
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.
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 |
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. |
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. |
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. |
Copyright 2009-2015 Woodward Corporation. All Rights Reserved. | Visit Us: mcs.woodward.com |