This post provides some tips I’ve learned for working with S12 modules from the MotoHawk lineup.
The toolchain for the S12-based MotoHawk is different from all the other modules. For the S12, you will require FreeScale’s CodeWarrior compiler. This for-purchase compiler can be obtained online and generally you can get started right away using the 30-day trial feature. During the 30-day trial you will have what appears to be a full-functioning license. This trial allows you time to secure a full license or merely experiment. There are different versions of this compiler, please refer to the Freescale documentation to find the most suitable and compatible version of Codewarrior for your machine. While the other modules have the free compiler option of GCC, this does not apply to the S12 MotoHawk modules.
Note: After the 30-day trial is complete, there is a 32 KB compiler limit. This is too small for most applications and will result in a link error which manifests itself in an error during build that will look similar to below:
>>ERROR L1102: Out of allocation space in segment RAM_BLOCK0_SEG at address 0x3BFC
>>Error using ==> motocoder_codegen at 84
One of the first issues you will discover upon attempting to build your MotoHawk model targeted to the S12 is that the base project, generated by the ‘motohawk_project’ script, does not compile! This is evidence of the memory constraints of the lower-cost module family. As a comparison, in the table below is a comparison of an S12 module to the 55xx 112-pin module.
Compared to the 55xx module, the S12 module has:
- 6.25% of the FLASH
- 12.25% of the RAM
- 6.25% of the EEPROM
As you can imagine this can have significant bearing on your software design. Looking at the default memory allocations in the target definition block, we see:
Since these add up to 13.5K, which is larger than the 8K of RAM that is available on the S12 module, we know it won’t compile this way. These settings will vary based on your application’s profile, but recommended starting values might be:
These values add up to 4.75K which is just over half the total RAM for the module. These should be adjusted as needed by your application.
If you are curious what each of these ‘stacks’ are all about, here is some more information.
Not all S12-based modules are listed in the MotoHawk Target Definition block. A part of the reason for that is the evolution of these modules over time which resulted in part number and name changes. This chart provides information about the evolution of SECMs.
Further, for certain targets you will have to select a target other than that listed on your module. The following cross reference (from the MotoHawk Help documentation) is helpful in selecting the proper option in the MotoHawk Target Definition block. In addition, something to double-check would be the ‘Memory Layout’ option just below the Target Selection. That option defaults to DEV so needs to be set properly according to your target.
Programming the module
If you would program these modules under conditions like the following, you would have to be aware that the module will have non-standard City IDs by default. These conditions are:
- Programming the module for the very first time after purchasing it.
- Using a boot harness to program the module.
- Always until the City ID change has been made through a change in CAN settings in the model.
All this calls for setting up another MotoTune port to reflect the right City ID.
If you are using a boot harness then after flashing the module, you would have to switch over to a normal development or programming harness in order to access the application over MotoTune. The boot harness will for the module to stay in boot mode otherwise.
Another issue that will result from selecting a target which is different from the label on the module is a MotoTune error message that looks something like this:
If you have selected the proper target from the list above, it is safe to click on YES to program anyway. This will not affect the normal running of the program.
Controlled Shutdown – NonVolatile RAM
The Small Engine Control (SECM) S12 modules (ECM-0S12-024-0801, ECM-0S12-024-0802, ECM-0S12-024-0804, ECM-0S12-024-0502, ECM-0S12-024-0503) do not have a KEYSWITCH input. As a result, these modules do not operate with a ‘controlled shutdown’. Normally, during a controlled shutdown software found within the ‘Main Power Relay Block’ will cause datastore values set as ‘NonVolatile’ to be written to the module’s EEPROM memory. Without a controlled shutdown, the application will have to store Nonvolatile data manually using the ‘MotoHawk NonVolatile Store’ block. Since the EEPROM memory has a limited write-cycle lifetime (approx 100,000 times), the application must issue the store command judiciously. As an example, issuing the command once per second would burn out the EEPROM in a day or so.
If you happen to program an invalid application into a module, or are otherwise unable to communicate with the module you may need to ‘boot’ the module to recover. The ‘boot’ procedure prevents the module from beginning execution of the user application on startup for some period of time – the processor is kept in the bootloader awaiting reprogramming commands. The S12 family of MotoHawk modules don’t all use the standard boot key that other modules do. Certain modules require a special ‘boot harness’ which provides a combination of I/O states that the module recognizes as a signal to stay in ‘boot’ mode.
SECM Boot Harness
GCM 24 Boot Harness
The ‘MotoHawk Application Monitor’ sets up a monitor within your application that checks critical system parameters as your application executes.
While monitoring these parameters it will halt the application if usage exceeds certain thresholds you configure within the mask for this block. Although the application is halted when a threshold is exceeded, the MotoTune protocol handler should continue to execute meaning that you can inspect the state of the controller using MotoTune to determine what has occurred. The following MotoTune Display variables are useful in working with the App Monitor:
Configuring the Application Monitor for the S12 is done via parameters in the target definition block for most parameters. There is a separate block for the starvation timer. The parameters available are shown in the table below:
The App Monitor can stop your application for the following reasons:
- App Monitor Notification Stop
- Application Stopped (User Command)
- Starvation timer margin violation
- Heap margin violation
- Idle stack margin violation
- Interrupt stack margin violation
- ApplicationInterruptTask stack margin violation
- BGNDTask stack margin violation
- SHUTDOWNTask stack margin violation
- FGNDTask stack margin violation
When the application monitor stops your application for one of these reasons, it is because a condition has been detected that needs to be resolved in your software. Often times, all that is required is adjusting the stack sizes to better match your application, but for applications that are approaching the resource constraints of the module, this can involve tradeoffs and optimizations.
This has been made into a PDF guide at: here