1. It may be because the micro is working but the RS232 interface chip is not.  This typically is caused by a weak battery supplying power.  Don't use a 9-volt battery during development--   it wears down too quickly, since the current draw is between 15 and 30 mA.  A typical 9V battery rating is usually about 90 mAH.
2. If you are attempting to use the DOS batchfile provided, or PCBUG11, you must reset the board in BOOT mode.  On Adapt11-family products, always leave the VPP/NRML switch in the NRML position, or you may zap your chip!  Note that we strongly urge you to use the Windows program MicroLoad for downloading (get it on our RESOURCES webpage).  Unlike the DOS batchfile, MicroLoad is an intelligent downloader--  the DOS batchfiles have no intelligence or feedback at all, and may lead you to erroneous conclusions.
3. To use the DOS downloading batchfiles with Adapt11-family or MicroCore-11 products, you MUST use the supplied serial cable.  If you make your own, you will have to jumper the appropriate handshaking lines.  Refer to the document Making Your Own Serial Cable for details.  That's one more reason to use MicroLoad for Windows (get it on our RESOURCES webpage).
4. If you are having communications problems, check your terminal program's com port settings to make sure the proper port, baud rate, etc. are selected.  See the Tutorial in your Starter Package manual for the correct settings. If you still have problems, try a different terminal program.
5. If you are using PCBUG11, and getting communications failures or other errors, make sure you read Using PCBUG11 with Adapt11 Products
6. If you are using a 9-pin to 25-pin adapter, try a different one--  some adapters don't pass all the signals through.
7. Make sure you leave the PD0 and PD1 pins on the I/O connector open (where applicable).  These signals are used by the RS232 interface.
8. You may have a faulty serial cable (test for continuity, or try a different one)
9. Your .s19 file may contain target addresses in invalid address range (eg. non-existent or unwritable memory; check the ORG directives (assembler), command line parameters (SBASIC), or linker options (C) )
10. Most of our 68HC11 products have a Write Protect switch to protect the external EEPROM from being corrupted or inadvertently overwritten.  The WRITE PROT switch may have been inadvertently left in the PROT position (switch to WRITE before downloading and back to PROT after downloading)
11. The COP watchdog and/or ROM may have inadvertently been enabled in the CONFIG register;  some versions of ImageCraft C have been known to do this from time to time (use PCBug11 to verify the value in the CONFIG register, and change it if necessary;  refer to the PCBug11 section in your Starter Package manual)  Here are correct CONFIG register values for the various products:
1. 68HC11E0 chip:  NOSEC should be 1, ROMON should be 0 (or 1 to enable BUFFALO monitor in ROM if it is present) and NOCOP should be 1;  CONFIG = $0C or $0E
2. 68HC11E1 chip:  NOSEC should be 1, ROMON should be 0 (or 1 to enable BUFFALO monitor in ROM if it is present), NOCOP should be 1, and EEON should be 1;  CONFIG = $0E or $0F
3. 68HC811E2 chip:  all bits should be 1;  CONFIG = $FF
12. The RS232 interface chip or the MCU may have been damaged by static electricity (you should work only at an ESD-safe work area, and avoid touching the board until you have grounded yourself);  if you conclude the chip has been damaged, you may return the board for repair, after contacting us for return authorization and instructions.

1. Check that you have the power hooked up correctly, and that you have adequate power
2. Make sure the switch is at RUN when you reset the board
3. Verify that you are using the correct demo program for your board, and that it is actually in memory, using PCBUG11 or HCLOAD.  If not, re-load it using one of the methods described in your Starter Package manual (use of MicroLoad is recommended, since it automatically verifies as it loads).  If you used MicroLoad for downloading and it reported successful downloading, no further verification is required.  Instead, check the other possibilities mentioned.
4. Make sure you have not shorted out PA6 on the board's I/O connector.  It is the output pin that drives the LED.

The red LED is attached to PortA, bit 6.  It simply lights up whenever there is a logic high on that pin.  If the red LED lights up or blinks, it means that the MCU must be writing to the PortA data register.  If your program doesn't write to PortA, then it would imply that your program is not running (something else is).  If the MCU doesn't know where your program is, it won't execute it.  The mechanism that the 68HC11 uses to define where your program starts is called the Reset Vector.  This is a pre-defined two-byte address location ($FFFE and $FFFF).  The MCU automatically dumps the 16-bit contents of these two addresses into its program counter following a reset event.  It's up to you to make sure the starting address of your program is in these memory locations.  In assembler, this is as simple as:

    ORG $FFFE
    FDB    START

where START is the label you put on the first line of code in your program (note that you could call it anything you like).  Refer to the simple examples in the Starter Package manual, and the demo program on the HC11 disk for more details.

1. The most likely cause is that the Reset Vector has not been defined  (see the reply to Q3, above, for more details).  The unprogrammed value of a memory location is usually $FF, so the Reset Vector contains $FFFF.  The MCU loads the program counter with this value ($FFFF) immediately following a reset event and dutifully executes the instruction it finds there ($FF).  So it fetches $FF as the opcode STX, and the next two bytes (contents of addresses $0000 and $0001) as the address where it's supposed to store the contents of X.  Since these are RAM locations, they could contain anything (possibly even $1000, which is the address of the PortA data register).  Now the Program Counter is pointing at $0002 and it fetches the contents of that location and interprets it as an opcode.  Since it is a RAM location, the contents are random, so it's anybody's guess what will happen next.  You get the idea!
2. The program in memory may not be properly designed.  The most common defect is lack of a RESET VECTOR, so the MCU doesn't know where your program starts.  If you are using ImageCraft C, make sure to include vectors.c in your program or project.  Correct your program and download it again.
3. The program in memory may have become corrupted (make sure the WRITE PROT is always in the PROT position when you apply power to your board).  The most common location to get altered is $FFFF, which is part of the reset vector (see Q3, above).  Note that corruption doesn't mean electrical damage--  it just means you have to load the program into memory again.
4. Users of Adapt11 + MX1 memory expansion card combination, make sure you know where your program is.  In other words, if the flavour of MCU on your Adapt11 board is 68HC11E0 or 'E1, there's no on-chip program memory (ie. in the reset vector area).  So the only program memory available in this configuration is in the MX1's program memory socket--  make sure you have a programmable device in the socket, and make sure you move the switch next to the MCU to the EXP position (ie. away from SGL) so that the MCU is running in expanded mode.
5. Another possibilty is that the watchdog timer is enabled.  This watchdog function is enabled by the COPON bit in the 68HC11 Config register.  Use PCBug11 or another suitable utility to examine and modify the value of the Config register, if necessary.

1. Although it is possible to load a program into external EEPROM in MicroStamp11, MicroCore-11, and Adapt11 products via PCBug11, it is not recommended (it's slow and the BOOT ROM of the 68HC11 might get in the way).  Instead, you should use MicroLoad (Windows utility).  If you're determined to do it, however, follow this checklist (see the PCBug11 section in the Starter Package manual for details):
1. after starting PCBug11, force the MCU into expanded mode via the HPRIO register
2. specify the memory range of EEPROM
3. disable "erase-before-write"
4. make sure your WRITE PROT switch is at WRITE
5. make sure the ROMON bit in the CONFIG register is clear (otherwise, on-chip ROM such as BUFFALO will be in the way of accesses to some or all of external memory
6. now you can use commands like MM, MS, BF or LOADS on EEPROM locations
7. don't forget the Bootstrap ROM is active in PCBug11, so you'll encounter errors if you try to write in the area from $BF00 - $BFFF