However, no responsibility is assumed for inaccuracies. Furthermore, Motorola reserves the right to make changes to the product herein to improve reliability, function, or design. Motorola does not assume any liability arising out of the application or use of any product or circuit described herein; neither does it convey any license under its patent rights or the rights of others. Motorola products are not authorised for use as components in life support devices or systems intended for surgical implant into the body or intended to support or sustain life.
Buyer agrees to notify Motorola of such intended end use whereupon Motorola shall determine the availability
and suitability of its products for the use intended.
Copyright (c) Motorola Ltd 1990
The package allows users to program the 68HC11 of interest and also to examine the behaviour of internal peripherals under specific conditions. In addition user programs may be run on the part with breakpoint and trace processing available.
This manual provides information on installing and running the program and on common problems encountered. The
user is advised to review any attached version information note before proceeding with the code.
Terminology:
M68HC11, HC11 Any member of the 68HC11 family of processors
A8, E9, D3 etc. A particular family member - normally preceded by MC68HC(7)11..
The following are trademarks:
MS-DOS is a registered trademark of Microsoft Corporation
IBM is a registered trademark of International Business Machines Corporation
Motorola and (batwing) are registered trademarks
2. Setting up your 68HC11 for use with PCbug11
There are two steps in preparing your 68HC11 for use with PCbug11. Firstly the hardware support components must
be prepared and secondly the software must be run on your IBM or compatible PC. Appendix A deals with the
hardware construction and lists the components required.
The software may be installed on to a hard disk as follows:
PCBUG11 -XA
This will start up a 68HC11A8/1/0 with the XIRQ pin connected to the PD0 pin.
It is also possible to use other 68HC11 family members. To use other family members the two characters after the -X in the command line is altered. This character is associated with the type of bootloader used on the chip. Most HC11s use the E9 type bootloader so that the -XE option will suit most family members. The following table highlights the current possibilities :
Device PCbug11 startup command
68HC11A8)
68HC11A1 ) PCBUG11 -XA
68HC11A0)
68HC11E9)
68HC11E1 ) PCBUG11 -XE
68HC11E0)
68HC811A2 PCBUG11 -XE
68HC811A8 PCBUG11 -88
68HC(7)11D3 PCBUG11 -D
68HC711E9 PCBUG11 -E
68HC11F1 PCBUG11 -XE
68HC(7)11K4 PCBUG11 -K
Type the command shown above which corresponds to the device which you have installed on your hardware. Note
that if the X option is indicated then the XIRQ pin should be connected to the PD0/Rx pin.
3.2 The PCbug11 monitor screen
The status of the hardware is displayed on the screen of the PC. There are four major areas or "windows" which make
up this screen.
In addition to the above windows a temporary window is used to indicate any errors and whether the communications to the HC11 are operating normally. This is displayed on top of the main window contents and on a colour screen is shown as red characters on a black background. This error window is cleared by hitting any key or after a timeout of around 5 seconds.
If the screen as described above does not appear then the program has not run properly. A DOS or a PCbug11 error
message (in the error window) will describe what the problem is. Please correct this error before proceeding. The
following section gives some help if errors occur.
3.3 Fixing simple problems and trying simple commands
If the software did not start up properly then errors will be displayed on the command screen and the register window
will show a series of XX's where the register values should be. A detailed description of the meaning of these errors
is contained in Appendix B, however, it is likely that for an initial start up that the errors are due to either the
communications link or some incorrect setting on the hardware. Check the following:
Try all the above then retry starting the system. If the system continues to fail then it is best to check the hardware constructed and the HC11 itself before calling for help.
If you had no error messages and the register display contains digits then the package is working correctly. The full command set for PCbug11 is contained in section 2.6, but we shall look at some simple commands to demonstrate the operation of the package.
This has the effect of causing the communications program to be reloaded and allows you to start afresh. Note : this command will only work if you reset the HC11 before typing the command. This command may cause any program in RAM on the processor to be lost.
A message in the main window will ask you to confirm this before the program is terminated on the PC.
If the command is successful the register contents will be displayed. If not then an error message will be shown and the register window will contain X's.
MD start_address (end_address)
command. The two values start_address and end_address indicate the block of memory to be displayed. If end_address is not entered then the 16 locations from start_address will be shown. Note that all hexadecimal numbers within PCbug11 are indicated by a leading $.If the contents are correctly read then they will displayed on the main window. If not then an error message will be displayed.
Help on a particular command may be available. To see this type
HELP command
where command is the command of interest.
The operation of more complex commands is shown in section 6.2
4. How PCbug11 works
To fully appreciate both the power and the limitations of the PCbug11, it is important to understand how the system
works. This section describes the basic operation of the package. It is strongly advised that the reader examines this
section before going on to more complex commands.
Most microcomputer emulators/trainers work in a similar manner. The microcomputer chip will run a program in ROM which communicates with a terminal allowing the user to execute program and alter registers etc. This monitor program is generally sophisticated and requires a complex hardware platform, although no other computer equipment (except a terminal) need be attached except when higher level functions such as high level debug etc. are used.
With this package the approach is quite different. In this case the microcomputer runs only a very simple program.
All the sophistication is at the PC which has a serial connection to the board. The communication between the PC and the HC11 allows similar functions to that of the emulator to be carried out with a very much simpler hardware board.
In effect the hardware complexity of the emulator has been replaced with software complexity on the PC. PCbug11 communicates with the 68HC11 through a low level communication program called the talker. A number of different talkers are supplied to support different HC11's and operating modes. All of these talkers are designed to communicate through the HC11's SCI port to the PC's serial port.
Each talker occupies less than 256 bytes of 68HC11 memory space and operates under interrupt. However, the operation of the talkers can be divided into two main groups: those talkers which use internal HC11 RAM memory and those talkers which use internal EEPROM or other ROM.
In the first case the PC must download the talker into the the HC11's RAM each time the hardware is used. In the latter the PC simply synchronises communication with the talker program which is already running on the HC11.
Both approaches have advantages and disadvantages and are discussed below. The RAM approach is termed the boot method and the alternative is called the ROMed method.
In the boot method, a talker is downloaded into the 68HC11's internal RAM during the start up of PCbug11. This download is achieved by using a special mode of the HC11 called bootstrap mode. In this mode it is possible to have the HC11 automatically download a program into its internal RAM and then run that program. This makes it possible to alter internal values, program memory, read and write to chip ports and other functions. This approach is very simple and requires no external hardware around an HC11 except a power supply, an oscillator and an interface to the RS232. It is limited in that it does use around 240 bytes of the internal RAM (less for the D3 part). This may be a problem for some users.
In ROMed mode, the appropriate Talker must be preprogrammed into either internal or external 68HC11 memory space, before PCbug11 is run on the PC. In the simplest case the talker is placed in an external memory and is run whenever the HC11 is powered up. A compromise is possible if a talker is loaded into the HC11's internal EEPROM.
Since the Talker is interrupt driven, and resides in the same memory map as user software, certain vectors must be reserved for the Talker code. These are the RESET, XIRQ, and SWI vectors. However, the SCI vector may be used in preference to the XIRQ vector, to give maskable control to PCbug11. Given the operating approach of PCbug11 described above some rules of thumb become apparent.
PCBUG11 [?|[-X][talker][macro=macroname params][baud=baudrate][port=1|2]
(talker) = (boottype)|(ROMtype)
(boottype) = A|D|E|K|88|
(ROMtype) = user defined file for ROMed talker
(baudrate) = a number which is a possible baud rate for the PC and
for the HC11
(macroname)= A valid name for a macro file which is stored in the
current directory
KEY:
(talker_type) indicates which talker is to be used. If this field is
preceded by the - character then the file
TALK(boottype).BOO/.XOO must be in the same directory as
PCbug11.exe.
(ROMtype) indicates that a ROMed talker is in use and the user must
supply a file called .MAP in the current directory.
(baud) is only applicable when a crystal other than 8MHz is being used.
At this frequency the communications rate which the PC uses is 9600
baud and the rate at which the - talker is downloaded is 7812.
Users using alternative crystals must inform PCbug11 what ratio this
is to 8MHz by using the option. For the option,
(baudrate) is the baud rate that will be used by the PC and the HC11 for
communications, it must be a value which represents the same ratio
to 9600 as the crystal in use represents to 8MHz That is,
= crystal_used MHz * 9600 (for ) ------------8
If the option is in use then must be
the value which represents the same ratio to 7812 as the crystal
in use represents to 8MHz. That is
= crystal_used MHz * 7812 (for ) -----------8
(macroname) is the name of a macro library file i.e. .MCR which
is automatically loaded at startup. This is useful because if a
macro called AUTOSTART exists in this library then it will
executed automatically after startup. Parameters may be passed
to this macro by enclosing them in round brackets () immediately
after the macro= option.
port=2 indicates that the PC port to be used for communications with the
hardware is port 2 and not port 1 which is the default port.
Examples of use of runtime command:
5.2 Uses of the Software
The list of possibilities for the software is unlimited. This is not a clever software simulation of a 68HC11, the
commands and programs you enter will run on the real hardware, albeit via a software interface. Since most of the
time the hardware will be running the HC11 in special bootstrap mode access to secured resources is at the user's
discretion and not under HC11 control. (This applies once the HC11 is started, in starting the part any installed
program may be erased)
Since the package runs under interrupt. It is possible to have a program running and still be able to read registers etc. It is also possible to write to registers and even to memory. With care it is even possible to modify the program that is being run at that time. The user should note that while the program or registers are being modified the program in use actually waits while the interrupt caused by PCbug11 is processed.
Breakpoints can be set in the software to cause the 68HC11 to stop whenever a point in the code is reached. The trace command also allows the user to step through code to see how instructions are executed and what result they have on the registers and CCR.
PCbug11 allows the user to modify and assemble into EEPROM as if it were RAM. Although the 68HC11 has quite
an elaborate routine required to program this memory, PCbug11 handles the algorithm so that programming can be
carried out transparently. The area of internal EEPROM must be predefined using the EEPROM command before
PCbug11 can program it correctly. Note that external EEPROM should not be specified in this way since the talker
will automatically handle slow external memories. The user will notice a difference in response time between writing
to EEPROM and RAM.
5.3 Pitfalls to avoid
Just as a feature of PCbug11 is being able to program EEPROM transparently, there is also a side issue. On some
HC11 there is a register which adds even more protection to the EEPROM memory. This is called the BPROT
register and generally resides at address $1035. This must be modified before the EEPROM or CONFIG register can
be programmed. PCbug11 DOES NOT modify this register.
If programming the CONFIG register it should be remembered that the contents of this register are generally not readable until the HC11 has been reset. Note also that if the part is reset in bootstrap mode certain automatic functions are carried out to place the part in a sensible operating mode. So the user will find that the NOCOP bit will always read 1 in bootstrap mode even if it has been programmed otherwise. If it is a security mode part then clearing the NOSEC bit will protect the internal RAM, EEPROM and CONFIG register. This means that if the part is reset in bootstrap mode then the CONFIG register will read $0F. If it didn't then the security mode would not be operating!
The use of interrupts is possible with the hardware, but certain practices must always be followed. For interrupts such as the real time interrupt etc., the interrupt is allowed by the I bit being clear and the appropriate interrupt mask being set (e.g. RTII bit for the real time interrupt). Note that while the interrupt flag I is set by an interrupt and cleared by a CLI (or RTI) instruction, the flag for the interrupt source itself remains set (for the real time interrupt this is RTIF).
So an exit from a real time interrupt service routine which leaves RTIF set will cause an interrupt to occur again immediately and communications with PCbug11 could cease (due to stack overflow) or cease to make sense. This has often been seen as a bug with PCbug11, but a casual analysis shows the user at fault. The user must clear the local interrupt flag (e.g. RTIF for the real time interrupt).
When real time measurements and calculations are in progress, it is necessary to remember that by reading registers or memory, the user is causing interrupts which interfere with the logical operation of the program. This could cause the result of the code to be upset in such a way that the answer is wrong. This is particularly the case when the processor is waiting for the logical value on a port pin to change before carrying out some action. If the change occurs while the user is using PCbug11 to enquire about the processor status then the change could be lost or upset.
Remember that the 68HC11 itself does its own self examination, it does not rely on external hardware for this function. Programs which perform off-line functions such as calculations will not, of course, be affected by this action.
Breakpoints and traces are implemented by the package via software interrupts (SWI). This means that when a breakpoint is hit an interrupt is generated which is handled by the internal talker. If the SWI is the used by the user directly then the SWI vector is called. If it is a true breakpoint then the PC performs various actions to inform the user. This system which is used by many emulators is very effective, but unfortunately is limited to use with RAM or EEPROM. ROM cannot have breakpoints set in it nor can it be traced through. Another problem exists when resetting the device while all breakpoints are still set. When the user resets or restarts the SWIs will remain in memory (especially EEPROM). These will be displayed as SWIs where normally another opcode would be displayed. The moral is either clear all breakpoints before resetting or restarting the device or load your code in again before using it after a reset/restart.
Finally, a point about macros. These are implemented such that their execution by PCbug11 can be very quick. A practice which may therefore cause problems is to place a G command in a macro followed by certain other commands which modify memory associated with the program. Since there is no way of knowing where the program is in its execution, a macro may modify memory before or during the program's own memory operation (remember that PCbug11 commands operate under interrupts, in which case the program is temporarily halted). Since memory operations normally involve loading/calculating a value and then storing it in memory, it is possible that the load/calculation could be performed and then an interrupt could occur during which PCbug11 could set the value of that location. On ending the interrupt the program would then store into the memory location. This could cause apparently erroneous operation and error messages. Therefore, it is not advisable to have a G instruction in a macro followed by instructions which modify memory.
Note that different boot talkers initialise the stack to different values according to the availability of RAM. Therefore the user take care when moving from one processor to another where the stack pointer varies. The default values are:
A - $EB; D - $EB; E - $1FF; K - $1FF; 88 - $EB
Remarques à Jacques.Weiss@supelec.fr