Freescale Serial Bdm Programmer

Programming application 1: Replacing D-Bug12 monitor with serial monitor using HCS12FlashProgrammer: PGO has provided a cool utility program to turn our USBDM-1 into a standalone programmer without invoking the CodeWarrior. Warning: To use this feature, your USBDM must be installed successfully. It should be recognized by the Device Manger. BDM uses Standard Freescale 26pin to connect with BDM only uses one pin of the target microprocessor. The primary motivation for this was to produce a single BDM that could be used with a range of Freescale microcontrollers. Other features have also been added. The software may also be used to provide an on-board BDM for the Axiom MCF8006Demo board. Strangely, this board has a complete DSC BDM built-in but the firmware is not present. I have a number of Freescale MC9S08GT32 devices I plan to use in some projects if I can find the right toolchain. Code development would be Codewarrior, which is free for up to 32K of C code. Programmer/debugger is Background Debug Module (BDM), but this doesn't seem to be standardized; at least I couldn't find one on the Freescale website.

Freescale Serial Bdm Programmer Manual
Tutorial - Using The USBDM - Free
Programmer - Background Debug Module (BDM) Recommendation For ...
USBDM: USBDM Debugger Interface For Freescale RS08,HCS08 ...

NoICE for the Motorola/Freescale 68HC12 can be used with a serial monitor, like the other versions of NoICE. However, the 68HC12 chip includes a feature called Background Debug Mode, or BDM. Most 68HC12 evaluation boards and single board computers include a BDM port, usually using a 6-pin connector.

NoICE support for BDM is contained in an optional DLL (NComBDM.dll or NComCOMPOD.dll). Some BDM pods also require the installation of a vendor-provided driver. Currently supported are

Elektronikladen ComPOD12, available from Elektronikladen (http://elmicro.com/compod12.html)
P&E USB MULTILINK12, MULTILINK12, and CABLE12, available from P&E Microcomputer Systems (http://pemicro.com)
SofTec Microsystems inDART-HCS12 and PK-HCS12, available from SofTec Microsystems (http://www.softecmicro.com)
Technological Arts microBDM12SX, available from Technological Arts (http://www.technologicalarts.ca)
Wytec DragonBDM, available from Wytec (http://www.evbplus.com/Dragon_BDM/dragon_bdm.html)
Any other D-Bug12 pod containing 4.0.0b17 or later
Kevin Ross BDM12, no longer available, but still supported by NoICE
USBDM, an open-source BDM pod and interface library. Plans and firmware are available from http://usbdm.sourceforge.net/ Commercial pods are available from Technological Arts, Witztronics, Axiom and others.
TBDML, an older open-source BDM pod, largely replaced by USBDM
Axiom AX-BDM12, parallel-port pod formerly available from Axiom Manufacturing Company

Additional pods may be supported in the future. Contact us if you need support for a particular pod not listed here.

In addition to this document, you may wish to read the NoICE HC12 Tutorial at https://www.noicedebugger.com/tour. It contains step-by-step examples of configuring and using NoICE for HC12.

More information is available here on

Drivers for BDM Pods

Before you can use NoICE with your BDM pod, you may need to install the appropriate driver.

If your pod uses a serial interface (Elektronikladen, Ross, or D-Bug12), no driver is required besides the standard Windows serial driver.

For other pods, you should install the driver that came with the pod, or visit the vendor's web site to get the most recent driver. This is especially true if you are running Windows Vista, which tends to hate any driver older than a week and a half...

Installing and Connecting BDM

Follow the manufacturer's instructions for connecting and using your pod. In most cases, you will need to proceed in this order:

Turn off power to the target.
Connect the pod to the BDM connector on your target.
Tie the MODA and MODB pins of your target to ground (Single Chip mode). If you are using these pins as port pins, you may need extra circuitry to hold the pins low during reset. In conjunction with the BDM pod, NoICE will start the chip in Special Single Chip mode. If you start in any other mode, the processor will begin executing instructions immediately, and NoICE may not be able to control it.
If you are using a USB BDM pod, connect the USB cable from your PC to the pod.
Turn on power to the target.
If you are using a parallel or serial BDM pod, connect the cable from your PC to the pod.
Run NoICE.
Select 'Target Communications' from the 'Options' menu.
From the 'Interface' drop list, select the option appropriate to your BDM pod.
Edit the 'port' and other fields as appropriate to your PC and BDM pod as described below for Elektronikladen ComPOD12, P&E MULTILINK or CABLE12, USBDM, SofTec Microsystems, D-Bug12 (Technological Arts microBDM12SX, Wytec DragonBDM, etc.), Kevin Ross BDM12, TBDML Configuration DialogAxiom AX-BDM12.
Press 'OK'.

Once you have set up the BDM pod, you will not need to repeat the last four steps on subsequent runs.

To disconnect the BDM pod from the target, you will need to

Exit NoICE.
Disconnect the parallel cable from the pod (serial cables may be left connected).
Turn off power to the target.
Disconnect the pod from the BDM connector on your target.

Failure to follow the manufacturer's instructions for connecting and disconnecting may result in damage to the BDM pod or to your target.

BDM Configuration Dialog

This section describes the common items in the BDM configuration dialogs. Pod-specific information may be found below.

Your hardware must be set to come up in Special Single Chip mode. This is necessary so that BDM is active immediately after reset. If you start up in any other mode, your target will begin running whatever the reset vector points at. If this is not a very polite program, BDM will proably not be able to gain control of the target.

If you wish NoICE to access off-chip memory (typically to download code into it), you must change to another mode, and perhaps set up chip select outputs etc. The best way to perform such mode setting and initialization is to use the Play after Reset edit box to specify a command file to play when communications is initialized and after each reset. This is described further under Initializing the Target. You may use the Browse button to select the file.

Use the Target Chip/Environment list to select your target processor. Please be careful to select the exact chip that you are using. For example, the DG60 and DG60A use very different algorithms for programming Flash. Use of the incorrect algorithm may damage the chip. If you can't find an appropriate type, please contact the Author. 'Generic 68HC12' is safe in all cases, but will not allow you to burn Flash, use paged memory (PPAGE), or use hardware breakpoints.

Once you select a target, the Paged Memory, Hardware Breakpoint and Use Flash Burner checkboxes will be enabled if the selected target supports these features.

If your target has a PPAGE register, and you want to use paged (also known as expanded or banked) code memory and the CALL instruction, set the Use PPAGE checkbox.
If your target has hardware breakponts, and you wish to use them (usually to debug programs in Flash), set the Use Hardware breakpoints checkbox. Note that this will limit you to two or three breakpoints, but you may set them in Flash or other places where you you can't set BGND breakpoints.
If your target has Flash memory, and you wish to burn and debug programs in Flash, set the Use Flash Burner checkbox.
Note: Flash burning is not supported when using the Axiom BDM pod.

The Bus Frequency (MHz) combo box specifies the target bus frequency. This is one half of the crystal frequency. On some pods, this value may not be changable.

This field is a combo box: if the frequency you want isn't in the drop-list, just type the value. However, some BDM pods may not support arbitrary frequencies. Consult the documentation for your pod to determine its capabilities.

For some targets, Flash burning may only be supported at a single frequency (usually 8 MHz).

Elektronikladen ComPOD12 Configuration Dialog

Elektronikladen has manufactured several generations of ComPOD, a BDM pod with an RS-232 interface. NoICE will work with any of them, using the standard Windows serial driver.

Click on a field for more information about its function.

Select an available serial port from the Port drop list. The baud rate for the pod is fixed at 38,400 for the original ComPOD12, and 115,200 for the ComPOD12/Pro and ComPOD12/NG.

The Bus Frequency (MHz) combo box specifies the target bus frequency. This is one half of the crystal frequency. The original ComPOD12 supports only 8 MHz. The ComPOD12/Pro can support target bus frequencies of 1, 2, 4, or 8 MHz. The ComPOD12/NG can support any target frequency in the range 0.25 to 40 MHz.

Freescale Serial Bdm Programmer Manual

This field is a combo box: if the frequency you want isn't in the drop-list, just type the value.

For some targets, Flash burning may only be supported at a single frequency (usually 8 MHz).

Please read additional information about configuration

P&E MULTILINK and CABLE12 Configuration Dialog

P&E has manufactured a wide variety of BDM pods, including their original parallel-port CABLE12, several generations of USB Multilink, and a number of more complex devices. To use any of these pods, you must install the appropriate driver from P&E.

Click on a field for more information about its function.

Select the appropriate port from the Port combo box. If you are using the USB Multilink, select 'USB'. Otherwise, select the parallel port to which your BDM is connected. The BDM interface actually uses port addresses rather than LPTn numbers, so the addresses traditionally used by parallel ports are shown. When in doubt, go with the address, not the LPT number.

If you are unsure of the address of your parallel port, run the Windows Control Panel. Double-click on 'System', and select the 'Device Manager' tab. Expand the item labeled 'Ports (COM and LPT)'. Select your port, and press the 'Properties' button. Select the 'Resources' tab. The 'Input/Output Range' specifies your port's address.

If your parallel port's address doesn't match one of the selections in the Port list, you can enter the port's address in hex. NoICE will accept only addresses in the range 0x200 to 0xFFFF. Please be careful: addressing something other than a parallel port may cause your PC to do surprising (and generally undesirable) things!

If you are (still!) running Windows XP and find that you have trouble the first time you run NoICE after booting, but that things work thereafter, please read about disabling Windows port polling

The Pod Speed box shows a speed value used by the BDM pod. When you press 'OK' in the dialog, NoICE will determine the proper setting of the speed, and store it in the Registry. This process may take several seconds, so please be patient. On subsequent runs, NoICE will use the setting from the Registry for faster initialization.

If you use a firewall, you may receive a warning when you run NoICE for the first time after selecting a P&E pod. For example, the Windows XP Firewall says

'Windows Firewall has blocked this program from accepting connections from the Internet or a network.'

This is because the P&E BDM DLL supports all P&E BDM pods including an Ethernet version (Cyclone). The DLL runs an enumeration process that listens on a TCP port. Since NoICE does not support the Cyclone pod, you can tell your firewall to block access to the port. This should have no effect on NoICE.

Please read additional information about configuration

USBDM Configuration Dialog

USBDM is an Open Source project which includes a variety of BDM and JTAG pods, and the drivers and DLLs to interface with them. Hardware may be built from the Open Source documenation, or can be purchased from a variety of vendors.

NoICE operates with version 4.10 and later of USBDM. To use NoICE with USBDM, you must install the appropriate drivers and libraries from the USBDM distribution.

Click on a field for more information about its function.

The Bus Frequency (MHz) combo box must be set to match the speed of the target processor, or BDM will not operate correctly. This is usually one half of the crystal frequency.

Some USBDM pods can provide power to target boards via the BDM connector. Some pods provide a constant voltage, with the value set at 3.3 or 5 volts via jumper or switch. Other pods can turn power on and off under software control. NoICE's USBDM configuration dialog contains three controls to configure such pods. These controls have no effect when used with a USBDM pod that does not have power control.

The VDD drop-list specifies the voltage to be provided to the target. This setting has no effect when used with a USBDM pod that does not have power control.
The Leave power on at exit checkbox specifies whether or not target power should be turned off when NoICE exits. This setting has no effect when used with a USBDM pod that does not have power control.
The Cycle VDD on Reset checkbox specifies whether or not target power should be cycled in order to reset the target. This setting has no effect when used with a USBDM pod that does not have power control.

Please read additional information about configuration

SofTec Microsystems Configuration Dialog

Click on a field for more information about its function.

Select the appropriate hardware device from the SofTec Hardware drop list.

PressConfigure BDM... to open a dialog box that controls various settings for the SofTec BDM pod.

NOTE: the SofTec dialog has a checkbox labelled 'Do Not Modify EEPROM Contents'. In most cases, you will want to check this box. If you don't, then every time you load a program into Flash, the SofTec DLL will erase all of the EEPROM. Really.

Use the Target Chip/Environment list to select your target processor. The SofTec pods support only the MC9S12 family. They do not support non-S HC12 parts.

Please read additional information about configuration

D-Bug12 (Technological Arts microBDM12SX, Wytec Dragon, etc.) Configuration Dialog

NoICE requires version 4.0.0b17 or later of D-Bug12. NoICE uses the BDMDB commands, and will not work with versions of D-Bug12 that do not contain these commands.

Before using your D-Bug12 pod with NoICE, verify that it works correctly in pod mode with your target. Follow the instructions that come with the pod.

Once pod mode works, use your terminal program and the BAUD command to set the baud rate to be used with NoICE. Typically, this should be 38,400 or faster. The pod stores the baud rate in EEPOM, so you only need to perform this step once.

Exit the terminal program and run NoICE. Select an available serial port from the Port drop list. Select the correct baud rate for your pod from the Baud rate drop list.

Click on a field for more information about its function.

Tutorial - Using The USBDM - Free

Please read additional information about configuration

Kevin Ross BDM12 Configuration Dialog

Click on a field for more information about its function.

Select an available serial port from the Port drop list. Select the correct baud rate for your pod from the Baud rate drop list. Pod versions 4.5 and later operate at 115200 baud. Earlier pods may use lower baud rates. Note that the Ross pod uses RTS/CTS handshaking. Your serial cable must include both RTS and CTS.

The Bus Frequency (MHz) combo box must be set to match the speed of the target processor, or BDM will not operate correctly.

Pod versions 4.4 and earlier contain DIP switches that must be set to specify the baud rate and target processor frequency. Later versions of the pod can support target bus frequencies of 1, 2, 4, or 8 MHz. Refer to pod documentation for details.

NoICE does not support the MODA, MODB, RSRV1, or RSRV2 outputs of the Ross pod. You should use the 6-pin BDM connector rather than the 10-pin if your pod has both.

Please read additional information about configuration

TBDML Configuration Dialog

TBDML was an Open Source BDM project which included a BDM pod and the drivers and DLLs to interface with it. The TBDML code was later incorporated into the USBDM project, and the TBDML DLL was rewritten as a shim which used the USBDM DLL and drivers. However, distributions of USBDM after about 4.6 seem to no longer include a TBDML DLL.

NoICE supports the TBDML API on a legacy basis, mostly to support customers who have older versions installed. It may be possible to use at least some TBDML pods with USBDM, or to build the TBDML shim (which seems to still be part of the USBDM source tree). However, we cannot assist you in such efforts.

Click on a field for more information about its function.

The Bus Frequency (MHz) combo box must be set to match the speed of the target processor, or BDM will not operate correctly. The TBMDL can support any target frequency in the range 0.9 to 16.5 MHz.

Please read additional information about configuration

Axiom AX-BDM12 Configuration Dialog

Click on a field for more information about its function.

Select the appropriate port from the Port combo box. The BDM interface actually uses port addresses rather than LPTn numbers, so the addresses traditionally used by parallel ports are shown. When in doubt, go with the address, not the LPT number.

If you are running Windows XP and find that you have trouble the first time you run NoICE after booting, but that things work thereafter, please read about disabling Windows port polling

The Bus Frequency (MHz) combo box must be set to match the speed of the target processor, or BDM will not operate correctly. If you are using the older AX-BDM12 rather than the AX-BDM12A, the Bus Frequency must be set to 8 MHz, as the older pod does not support variable frequencies.

Note: Flash burning is not supported when using the AX-BDM12.

Please read additional information about configuration

Programmer - Background Debug Module (BDM) Recommendation For ...

Initializing the Target

NoICE serial monitors such as MONHC12.ASM initialize various ports and peripherals when they start up. They must do this in order to communicate with the PC, and the initialization is convenient for the user, who can download and test small programs without worrying about doing initialization. If you want to change the initialization, you can do so by modifying the monitor.

In contrast, the BDM version comes up having performed no initialization other than ensuring that BDM is enabled and active. All other values are as specified by Motorola/Freescale when the 68HC12 comes out of reset in the mode specified by your MODA and MODB pin settings (usually Special Single Chip). In particular

the mode may not be what you desire
the chip selects and clock stretching are not initialized
the UART (SCI) is not initialized
the port pins are not initialized
the stack pointer is not initialized

Depending on the configuration of your target hardware, you may need to initialize at least some ports before you can download code. For example, if your download RAM is connected to the CSD output of an HC812A4, you must properly program CSD before downloading.

The best way to perform mode setting and initialization is to place commands in a command file, and specifying the command file for Play after Reset. In most cases, the NoICE EDITcommand will be used in the command file to set the appropriate I/O register values. The Play after Reset file may contain any valid NoICE command. Note, however, that this file is PLAYedbeforeNoICE12.NOI when NoICE12 is started.

As an example, suppose that our target board is the Axiom CMD12A4, which we wish to operate in Special Expanded Wide mode in order to access external memory. The MODA and MODB jumpers on the board are set to reset into Special Single Chip mode. We need to

change the mode from Special Single Chip to Special Expanded Wide
enable E, LSTRB, and R/W
enable CSP0 from 8000 to FFFF with one wait state
disable CSP1
enable CSD from 0000 to 7FFF with one wait state
enable CS0, CS1, CS2, and CS3 for 8-bit devices, with 3 wait states

The following commands would be placed in a file called AxiomCMD12A4.NOI, and the file specified for Play after Reset.

A file called AxiomCMD12A4_BDM.noi containing the above commands may be found in the NoICEbin directory.

The NoICEbin directory also contains .NOI files to set operating modes of most current Motorola/Freescale HC12 variants. The files all assume that the hardware starts in Special Single Chip mode. The files will generally not operate correctly if the chip is started in another mode.

Flash Burning

'Classic' NoICE assumes that the program you are debugging is in RAM. This permits NoICE to easily download the program, and to set an unlimited number of breakpoints by writing bgnd or swi instructions.

However, providing enough RAM to hold the program is always a problem. Writing to Flash memory is much more complex than writing to RAM, and it is usually not possible to change the value of a single byte without erasing a larger area. Thus, the 'classic' model won't work for debugging programs in Flash.

Most of the HC12 family include two hardware breakpoints (some newer chips have three), which NoICE can use instead of bgnd/swi instructions during debugging. This leaves only the problem of getting the program to be debugged into Flash.

NoICE includes code licensed from Elektronikladen that can burn Flash for many members of the HC12 family. Flash burning is available for all supported BDM pods except the Axiom AX-BDM12.

The HCS12 family has a security feature controlled by the contents of the Flash word at address 0xFF0E/0xFF0F. The NoICE Flash burner forces this word to the value 0xFFFE. This disables security. The alternative would be to let you program the bits, and then have BDM be disabled the next time you reset the chip. NoICE is a debugger, not a production Flash burner, so we assume that you want to use BDM to debug your program.

Flash burner operation is as follows

At startup, the target is reset via BDM and any Play after Reset file is played.
The Target Type is used to specify the address range of Flash and RAM on the target, as well as an algorithm to be used to program the Flash.
If the Flash burner is enabled, the LOAD command does not immedately write data into the Flash address range, but caches the data on the PC.
At the end of LOAD, NoICE resets the target and does not play the Play after Reset file, because the burner program assumes a standard configuration.
NoICE reads and saves enough target RAM to hold a small Flash burner program, and then downloads and runs the program.
The program is used to erase and burn the Flash.
When burning is complete, target RAM is restored.
The target is reset via BDM and any Play after Reset file is played.
Any attempt to modify Flash using NoICE memory write commands other than LOAD will fail.

Some of the HC12 burner programs operate only at limited bus frequencies. The MC9S12 burner programs do not have this limiations.

If you need to burn more than one Motorola/Freescale hex file to make a complete program image, please read about EatS9.

Using the Phase Locked Loop (PLL)

Many members of the HC12 and HCS12 families contain phase locked loops that permit the processor to run at speeds faster or slower than the oscillator or crystal.

When the PLL is enabled, BDM communications may continue at the original, crystal-determined rate, or it may change to follow the processor speed. In most cases, it is preferable to have the BDM speed remain unchanged. That way, regardless of what you do to the processor speed via the PLL, debugging via BDM is unaffected. This is the normal default for HC12 and HCS12 chips.

Unfortunately, some types of HCS12 (including the A, Dx, and H) contain a bug, described in Motorola/Freescale errata, that causes BDM to stop working when the PLL is enabled and BDM is operating in the default mode. For such chips, it is necessary to set the CLKSW bit in the BDM status register at startup. Then, when the PLL is enabled and the processor speed changes, NoICE must change the BDM speed to match.

NoICE sets CLKSW if the NoICE12_targets.ini file contains the line

for the target in question. NoICE12_targets.ini specifies this for the affected chips.

In operation, edit NoICE's target communications dialog for the initial bus frequency, which is the crystal frequency divided by two.

When your startup code enables the PLL (or even if you enable it via manual edit from NoICE), NoICE will notice an error in reading the BDM status register, and pop up a dialog asking you to enter or select a new bus frequency. If the rate you enter doesn't result in a correct read of BDM status, the dialog will continue to pop up until you either specify the correct rate, or abort.

This feature is limited to the BDM speeds supported by particular BDM pods:

P&E MULTILINK USB and parallel at any speed supported by the pod
P&E CABLE12 does not support this feature
Elektronikladen ComPOD12/NG at any target frequency in the range 0.25 to 40 MHz
Elektronikladen ComPOD / Pro, limited to 1,2,4,8 MHz
Elektronikladen ComPOD non-Pro version does not support this feature
USBDM at any speed supported by the pod. The USBDM DLL may automatically deal with the frequency change without showing the dialogg.
Kevin Ross pod, limited to 1,2,4,8 MHz
D-Bug12 at any speed supported by the pod
TBDML at any target frequency in the range 0.9 to 16.5 MHz
Axiom AX-BDM12 does not support this feature

CAUTION: BDM uses a very simple protocol, and there is no foolproof way to tell what speed a processor is running at. NoICE polls the BDM status register, and looks for a certain bit pattern. Divergence from the expected pattern is taken to mean that the speed has changed. There is, of course, no guarantee that your target running at speed X will not interpret NoICE's read request at speed Y to be a write request or some other nasty thing. In practice, this seems not to occur. However, we recommend that you not use this feature if your target is connected to hardware that might be damaged or cause harm if written to an unexpected value. (Actually, we recommend that you not do any form of debugging on such a system without appropriate safety measures.)

Moving the Register Block, RAM, etc.

Motorola/Freescale allows you to move or disable RAM, I/O, Flash and just about everything else on the 68HC12. However, if you move the I/O devices, NoICE will be unable to use PPAGE or hardware breakpoints unless you customize your setup.

The Target Type specifies information about chip options, including PPAGE, hardware breakpoints, and RAM and Flash locations. This information is kept in a file called NoICE12_targets.ini in the NoICEconfig directory. For the MC9S12DP256, for example, there is text:

USBDM: USBDM Debugger Interface For Freescale RS08,HCS08 ...

As an example, suppose that we want to move the I/O registers from the default location of 0x0000 to 0x3000, and move the RAM from the default location of 0x1000 to 0x0000. We proceed as follows:

Add a copy of the above lines (please leave the original unchanged) to NoICE12_targets.ini and modify them to (changes in bold):
This tells NoICE that PPAGE at 3030, the breakpoint module at 3028, and PartID at 301A, rather than at the standard addresses.
Do not change the ramstart value, even if you actually plan to move the RAM! Unlike BRK24 and PPAGE, ramstart is used only during Flash burning, and it must reflect the RAM location immediately after hardware reset or burning will fail.
Create a file, perhaps called MyDP256.noi, that contains the lines
In the Target Communications Dialog, specify MyDP256.noi as the Play After Reset file.
Edit your startup code so that the first write the processor does sets the locations of the I/O, RAM, etc.
When your program runs without NoICE, these instructions will set the address or the I/O registers.
These instructions are not strictly necessary during debugging - in that case, NoICE's Play After Reset file will have already moved the I/O registers before the instruction executes. However, there is no harm in writing to address $0011 after INITRG has been moved - the write will not affect INITRG, but will go instead to the RAM that is now at address 0011. Thus, we recommend that you insert the instructions even during debugging, lest you forget to add them in your final program.

This is somewhat involved, but please take the time to understand clearly how this works:

When NoICE starts, it resets the chip and everything is at the default addresses shown in the datasheets.
NoICE then does the play-after-reset and RAM and I/O get moved.
(If you want, you can look at memory, run whatever is in Flash, etc. The difference from the non-debug case is that registers and RAM are moved. See step 7 below.)
You give a LOAD command. NoICE resets the chip (everything is default), loads the Flash burner according to ramstart and burns the Flash.
After burning, NoICE resets the chip and repeats the play-after reset, once again moving RAM and I/O.
You set a breakpoint. NoICE uses the BRK24 value, consistent with where the registers have been moved.
You start your program. It probably begins with code to move the I/O and RAM - but they have already been moved. Is this a problem? Well, if the code doesn't access any I/O before attempting to move the I/O you should be OK.

Performance

Theoretically, a parallel-port pod ought to be able to run faster than a serial-port pod. In practice, Windows adds overhead to parallel port access that may lessen the performance difference. And clever design can overlap some delays and result in good performance even on an old-fashioned serial link.

We ran simple time trials on a 2 GHz PC running Windows XP, loading, saving and burning 32K of target memory in a hex file. Target running at 8 MHz (16 MHz crystal). Your results may vary depending on PC, operating system, and changes made by the vendors to pod software.

Vendor	Interface	Load 32K (seconds)	Save 32K (seconds)	Burn 32K to DP256 (seconds)
Elektronikladen ComPOD12 NG	115,200 baud	4.2	3.9	14.8
P&E Multilink (parallel)	parallel	2.8	3.5	19.7
P&E CABLE12	parallel	3.7	4.1	not tested
P&E USB Multilink Rev B (current)	USB	4.2	3.5	21.6
P&E USB Multilink Rev A (old)	USB	5.5	5.2	50.8
Elektronikladen ComPOD12 PRO	115,200 baud	8.5	5.7	35.0
Kevin Ross BDM12	115,200 baud	10.9	7.5	27.3
TBDML	USB	10.3	12.3	43.1
Elektronikladen ComPOD12	38,400 baud	12.3	12.9	37.0
SofTec inDART-HCS12	USB	12.3	10.2	68.8
D-Bug12 (Technological Arts microBDM12SX)	57,600 baud	62.9	84.4	182.1
SofTec PK-HCS12	USB	66.8	65.4	265.6
Kevin Ross BDM12 via USB-serial converter	115,200 baud	not tested	71.1	not tested

The factor of ten slowdown on the Ross pod when used with a USB-serial converter is presumably because the Ross pod does an RTS/CTS toggle on every byte and the USB converter does a less than stellar job here. Your results with other brands of converter may vary. The other serial BDM pods show the same speed with the USB converter as with a 'real' serial port.

The relatively slow speed of the D-Bug12 is due to the ASCII hex protocol used, as compared to the binary protocol used by the other pods.

Terminal Interface Using BDM12 Virtual UART

NoICE with BDM12 allows an advanced feature called 'Virtual UART'. This allows the target to use the BDM port to communicate with the Output Window as with a dumb terminal.

Characters in the range 0 to 255 decimal are allowed, and will be displayed using the current Windows character set.

If keyboard focus is in the Output window and the user presses any key other than a function or cursor key while the target is executing, the ASCII/Windows representation of the key will be sent to the target via the serial port.

How it Works

The Virtual UART requires two consecutive dedicated RAM locations, one for output, and one for input. Both the target and NoICE/BDM read and write the memory locations to implement a communications channel.

To begin using the Virtual UART, the target must clear both memory locations to zero. Whenever the target is running, NoICE polls both bytes.

In order to send a byte to the Output Window, the target simply writes to the first, 'output', memory byte. When NoICE sees a non-zero value in the output byte, it displays that value in the Output Window, and then clears the output byte. The target must not write to the output byte unless it is zero, or characters will be lost.

When the user presses a key while the focus is in the Output Window, NoICE will write the key value to the second, 'input', memory byte. When the target sees a non-zero value in the input byte, it returns that value as if from a UART, and clears the input byte. NoICE will not write a keyhit to the input byte unless it is zero.

Defining the Virtual UART

To define the memory locations to be used, edit the BDM configuration file noice12_targets.ini in the NoICEconfig directory. For the MC9S12DP256, for example, there is text:

The memory locations to be used must not be used by your program for any other purpose. This may require you to change your linker file to avoid these bytes, or to define them in your program, as shown below.

The DP256 has RAM from 0x1000 to 0x3FFF. To define a Virtual UART at address 0x1000, we insert the line

into the ini file. It is a good idea to copy the section and give it a name that shows what you are doing. This can prevent confusion later, should you have another DP256 project on which you don't want to use the Virtual UART. In our example, we add

Using the Virtual UART Address

The target code required to use the Virtual UART is similar to any polled UART code. The major difference is that instead of testing a status bit in a status register, the target tests the zero/non-zero value of an entire byte.

Here is an example, done using ImageCraft ICC12 showing how to declare and initialize the Virtual UART

To connect the Virtual UART to printf, you must replace ImageCraft's putchar function with this:

CAUTION: if you run your program without NoICE, this version of putchar will hang after sending the first byte, since NoICE won't clear VUART_TX. The solution is usually to use a different version of putchar for release versus debug.

To use the Virtual UART for input, you must replace ImageCraft's getchar function with this:

Assembly code is similar:

Using STOP and WAIT Instructions

STOP and WAIT instructions have effects on processor operation that may result in loss of BDM communications. If you use these instructions, here are some tips. For complete information, refer to your target chip's datasheet.

The STOP instruction stops all system clocks in order to reduce power consumption. Since BDM relies on system clock, BDM will not operate when the processor is STOPped. After reset, the S-bit in the Condition Code Register (CCR) is set, disabling STOP mode. In this case, the STOP instruction will be executed as a NOP, no stop will occur, and BDM will continue to operate.

If your application wants to use STOP, it must clear the S-bit in the CCR. During debugging you may wish to omit the clearing of the S-bit so that BDM can be used.

The WAIT instruction stops some system clocks in order to reduce power consumption. Since BDM relies on system clock, BDM will not operate when the processor is in WAIT mode if the clock used by BDM is stopped. After reset, the SYSWAI bit in the CLKSEL register is set. This causes the system clock (and hence BDM) to continue running during WAIT mode.

If your application wants to stop system clocks during WAIT, it must clear the SYSWAI-bit in the CLKSEL register. During debugging you may wish to omit the clearing of the SYSWAI-bit so that BDM can be used.

Tips and Problems

The power and connection sequencing described above under Installing and Connecting BDM is critical. Failure to follow the manufacturer's instructions for connecting and disconnecting may result in damage to the BDM pod or to your target.
Proper entry into Special operating modes requires that the BDM pod be able to sequence the RESET and BKGD signals. If your target board has a capacitor on its RESET line, the pod may not be able to properly set the mode. Motorola/Freescale recommends that a reset chip such as the MC34064 be used rather than the traditional RC reset network. In some cases, you may need to remove the capacitor in order for BDM to operate properly. In particular, the Axiom boards may exhibit this problem.
The Ross pod is a sweet little thing, but it is a reset wimp. It doesn't pull very hard, and it doesn't pull very long. If you use it on a target with an other-than-recommended reset circuit (see the previous tip), you may have trouble. There isn't much that you can do, except to modify your target or change pods.
If you are using one of the parallel pods, you may need to set your parallel port to 'SPP' or 'Standard mode'. EPP or ECP may prevent proper function. You would have to ask the pod vendor why. We only know that they recommend standard mode, and we had to set our port that way to get it to work.
Don't try to put a parallel BDM pod at the end of a pass-through chain. Put your Zip drive, your scanner, your frambolator and your printer on one port. Put your BDM on another.
We haven't tried putting a BDM pod on the parallel port of the USB hub, but we would be very surprised if it worked.
If you are going to violate the above three rules, at least try it as recommended first. Once it works reliably (i.e., for more than two minutes) that way, then you can play with other settings. But don't ask us or the pod vendor for support when it doesn't work.
The serial BDM pods have all been verified to work with at least one brand of USB-to-serial converter (the driver is copyright by Prolific, but the converter itself is an anonymous Made In China). However, the Ross pod is ten times slower when used with the USB converter versus a 'real' serial port. This is presumably because the Ross pod does an RTS/CTS toggle on every byte and the USB converter does a less than stellar job here. Your results with other brands of converter may vary. The other serial BDM pods show the same speed with the USB converter as with a 'real' serial port.
If you can't access off-chip memory or things just look 'weird', be sure that you have initialized all necessary registers as described above.
The P&E CABLE12 pod will work with targets running at clock speeds between 500 kHz and 8 MHz. The P&E MULTILINK pod will work with targets running at clock speeds between 500 kHz and approximately 30 MHz.
Whenever you press 'OK' in the Target Communications dialog for a P&E pod, NoICE attempts to determine the speed of the target. This may take several seconds. Once the speed has been determined, it is stored in the registry for future use. Normally, this should be transparent to you. However, if you have problems communicating with your target, it may be worth opening the Target Communications dialog, verifying all the settings, and pressing 'OK' to get the pod to check communications speed.
The non-A version of the Axiom pod will work only with targets running at 8 MHz (16 MHz crystal). If your target runs at another speed, you must change the crystal in the pod.
The Ross pod will work only with targets running at 1, 2, 4, or 8 MHz, and you must configure NoICE appropriately. If your target runs at another speed, you must change the crystal in the pod. However, this may affect the baud rate as well.
The original Elektronikladen ComPOD will work only with targets running at 8 MHz (16 MHz crystal). If your target runs at another speed, you must change the crystal in the pod. However, this may affect the baud rate as well.
The ComPOD PRO will work with targets running at 1, 2, 4, or 8 MHz.
The ComPOD12/NG supports any target frequency in the range 0.25 to 40 MHz.
If you see lockups and crashes when you write to COPCTL, be aware that there is an apparent bug in the HC12 if you clear DISR and the CRx bits in the same write. When you start up in any Special mode, DISR is set, disabling the COP. If you wish to clear COPCTL to zero from a Special mode, you should do two writes:
The standard Play after Reset files do this as:
Be sure to select the exact chip that you are using. For example, the DG60 and DG60A use very different algorithms for programming Flash. Use of the incorrect algorithm may damage the chip. If you can't find an appropriate type, please contact us. 'Generic 68HC12' is safe in all cases, but will not allow you to burn Flash, use PPAGE, or use hardware breakpoints.
If your code writes to COPCTL on the MCS912, or to RTICTL on the older HC12, you may wish to set the RSBCK bit. When set, this bit stops the COP and the Real Time Interrupt (RTI) timer when the target is stopped in BDM mode, as at a breakpoint. If you enable the COP, this is the only way to avoid getting reset while in BDM mode.
Even if you don't use the COP, you may want to add code to set this bit if you use the Real Time Interrupt. Otherwise, the RTI will almost certainly time out while the target is stopped in BDM mode, meaning that the first instruction after GO will usually be the RTI interrupt handler. This may or may not cause problems for you, but the number of non-interrupt instructions executed between RTI interrupts will certainly differ from the free-running case.

Using NoICE - Contact us - NoICE Home