--------------------------------------------------------------------------------------
-  NOTE: Besure to read the section under "Release Notes" for new feature additions. -
--------------------------------------------------------------------------------------

Included in the D-Bug12 v4.x.x distribution are two variations of D-Bug12. The bootloader
and D-Bug12 S-Record files with a Ô-8Õ in the name are for systems using an 8.0 MHz crystal
or oscillator.  The bootloader and D-Bug12 S-Record files with a Ô-16Õ in the name are for
systems using a 16.0 MHz crystal or oscillator. Details on customizing the bootloader and
D-Bug12 for use in systems with other crystal or oscillator frequencies can be found in
Appendix B of the D-Bug12 Reference Guide.

Note that the supplied S-Record files are in the linear load address format (the format
used by D-Bug12's FLOAD command). If a tool requiring 'banked' S-Records (such as the
Codewarrior tool chain) is used to program the S-Record files into an EVB, both the D-Bug12
and Bootloader S-Record files can be converted to banked format using the included
SRecCvt.exe utility. The following command line can be used to convert the files:

sreccvt -m c0000 fffff 32 -ob -o <OutFileName.S19> <InFileName.S19>


With this distribution, a folder containing the 'include' files needed to assemble
BootDP256.Asm has been included. In addition, the BootDP256.Asm file was modified so that
it can be assembled with MCUez.

In prior versions of D-Bug12, the S-Records for the serial bootloader were included in
the DÐBug12 S-Record file. In version 4.x.x, the bootloader S-Records are contained in
a separate file included with the distribution. Both of these files must be programmed
into the target Flash for DÐBug12 to operate. Most M68HC12 Flash programming utilities
will allow programming of a target MCUÕs Flash even if it is not erased. However, if
programming target devices with two files is not permitted, the two files may be combined
into a single file. When combining the files, make sure that only a single S9 record is
present and at the end of the file. Most programming utilities terminate the programming
process when they detect an S9 (or S8) record.

D-Bug12 is configured to use port pins PAD00 and PAD01 for mode selection (EVB, POD,
bootload or Jump to EEPROM). The Barracuda (DP256) EVB was designed to use PAD00 and
PAD08. In order to run D-Bug12 on the Barracuda EVB, the EVB must be modified to use
PAD00 and PAD01. The easiest way to perform the modification is to place a 0.1 inch shunt
jumper between the PAD08 and PAD01 pins on the outer header as these two pins are
adjacent. The two pins are clearly marked. In addition, the board may be permanently
modified by cutting the trace leading to the center pin on the PAD08 three position
jumper on the top of the board and connecting PAD01 to the center pin.

Note that the Motorola DP256 EVB is shipped WITHOUT the XFC capacitors installed in
locations C13 and C14. These parts are REQUIRED for D-Bug12 operation since the PLL is
used to increase the bus frequency to 24 MHz. Operation without these components will,
at best, result in VERY unstable serial communications. Capacitor values of 0.033uF and
0.0033uF can be used for C13 and C14 respectively.

Please note that the LOAD, VERIFY and UPLOAD command line options have changed with version
3.0.0b10 of D-Bug12. In prior versions of D-Bug12, these commands used a ';d' command line 
option to allow loading, verifying or uploading code or data into memory areas outside the
Flash program memory address range for devices containing more than 64K of memory space. In
general this was confusing to most users that just wanted to load some code or data into
RAM or EEPROM (they would forget about the ;d option if they hadn't used the command for
a while).

With version 3.0.0b10 and later the LOAD, VERIFY and UPLOAD command will perform their
functions on the 64K address space without a command line option. To perform a LOAD, VERIFY
or UPLOAD operation on the expanded program memory space, a ';f' command line option must
be supplied on the command line.

Examples:

To verify the results of an FLOAD command for an M68HC12 device with more than 64K of memory
enter:

verf ;f

To load a program into on-chip RAM or EEPROM enter:

load

To upload the entire contents of the on-chip Flash memory of the MC68HC912DA128, generating
32 byte S-Records enter:

upload 0 1ffff 32 ;f


Release Notes


Version 4.0.0b26
----------------

Added option to the FBULK command to allow specification of the security byte value on the
command line. This option can only be used when an S12 is selected as the target device.

Added support for the S12NE64.

Added the FSERASE command. This command allows a range of Flash sectors to be erased.
See the D-Bug12 Reference Guide for additional details.

When option '1' of the "Can't Communicate..." menu is selected, D-Bug12 will attempt to
automatically detect the operating speed of a connected target device using the Sync
feature of the Enhanced BDM module. If the attempt is successful, communication will
be established with the target device resulting in the display of the S> or R> prompt.
If the connected target does not contain the Enhanced BDM module, a target operating
frequency may be entered manually.


Version 4.0.0b24
----------------

Added Support for the S12B128.


Version 4.0.0b23
----------------

Added Support for the S12KG128.


Version 4.0.0b22
----------------

Breakpoints were not working properly for the 9S12C32 because the C32 has a simple
'linear' ($8000 - $FFFF) address space in the device data table, but contains an
extended breakpoint module. I changed the device data table entries for the C32 &
UF32 to make them paged devices since they really have a paged architecture. Also
changed the GetXtndAddress() function to allow entering a simple 'linear' address
in the $8000 - $BFFF range if the selected target device has less than three 16K
pages. Also modified the FLOAD command so that a paged architecture device with
two 16K pages of Flash (32K devices) can accept S-Records in the $8000 - $FFFF.

Added Support for the S12C128.


Version 4.0.0b20
----------------

Modified support for the DP512 to add its own programming driver. This was required
because the memory blocks in the DP512 are 128K rather than 64K like the DP256. Didn't
have any DP512s to test with when the original support for it was released.

Modified the TargetInit() function to add a delay of 750 target clock cycles after
issuing the BDM AckEnable() command. This was required because the HC12 family
apparently does not completely ignore invalid/unrecognized commands. This problem
caused D-Bug12 to not be able to hot connect to any HC12(A) family device.


Version 4.0.0b19
----------------

The offset for MIN/MAX instructions were being disassembled incorrectly when using
PCR indexed addressing because an incorrect value of the program counter was being
passed to the DiIndexed() function.

Had to change the EraseUnSecStar12() function to include a timeout when waiting
for the EEPROM mass erase to complete. This was required for devices (such as the
C32 & E128) that do not have EEPROM. With the timeout not present, the function
would just hang after successfully erasing the the Flash.

Added support for the MC9S12UF32.


Version 4.0.0b18
----------------

Modified the EVB Bootloader & D-Bug12 so that it will run on 128K & 256K 'D' family
and 'A' family HCS12 devices. In addition, it will also run on the MC9S12H256.

Functionality was added that allows D-Bug12 to automatically detect and display the
correct address range of the on-chip RAM, EEPROM & Registers when an HCS12 device is
selected/connected as the target device.

When connecting to an HCS12 target device, D-Bug12 will automatically detect and
select the correct target MCU device based on the contents of the PARTID register.

Fixed a problem in the TargetReset() function that caused D-Bug12 not to be able to
connect to a target system if an HCS12 had been previously selected as a target device
and an attempt was then made to connect to an HC12 target device.

Added support for the MC9S12E128.

Added support for the MC9S12C32.

Added the VER command that displays the current version of D-Bug12. This allows high
level debuggers to determine what version of D-Bug12 is running so they know what
features they can count on.

A "Target CPU Is Being Held In Reset" error message is displayed on the command line
when the target's reset line is held low for longer than 250 mS. The target reset
condition must be removed before D-Bug12 can continue.

The DEVICE command was modified to allow full device names (i.e. MC9S12DP256) to be
used on the command line when selecting a target device. This keeps users from having
to consult the D-Bug12 Reference Manual to know which devices are supported by D-Bug12.
The 'DEVICE ?' form of the DEVICE command displays all of the device  names that may
be used to select a target device. See the DEVICE command for additional details.

Version 4.0.0b17
----------------

Added BDM debugger to D-Bug12. Allows sending single BDM hardware or firmware commands
to a target from the command line.
 
Modified the function EstablishTargetCom() to allow entering the BDM debugger even if
communication cannot initially be established with the target.

Updated the BDMDrvrs.s file to accommodate the BDM ACK protocol present on Torpedo
(Dx64) and other HCS12 devices. Also modified the ProbeInit() & TargetReset() functions
to issue the ACK_ENABLE BDM command. This will enable the BDM ACK protocol on devices
containing the enhanced BDM module & just be ignored by other devices.

Version 4.0.0b16
----------------

When the PP command was implemented, a check was not being made for D-Bug12 operating mode.
Consequently, the PP command could be used to change the PPAGE register when operating in
EVB mode. This sent D-Bug12 off into never-never land. Change was made to not allow the
PP command in EVB mode.

The programming driver for HCS12 devices was attempting to unlock the Flash via the
backdoor security key & was not necessary. This action caused a problem with a new
implementation of the backdoor security key enable mechanism that uses bits 7:6 in the
Flash security register in a 1:0 combination to enable the security key mechanism.
Because the default value of the security byte is $FE, the ACCERR bit gets set & programming
is prohibited. Removed the code that attempted to unlock the Flash.

Added support for the MC9S12DP512.


Version 4.0.0b15
----------------

Fixed a bug in the EraseUnSecStar12() function. Because of a cut & paste error, when erasing
the EEPROM, the code was checking the FSTAT register instead of the ESTAT register.

Moved the display of the sign-on message to occur before an attempt is made to establish
a connection with the target. This was done so that users could know what version of
D-Bug12 they are running without having a connection to a target when operating in POD mode.


Version 4.0.0b14
----------------

Added support for the MC9S12DJ/DG64.

To accommodate target designs that place large amounts of capacitance on the reset line,
a 10 mS delay was added between the time the reset pin is released and the background pin
is released in the function TargetReset(). This makes sure that the part is reset in
special single chip mode.

Fixed a bug in the BS command that caused a search in paged memory to fail if the search
was begun at an address near the end of a page. If the number of bytes between the start
address and the end of the page was less than the number of bytes in the search string,
the search would fail.


Version 4.0.0b12
----------------

The UDREEMM() function in UDREEMM.c and the SSTEEMM() function in SSTEEMM.c were returning
the error code NoTargetWrite instead of NoTargetEEWrite & EEEraseError if the EEPROM
couldn't be written or erased. This kept the ;nv option (no verify) of the Block Fill
command from working for the 0.65u & 0.5u parts. These two files were changed to  return
the proper error codes.

When programming the EEPROM in the 0.5u parts, the SSTEEMM() function uses the auto
timing feature. If an attempt is made to program or erase a protected block, the EEPGM
bit never clears. This resulted in D-Bug12 hanging waiting for the bit to auto clear.
Timer channel 0 is used as a watch dog timer to terminate the erase or write and
return an error if it doesn't complete in the specified time.


Version 4.0.0b11
----------------

The Changes made to GetCmdLine() to allow quoted strings to be entered on the command line
for the BS command (moved the conversion of the command line string to all upper case
caharcters to the ProcessCommandLine()  function) broke the ability of the single line
assembler to accept instruction mnemonics in lower case. Added code to convert the entered
assembly line to all upper case.


Version 4.0.0b10:
----------------

A Minor mask revision was made to Barracuda II, changing the MCUID register from $0010 to
$0011. To accommodate this change & any other minor mask set revisions to the DP256 pass
2 & H256 silicon, the code in ProbeInit() & TargetReset() that read the target MCUID
register for detection of the BDM bug now masks off the lower 4 bits (minor mask set revision)
of the MCUID.

Changed the Device command to only list the device names (instead of EE, Flash, I/O addresses,
etc) when the '?' is the only command line parameter.

Modified the LOAD, FLOAD & VERF commands to accept banked S-Records using a ';b' option.

Added a ';np' option to the FLOAD & FBULK commands. This command was mainly added for the
Star12 family. The option is used to force the target NOT to use the target PLL during the
erase or programming process. The D-Bug12 firmware & the erase & program drivers for the
UDR (0.65u and 0.5u) HC12 parts are written to automatically detect if the PLL is enabled
(the state of the Vddpll pin is reflected in the PLLON bit in the PLLCR register) and
utilize the maximum bus frequency of the selected device to reduce the erase & program
time. Because Star12 devices must have power applied to Vddpll even if the target
application does not use  the PLL (because Vddpll supplies power to the oscillator
circuitry), the Star12 drivers have no way to detect if they may use the PLL to reduce
the erase or program time.

Fixed a bug in the InsertBP() & RemoveBP() functions. If software breakpoints were being
used, the PPAGE register was not being restored to its original value when breakpoint
insertion or removal was complete.

Added the SO (Step Over) command that allows tracing a subroutine call as a single instruction.

Added the BS (Block Search) command. Allows a block of memory to be searched for a string
or hex data pattern.

Added support for the MC9S12DB128 (Marlin).

Added a ';t' option to the BAUD command. Using this option makes the baud rate change
temporary. i.e. the new baud rate is not stored in NVM memory. The next time D-Bug12
is powered up or reset, the baud rate will revert to the last value stored in NVM.

Added a ';nv' option to the Block Fill command (BF). This option prevents the BF command
from verifying writes to the specified memory range. This option can be useful for testing
a range of memory, especially RAM or EEPROM, for defective locations.

Added the ';nf' option to the FLOAD command to prevent an ASCII asterisk (*) from being
sent to the host for each S-Record received.


Known Issues
------------

MC9S12DP256 mask sets 0K36N, 0K79X and 1K79X all contain an errata related to properly
handling SCI interrupts. This errata results in an SCI interrupt not being generated if
a transmit and receive interrupt occur simultaneously. This errata can negatively affect
the execution of the FLOAD and LOAD commands, especially at high baud rates, by causing
a character in the data stream to be lost due to an SCI overrun error. Generally this
results in a 'Bad Hex Data' error being reported during the FLOAD or LOAD process. The
FLOAD command has a new command line option, ';NF', to help work around this errata. This
option prevents an ASCII asterisk (*) from being sent to the host for each S-Record
received. Because the LOAD command only sends an ASCII asterisk (*) to the host for each
10 S-Records received, it is much less likely for the errata to affect its execution.
