Q. What makes my first EEPROM location ($B600) go away now & then? A: You need a good reset circuit to hold the part in reset during power on and power off cycles. You should also take care to initialize all interrupt vectors, especially illegal opcode. Two example circuits are shown in the new data sheet but these are not necessarily the best for all applications because one draws significant current while the other has a limited temp range. If the application operates at E = 1Mhz or less, the reset threshold can be anywhere from about 3V to 4.5V. If E = 2Mhz and the application operates at high temp, the reset trip point should be 4V to 4.5V. The trip point needs to be above the level where the CPU can function normally (won't misinterpret instructions or data) and reset must not release until the charge pump is discharged enough so it cannot cause programming or erase cycles (Vdd = 2V is risky but 0.7V should be OK). On mask sets A38P & A49N, location $B600 seemed prone to this problem by coincidence because the most likely runaway scenario is as follows: When Vdd gets low enough for the CPU to misread information, an illegal opcode may be encountered fairly quickly. In many cases the illegal opcode vector doesn't point to a meaningful program (or the program isn't readable) so another illegal may be fetched leading to repeated stacking of the registers. All addresses are then quickly written in descending order. If the value written to the PPROG register has bits 0 and 1 set, a program or erase operation will be initiated and the most recently written address in EEPROM would be the lowest address ($B600). Though this is the most common runaway scenario it is not the only possibility and any EEPROM location including the CONFIG register is subject to corruption. On mask set B96D, the required sequence for program and erase was strickly enforced by logic to reduce (drastically) the probability of accidentally turning on the charge pump output during a runaway. Also, the CONFIG register was changed such that it can only be altered in 'Special' modes (test or bootstrap). Proper system design still requires an external low voltage inhibit (LVI) reset. It is unlikely that a LVI will be added on chip in the foreseeable future. In the new data sheet, an oscillator startup delay (big RC on reset) is no longer specifically required although a few applications may still want to include a delay if timing is important during the first several milliseconds of operation. Often the LVI reset provides this delay in conjunction with the power supply rise time. The 68HC11 itself can operate with a DC speed clock so the oscillator need not be running full before reset is released. Q. How can I get 'real' bus timing numbers that reflect what the 68hx11 really does? How can i get bus timing numbers for bus frequencies other than 1 and 2 Mhz? A: The new data sheet includes timing numbers that are derived from real characterization over temperature. Also for each timing number, there is a formula which relates the spec number to the clock picket which causes it. From these you can calculate the timing numbers for any bus frequency and you can distinguish bus frequency factors from circuit delays. Q. How does the bootstrap mode work? A: The new data sheet includes a good description including special features such as how to force a jump to the first EEPROM address after a reset. If this is still not enough, we can send out a source code listing of the bootstrap ROM upon specific request. On very new parts, the bootstrap program for parts which do not specify the security option will not include the code to check for security and erase EEPROM. This change should not cause any changes to part usage. Q. I developed and debugged my program with a M68HC11EVB, a M68HC11EVM, or other development system, then I put it into the EEPROM of a 68HC11 and tried to run it but it wouldn't work. What's wrong? A: There are a few possibilities here. First, be sure that you initialized the stack pointer in your program. Most debug software like BIFFALO and EVMBUG set the stack pointer to a default safe value so you may get all the way thruogh your development without realizing that you forgot to set it. Another possibility is related to using the bootstrap mode method to jump to $B600 upon reset. This is done by connecting the RxD and TxD pins of port D together and to a pullup resistor and setting the MCU in the boot- strap mode (MODE A and MODE B pins low during reset). The bootstrap program sets up the SCI and transmits a break character. If the receiver sees a break as the first character, the program jumps to $B600 instead of continuing with the download. By the time your program starts at $B600, some of the reset values of registers have changed by the bootstrap program. The important changes are that the SCI transmitter and receiver have been turned on and port D has been configured for wire-or operation (by settint DWON bit in SPCR register). The result is that port D may not operate as your program expects. Q. I have been using the BUFFALO method for jumping to EEPROM (tie PE0 low) and I have had no problems. Recently, I got a batch of parts that wouldn't work. What's wrong? A: For a long time, 'A0 and 'A1 parts had BUFFALO in the ROM although it was not guaranteed to be there. Due to the current demand for 'HC11, we now build almost no parts with BUFFALO in ROM. Today's parts usually have a custom pattern in ROM which does not support the PE0 method of jumping to EEPROM. You should change to the boot- strap method to jump to EEPROM. This method is guarenteed to work for all parts.