6811/6812 Embedded Development Boards
Intro
I've had a number of questions since my Embedded Tools
were released about a year ago. The same questions are
asked again and again, so I wrote this document to help
answer some of these questions.
This is NOT intended to replace the documentation that
came with your board. I can't cover all of the details
about every board in use. This is only designed to give
you some general info that will make it easier to
understand the documentation that came with your board.
This document is written for "development" boards. These
are the full-featured boards that are often used for
developing and debugging programs. Once a program has
been debugged and throughly tested, companies will
often "burn" the program into flash memory on a smaller
board intended for mass production.
Conventions in this Document
Anywhere you see the term "6811", I'm referring to the
family of chips in the 68hc11 line.
Anywhere you see the term "6812", I'm referring to the
family of chips in the 68hc12 line, including the newer
hcs12/9s12 line.
Sometimes I refer to specific chips so I can explain
the particular features of those chips, but I want to
keep this general in nature.
Internal Monitors
Development boards come with an internal monitor that
helps you download programs, inspect memory, set
breakpoints, etc. On the 6811 boards, the most common
monitor is BUFFALO. On the 6812 boards, the most common
monitor is D-Bug12. These 2 monitors are very similar,
but D-Bug12 is more complex because it supports many
of the enhancements in the 6812 family, such as
background debugging (BDM).
Board Modes
The hardest things to understand about embedded boards
are the various modes that can be used. The modes
determine how the board will boot up, and where it
will look for your program, and whether or not it
will go into an interactive debugging mode that lets
you download programs, examine memory, set breakpoints,
etc.
The selection of the mode is done with small DIP switches
on the board. Consult the documentation that came with
your board to determine which modes it has, and what
switch settings are needed for each mode.
These are just some of the more common modes. Your
board may not have all these modes, or it might have
more modes than these.
Monitor/EVB Mode
The mode we normally use for program development is
"monitor" mode (sometimes called "EVB" mode - it was
named after the Motorola EVB development board). The
monitor is controlling the boot-up, and it interacts
with the host computer over a serial port. In this
mode you have to reserve all of the designated memory
areas for use by the monitor itself. Your program
can be downloaded into RAM and run from RAM. You can
also program EEPROM in this mode if your board has it,
but you normally can't program flash in this mode.
This is a great way to test programs because you can
easily trace program execution and set breakpoints.
See "Flash Memory and COM Port concerns".
AUTOSTART Mode
"Autostart" mode is where the monitor is still in
control, but it looks for your program in Flash memory
after it boots up, and it automatically starts your
program ("AUTOSTART's"). The monitor is still available
while your program runs, and you can call some of it's
routines from your code. The use of this mode is
difficult because you have to write your program to
the flash memory BEFORE you use this mode. See "Flash
Memory and COM Port concerns".
Bootstrap Mode - 6812 only
The "Bootstrap" mode is used to write your program to
the flash memory without the use of a BDM. You have 2
custom programs burned into the flash when you get a new
DP256: one is the bootloader, which allows the rest of
flash memory to be programmed, and the other special
program is the d-bug12 monitor. (earlier versions of
d-bug12 didn't refer to the bootloader as a separate
module). You are allowed to overwrite the monitor when you
write your program to flash memory in bootstrap mode, but
the bootloader itself is in protected memory that can only
be overwritten using a BDM. In fact, it is common proactice
to overwrite at least part of the monitor because you have
to program your own interrupt vectors. At runtime, the
monitor will not be active at all, and it won't handle any
interrupts - you have to do it all.
After you program the flash in this mode, and you reboot in
monitor (EVB) mode, your program will be run automatically
from Flash instead of the monitor, and you have complete
control over all of the chip's functions. This emulates the
way your program will work in a final design intended for
mass production. But final deployment won't be done with a
full-featured development board. This can be considered a
final test of a program before it gets migrated to a custom
hardware board.
You can also use this mode to upgrade the version of your
d-bug12 monitor. This might be desireable if you want some
of the features that are only available in newer versions of
monitor. You can get new .s19 files containing monitor
upgrades from Motorola, or the company that made your board.
If you get it directly from Motorola, you might want to ask
your board's maker if that version is compatible with your
board before you load it into flash.
You must be careful with this mode, because you will
overwrite the monitor. if you want to go back to using the
monitor again, you'll have to reprogram the monitor using an
.s19 file. Make sure you have one of these .s19 files
containing your version of the monitor before you overwrite
it in bootstrap mode.
Jump to EEPROM - 6812 only
The "jump to EEPROM" mode is useful for cases where you
have a reasonable amount of EEPROM and you want to
locate your program there so it won't be lost when the
power is removed. When the board boots up in this mode,
it will jump to EEPROM, where it will automatically run
your program.
Pod Mode
The "pod" mode is used on 6812 family devices to work
with the Background Debug Mode (BDM). In this mode
your board acts as a master to program another board,
who is the slave. This lets you program the flash
memory of the slave board.
Flash Memory and COM Port concerns
In both the Monitor mode and Autostart modes you are using
the monitor during boot-up, and it has the interrupt
vectors in it's flash memory area near $FFFF. This means
that your user program can't use those vectors directly.
Instead, you normally put your vectors somewhere else in
RAM memory, and the monitor jumps to your vectors from it's
own interrupt handlers once it determines that you want to
handle the interrupt. You will normally need to set values
in this RAM interrupt vector table just after your program
starts running.
One additional consideration here is whether you have
control of the serial ports, or if the monitor does.
Sometimes the monitor will only use one of the serial ports
in this mode if you have 2 ports. If you only have 1 port,
you can normally use it in your program by calling monitor
routines to read and write bytes. However, if the port is
unmanaged (meaning that the monitor is not in charge of it),
then you have to control the port directly.
Memory Segments
C compilers need a way to determine what should be
loaded in each area of memory. This is done by configuring
"Memory segments". The C source code files can specify
which segment should be used for the object code that
results from each source code file.
"IOPORTS" This is where the processor maps it's special
I/O control registers. They normally get mapped
to location $0000 on 6812 systems.
"eeprom" Some processors have internal eeprom, and some
have external eeprom (of course, some have no
eeprom). This type of memory retains values after
power is lost. It has restrictions on how many
times it can be written to, and it is much slower
to be written to, than to be read from. You may
have to validate this memory after you store
values in it because some eeprom can be unreliable.
Several attempts to write (perhaps with time
delays) may be needed. This is less of a
problem in modern chips.
You can sometimes store program code in eeprom,
and this code can be executed following a boot
("jump to eeprom" mode).
"data" The is normal RAM memory to hold variables and
arrays. Your stack also goes in RAM, and it
normally lives at the high end of the "data"
area, and it grows downward. Your variables
and arrays start at the low end of RAM and
move up from there. You may need to reserve
some RAM locations for use by your monitor,
depending on the mode.
"text" This is "program" memory. This is where your
program code will go, and also initialized
variables or tables go here. This is often
in flash memory, but you can map this to RAM
to make it easier to debug programs during
development. The monitor is also stored in
flash, and it's normally protected so you
can't overwrite it by mistake. However, with
a BDM device you can overwrite all of the
flash areas (assuming it hasn't been protected
by blowing out internal fuses).
"vectors" This is where the processors special vectors
are to be stored. These specify what code should
be executed when special conditions occur, like
reset, Timer interrupt, etc.
The vectors are remapped to RAM locations in monitor mode.
Your program can set the vectors in a reserved area of RAM.
Memory Architecture
The 6812 family members (which often have large internal
flash memory of more than 32K) use a paged architecture to
select which memory segments are visible within the 64K
addressing range of the address registers and program
counter. The segments of memory are often specified with a
granularity that depends on the particular chip. Even chips
with less than 64K of flash often allow you to relocate
the flash memory within the 64K address space, just as you
can relocate the RAM and I/O registers. However, you can't
locate it anywhere you want - there are some restrictions.
One segment of flash will normally stay "rooted" at the
area of high memory where the vectors are located (such as
the reset vector that tells the processor where to go to
begin program execution).
The method of relocating flash memory is to use the internal
PPAGE Control register. This is not an easy register to use
because it is bit-encoded (different bits have different
meanings), and because the specifics of its bits vary between
different chips in the 6812 family.
Here's an example of the MC9S12DP256 memory map in single
chip mode:
$0000-$03FF Registers
$0400-$0FFF EEPROM
$1000-$3FFF RAM
$4000-$7FFF 16K fixed Flash
$8000-$BFFF 16K page window
$C000-$FFFF 16K fixed Flash
The general idea for flash with the above chip: you have
2 fixed 16K memory blocks: the block at $C000-$FFFF is special
because it hold the vectors. The flash from $4000-$7fff holds
the main part of your program. This main code is responsible
for switching PPAGE as needed to select the desired 16K block
of memory to be mapped into the "window" from $8000-$BFFF.
Downloading Instructions or Data to the Chip
Most people who start using embedded microprocessors know that
the instructions for the processor to execute are a series of
bytes called "machine code". These machine code bytes are
produced by software tools on the PC.
An assembler program takes English commands in an "assembler
source file" and translates them into machine code, and stores
the machine code in an .s19 file. Some of the more advanced
assemblers, such as GNU "as", assemble individual files of
assembler instructions into "object code" files, which can be
linked together in a separate step to create an executable file.
A C compiler, such as GNU "gcc", compiles individual .c source
files into object files, which are then linked together to
create an executable file. At link time there are some special
code routines that are also linked into each program: one of
these special routines is a "Startup code" file (called CRT0)
that tells the processor what to do before it executes the
user's program. Some of the things a startup code file does
is to specify where the memory and registers are to be mapped
in the address space, setting the stack pointer, setting the
speed of the internal Phase-locked loop, and then calling the
user's program. Another special set of routines is the runtime
library, which provides the code for all the built-in library
functions in the C language. There is usually more than one
runtime library linked to each program: for example, you
might have an I/O library, a math library, a string library,
etc.
The executable file is sometimes not in the right format
expected by the 6812 processor family. In the case of the GNU
tools, the executable file is in the "elf" format, which is not
compatible with the tools used to program the chips. To solve
this problem, one of the steps in the make process with the GNU
tools is to run the "objcopy" program, which converts the elf
file into an .s19 file, which is suitable for programming a
chip.
The .s19 file is a text file that specifies the load address,
and a series of bytes given as ASCII hex. These .s19 files are
similar to the .hex files used to program other chip families,
but they aren't directly compatible with .hex files. The onboard
monitor in the chip is given commands from the PC connected to
the embedded board's serial port. One of these commands is the
"LOAD" command, which tells the monitor that you are going to
send it machine code bytes from an .s19 file on the PC.
S Records in an .s19 File
"S records" are the text records that hold machine-code bytes in
the form of hex bytes. These records are used to download programs
to an embedded board. The Motorola devices normally use the
"S record" format, but most other embedded chip families use the
Intel "Hex" format, instead. You can find utilities to convert
between these formats if you need them. Most Motorola developers
only use "S records", so they normally don't need to support the
"hex" format also.
The filename that ends with an extension of ".s19" contains a
bunch of "s-records" used to program a device. You don't have to
generate the S records yourself because most tools can create
these files for you, but you should be familiar with these basic
ideas because they help you understand why you need the SRecCVT
program.
The 3 original S record types are:
S0 - a header record
S1 - a program/data record, with 16 bit addresses
S9 - logical end-of-file record, with a 16 bit start address
These 3 record types are still widely used, and these are the
only record tpyes you need to program internal RAM and EEPROM,
because these are always mapped within the basic 64K address
space.
If you will be programming a large amount of flash that exceeds
the 64K address space, you need to use the newer record types
that were added to support larger address ranges:
S2 - a program/data record, with 24 bit addresses
S3 - a program/data record, with 32 bit addresses
S7 - logical end-of-file record, with a 32 bit start address
S8 - logical end-of-file record, with a 24 bit start address
The start-address normally isn't used because the interrupt
vectors (esp the reset vector) will determine where the MPU
will start executing instructions.
S2 or S3 replace the functionality of the original S1 records,
and S7 or S8 replace the original S9.
Note that S3 and S7 records are not commonly used with the 6812
families, and these types are optional: S0, S7, S8, S9.
Therefore, you can have an entire file containing only S1 or S2
records.
SRecCvt - Banked-to-linear
There are two type of "S records" that can be used to program
flash memory:
- the "linear" format is used by Motorola's D-bug12 FLOAD
command, and by most flash programmers. This is where 24 bit
addresses are specified using S0, S2, and S8 records, and the
monitor will break up the linear addresses into segments for
you. Many tools, such as gcc, produce files in this format.
- the "banked" format uses a modified S2 record where the
upper 8 bits of the 24 bit address are used to encode the
PPAGE number.
You can convert from the "banked format" to the "linear format"
using Motorola's free SRecCvt program.
Note: I don't think you can convert from the "linear" to the
"banked" format with SRecCVT? I think this is a 1-way conversion
tool. But, if the file is already in banked format, SRecCvt can
keep it in the banked format if you just want it to reformat the
records.
Which format do you need? This depends on how you will be
programming the flash memory - the "linear" format is the most
commonly used format. Check on the software you will be using
for details.
SRecCvt - Even "Word" Addresses
Flash programming is done by writing words (two bytes at a time)
to aligned "even" addresses. To form such aligned words, two
subsequent bytes have to be combined. Each row of an S record
must have an even number of bytes. If any of your S records has
an odd number of bytes, or if any byte is specified to begin
programming at an odd address, then your S record file has to be
reformatted so each record has an even number of bytes, and each
record starts on an even address. This function can also be done
with SRecCVT.
SRecCvt - blocks of memory in each record
Lastly, you often need your s-records to be blocked into a
certain size, like 64 bytes per record. This is needed when the
flash programming software prefers to program a group of bytes
at a time. This can also be done by SRecCvt.
Eric Engler
last updated: August 2, 2004