StarProg Help

Overview

StarProg is a universal solution for downloading software to 68HC12/HCS12 systems. StarProg can program, verify and erase build-in EEPROM and Flash memory as well as externally connected memory devices.

StarProg makes use of the ComPOD12, ComPOD12/PRO or ComPOD12/NG BDM Hardware Interface to access the HC(S)12 target microcontroller.

The methods for programming the target memory are not built into the StarProg Software in a fixed, unalterable way. Instead of such a static implementation, the algorithms are contained in separate Toolfiles, which makes StarProg very flexible for future extensions.

Getting Started

To install StarProg, simply copy the contents of the ZIPed distribution file to a directory of your choice. For an update, you should delete the files of the previous version at first.

After invoking StarProg for the first time, the appropriate BDM hardware interface type (either ComPOD12, ComPOD12/PRO or ComPOD12/NG) and the PC's COM port must be selected (see menu item Setup/BDM_Interface...).

Under Setup/Select_Target there is a list of supported target types. The term target means some type of memory of a particular HC12 or HCS12 derivative, i.e. MC9S12DP256 Flash. If an MCU has more than one non-volatile memory type (e.g. EEPROM and Flash) then StarProg will use a different target for each type of memory.

The standard version of ComPOD12 uses a fixed BDM clock of 8MHz, the ECLK field just shows "default" in this case. If the ComPOD12/PRO is used, the BDM clock of the target can be selected from a list. When using the ComPOD12/NG, also BDM clock setting not included in the list can be established by editing the input field.

If all hardware connections are made and the target is powered up (the Pod will get power from the target) then you are ready to go. Before any attempt to program or erase a target, please make sure the appropriate settings are active. Always check the status line at the bottom of the StarProg window.

Warning: Using the wrong program settings or changing the ini-file manually can easily result in a damaged target controller! If you have any doubts about program settings and handling procedures, please contact us before hitting the wrong button!

Menu & Command Reference

File/Open
	Ctrl-O	Open an S-Record or binary file. Binary files will be converted into an internal S-Record representation, therefore the user must specify the starting address (offset) and the desired S-Record type (S1 or S2). Drag&Drop can be used as an alternative way to open a file.
File/Save
	Ctrl-S	Save the current data as an S-Record file. Alternatively, if there are no "gaps", the data block can also be saved in binary format by selecting the appropriate file type
File/Align
-	-	Align programming data currently loaded according to target memory requirements (refer to section Alignment for details)
Target/Erase
	Ctrl-E	Erase the target memory. This normally causes a chip erase, i.e. the selected type of memory will be erased completely including all sectors, boot blocks etc. (if any).
Target/Blank check
	Ctrl-B	Check if the target memory is erased. Normally, erased state means all bytes are $FF.
Target/Program
	Ctrl-P	Program data, i.e. write current data into target memory. A warning will be issued, if some data bytes do not fit into the target address range.
Target/Read
	Ctrl-R	Read out target memory. User must specify address range to read and desired S-Record type (S1 or S2).
Target/Verify
	Ctrl-V	Verify S-Record data vs. target memory contents. A warning will be issued, if any bytes of the S-Record data do not belong to the target address range. Verify will stop at the first difference encountered. In this case a dialog box will show the address and which values were expected/found.
Target/Auto
	Ctrl-A	Production Mode: Performs Blank check, Program and Verify in an endless loop. At the beginning of each loop iteration the user is asked for confirmation to proceed with another target device.
Target/Secure
	-	Secure HCS12 Target. Prevents BDM access until an Unsecure cycle is applied. Do not use this function unless you are absolutely sure about the consequences! Only available on HCS12 devices. ComPOD12/PRO or ComPOD12/NG required.
Target/Unsecure
	Ctrl-N	Unsecure HCS12 Target. All Flash and EEPROM memory of the target will be erased and BDM access will be re-enabled. Only available on HCS12 devices.
Target/Run
	Ctrl-U	Run Target Application by performing a Normal Mode Reset (leaving BKGD high during Reset)
Setup/Select Target
-	Ctrl-T	Select a target type. A list box contains entries like "MC9S12DP256 Flash" describing a specific memory type in a certain HC(S)12 derivative (both together form a "target"). StarProg generates this list from the entries found in the .ini-file. After selecting a target, the applicable memory ranges for both S1 type and S2 type data records are displayed. If the target does not support paging, only the S1 range is displayed. The standard version of ComPOD12 uses a fixed BDM clock of 8MHz, the ECLK field just shows "default" in this case. If the ComPOD12/PRO is used, the BDM clock of the target can be selected from a list. When using the ComPOD12/NG, also BDM clock settings not included in the list can be established by editing the input field.
Setup/BDM Interface,Port Settings
-	Ctrl-I	Select the BDM hardware interface type (either ComPOD12 or ComPOD12/PRO or ComPOD12/NG) and the COM port used. The interface speed is fixed.
Help/Help Topics
-	F1	Show help information for StarProg (this file).
Help/About
-	-	Display program information - contains version information and a link to the StarProg Homepage
Goto Addr
-	Ctrl-G	Jump to a specific address within the data display. Input hex value with max. 4 digits to access the S1 address range or 5+ digits to access S2 addresses. Command will be ignored if current data does not contain the requested address. This command is also available via context menu - right-click mouse while cursur is over data display!

File Handling

StarProg uses the Motorola S-Record file format to read and write files as well as for internal representation of data. S-Record files contain both, address and code information, while bonary files only contain code. To load binary files, the user needs to specify a starting address (offset) and the desired S-Record type (S1 or S2, see below). The binary file will then be converted by StarProg automatically.

S-Record files are simple text files. Therefore, it is possible to view and edit them using a normal text editor. Each S-Record line contains a certain amount of data bytes, information about length and starting address of the data and a checksum. For a detailed description of the S-Record file format see this text document.

There are several S-Record types which are indicated by the first two characters in each line. StarProg can process S-Records starting with the identifiers S1, S2 ,S8 and S9. S1 and S2 records contain data while an S8 or S9 record is just an end-of-file marker.

S1 records use a 16 Bit address specifier. The address range is 64KB. S1 records specify MCU addresses (addresses as seen by the CPU12).

Though the MCU can only access 64KB at a time, the address range can be extended by a memory paging mechanism. Since several HC12/HCS12 MCUs already have built in paging support (e.g. HC812A4, MC9S12DP256), code sizes of greater than 64KB are possible. To represent such data, S2 records with a 24 Bit address specifier are used.

StarProg also can process S-Record files which contain a mix of S1 and S2 records.

Paging

As mentioned before, S1 records cover the 16bit address range which the CPU "sees" within it's 64KB memory map. To specify the 24bit address of S2 records, two different standards are established: banked and linear S2 addressing. StarProg treats S2 adresses as linear memory addresses, in compliance with Motorola recommendations (for details see SRecCvt Reference Guide).

While S1 adresses can be considered CPU addresses, linear S2 adresses can be described as memory addresses. I.e. StarProg interprets S2 addresses like adresses seen by a memory device, either a virtual one (built into the MCU) or a real, externally connected chip. The S2 address range generally starts at $000000, even if the CPU "sees" the memory device at a totally different (CPU-) address.

What does this mean for the paging scheme of the HC12? Here is an example: The MC912DG128A has 128KB of Flash Memory. The whole Flash memory is divided into eight pages with a size of 16KB each. Within the program page window ($8000-$BFFF), the MCU can access one page at a time. The desired page is selected by writing to the PPAGE register. Additionally, the last page (page 7) is always visible in the (non-paged) top 16KB area ($C000-$FFFF). If a user program uses the address range of, say, $C000-CFFF, then there are two possible representations using S-Records. With S1 records, addresses would not be translated in any way, since this is how the MCU sees the program code natively. If S2 records were used, the program code could be found at the beginning of page 7. The starting address of page 7 in the Flash memory would be $01C000 (7x 16KB). Therefore, the example would occupy the S2 range $01C000-$01CFFF.

The HCS12 devices use the same paging scheme with one deviation: The first page number used is not 0. For example, the MC9S12DP256 Flash starts at page $30. As a result, the S2 memory range for the 'DP256 starts at $0C0000 ($30 * 16KB).

Please check the related Motorola data sheets and the reference guide mentioned above about details of the memory paging implementation.

Alignment

S-Records describe memory contents on a byte-by-byte basis. An S-Record can start at any address and can contain any amount of bytes (with a maximum of 64). In certain situations, such data has to be converted to a more suitable structure before programming. The reason for that is alignment: Depending on the memory architecture and technology, it may become necessary to program more than a single byte at a time.

The HCS12 Flash and EEPROM memory arrays are organized on a word basis. To program a memory cell, a word access to an even address is necessary. Writing a byte or misaligned word will result in an error. Therefore, only S-Records starting at an even address and containing multiples of two bytes can be directly used to program HCS12 EEPROM or Flash. Files not conforming to this alignment requirement will have to be converted before use.

The Flash technology used for the "A"-series HC12 MCUs (e.g. MC912D60A, MC912DG128A) also requires word writes. Furthermore, programming the Flash EEPROM of these MCUs is done on a row basis. A row consists of 64 consecutive bytes starting at any address that can be devided by 64 without remainder. In other words: alignment size for the D60A is 64 bytes.

To convert unaligned compiler output, the Motorola SRecCvt tool (written by Gordon Doughman) may be used. The following example will produce <outfile> by adjusting all S-Records of <infile> using an alignment size of 64 bytes:

c:\...\Motorola-SRecCvt\SRecCvt -m 0x00000 0xfffff 64 -o <outfile> <infile>

Details about the SRecCvt Utility can be found in the SRecCvt Reference Guide.

Alignment of programming data can be performed without leaving the StarProg environment by selecting the menu item Align in the File menu. This will invoke the SRecCvt utility passing the current (S19) file name and command line options based on the current Target selection.

INI-File Settings

The file StarProg.ini contains information about how StarProg handles the different targets. The current target is selected by the target entry in the [Global] section. The INI-File contains a sequence like this for each target configuration:

[MC9S12DP256 Flash]
ramstart=0x1000
start=0x4000
last=0xffff
start2=0x0c0000
last2=0x0fffff
eclk=8 4 2 1
security=1
alignment=2
toolfile=tf2_dp256_flash.bin
remarks=MC9S12DP256 Internal Flash

Warning: Do not edit/change the INI-file manually!

ramstart is the RAM address where StarProg will load the Toolfile. The Toolfile's name is defined using the toolfile entry. remarks contains a description of the target.

The allowed memory address range for user data is start..last for S1-Records. If S2-Records are allowed (target supports paging), the appropriate address range is defined using start2..last2. If this entry is missing, S2-Records are not supported by this target.

A toolfile may support more than a single target BDM clock setting. In such a case, the supported frequencies are listed in the eclk entry. Out of reset, the BDM clock equals the bus clock called ECLK, which is half of the external clock (crystal or oscillator clock). BDM clock frequencies other than 8MHz are only supported by the ComPOD12/PRO and ComPOD12/NG.

If the entry security is present with a value greater than zero, the functions secure and unsecure are enabled. The security feature is only applicable for HCS12 MCUs. Securing an HCS12 device is only supported by the ComPOD12/PRO and ComPOD12/NG.

The minimum program block size is specified using alignment. Values can range from 1 to 64. A value of 2 means word alignment. If this parameter is missing, alignment defaults to one (byte alignment).

StarProg is looking for the Toolfile in the current working directory first. If it does not find the INI-File at this place, the default INI-File is used, which resides in the same directory as the StarProg.exe. Thus, different configurations can be prepared by placing a copy as a local INI-File in a project directory.

Command Line Options

If a command line argument is given, StarProg will treat it as a name of a file to load at startup time. Append the switch /b to specify a binary file rather than an S-Record file.

Together with the method of using local INI-Files, StarProg can be configured for different programming jobs, which is especially useful in a manufacturing environment.

Simply use a Windows shortcut (on the desktop etc.) to specify working directory and command line argument.

Toolfiles

Toolfiles are the key component for StarProg's flexibility. When StarProg starts to communicate with the target, the first step is to download the appropriate Toolfile into the target's internal RAM. The name of the Toolfile for a specific target is taken from the INI-File.

All target memory specific commands (erase, program, verify etc.) are executed by the Toolfile running on the target MCU. StarProg does not need to know the details of the programming algorithms, since these issues are covered by the Toolile.

If you have a special programming task, which is not yet covered by StarProg, please contact us in order to check if a suitable new Toolfile can be implemented.

BDM Interface

StarProg works with ComPOD12, which is the hardware interface between Host PC and target microcontroller. This hardware interface (also called "pod") translates between RS232 (PC) and BDM12 protocol (target).

ComPOD12 is very easy to use. On the PC side any standard serial (RS232) port can be used to connect ComPOD12. The serial cable is part of ComPOD12. On the target side, a standard BDM12 connector is used. This 6-pin header connector looks like this:

Warning: Always make sure that pin 1 of the BDM12 cable (red stripe!) and pin 1 of the connector on the target board match exactly!

Warning: Always power down the target before attaching/removing the Pod!

VCC and GND are used as power supply connection. BKGD is the serial debug pin. It also controls the operating mode of the target MCU. /RES is used by the pod to reset the target. VFP is the programming voltage pin. A programming voltage is only required for some older 68HC12 MCUs (such as the HC912B32). The newer MC912D60A, MC912DG128A and HCS12 MCUs do not require a seperate programming voltage. If a programming voltage is needed, it must be supplied externally. ComPOD12 does not deliver any signal or voltage on the VFP pin, the pin is not connected internally.

The 5V power supply for the ComPOD12 is delivered over the BDM12 connection, i.e. the target board will supply the pod. Current consumption of the ComPOD12 is typically in the 25mA range.

Clock Issues

Out-of-reset, the BDM clock speed of the HC12 and HCS12 microcontrollers equals half of the oscillator clock. The oscillator clock is normally generated by the microcontroller's CRG (clock and reset generator) module with the help of an external quartz crystal. The maximum crystal frequency supported in this typical configuration is 16MHz. The resulting BDM clock is 8MHz, respectively. This clock rate is supported by all versions of ComPOD12.

Since the BDM interface of the HC(S)12 does not contain a clock line, the BDM pod has to know in advance, which frequency the target microcontroller is using. If the target would change it's BDM clock during operation, the BDM communication would become unpredictable and crash.

Using the PLL present in all HCS12 MCUs, it is easy to set the operating frequency (bus clock) of the MCU to any desired value on-the-fly. To avoid any impact of changing operating frequencies on BDM communication, the HCS12 BDM system by default uses the fixed oscillator clock determined by the external crystal, as described above. Doing so, the BDM connection always uses the same speed, even if the bus clock is changed by establishing new PLL settings.

A different configuration is to use the bus clock as the clock source for the BDM clock. This feature can be activated by setting the CLKSW bit in the BDM status register using a BDM command. As described above, making the BDM clock dependent of a (varying) bus clock is normally not desirable. There is basically only one reason to use this configuration anyway: to achieve a higher BDM data throughput, e.g. in a mass production environment. While the ComPOD12 and ComPOD12/PRO pod versions are not suitable for this particular situation (they only support BDM clocks of up to 8MHz), the ComPOD12/NG is more flexible (though, still not a device for mass production) and can handle BDM clock frequencies up to 40MHz.

There are two scenarios where the pod's frequency limit of 8MHz would actually mean a restriction: in case of an oscillator clock higher than 16MHz (such a clock could be delivered by an external clock source only, not the crystal quartz normally used) and in case of some early HCS12 devices, like the MC9S12DP256B. There was a mask set erratum causing the fixed clock option to behave faulty when using the PLL. This bug effectively prevents enabling the PLL on those devices while debugging with the default BDM clock. Please check the manufacturer's errata sheet in order to determine if this bug is present on the device you are going to use.

Target Requirements

The HC(S)12 target system should provide the following features in order to work properly with ComPOD12:

• 5V operating voltage, margin of at least 40mA to supply the ComPOD12(/PRO)
• 3..5V operating voltage range for the ComPOD12/NG
• mode pins MODA and MODB connected to L-level (pulled-down) to establish Single Chip Mode out of reset
• BKGD (mode pin MODC) connected to H-level using a pull-up resistor (4k7 is a good choice)
• pins BKGD and /RESET connected directly to the corresponding pins on the BDM12-connector (see above)
• the /RESET line must not be connected to a reset controller which could be able to lengthen a reset pulse coming from the microcontroller. This could cause erroneous program behaviour due to a wrong reset vector fetch! For the same reason, any large value capacitor on the /RESET line is forbidden in an HC(S)12 system.

The ComPOD12 requires a target BDM clock of 8MHz (provided by a 16MHz crystal) The ComPOD12/PRO has the same characteristics as the standard ComPOD12, but additionally supports systems with a wider range of BDM clock frequencies (from 8MHz down to 1MHz, i.e. using crystals from 16MHz down to 2MHz). The ComPOD12/NG supports a wide BDM clock range, starting at 250kHz up to 40MHz.

Support

For technical support please send email to support@elmicro.com

News about StarProg, updates and purchasing information can be found at the StarProg web page.

StarProg was written by Andreas Dannenberg and Oliver Thamm
Copyright ©2000-2005 by ELMICRO Computer GmbH & Ko. KG.
All rights reserved - unauthorized copying is prohibited. Standard disclaimer applies.

Software Revision 2.10 - Document Revision 1.9 - Changed: 200-03-21