M68HC11
REFERENCE MANUAL
ON-CHIP MEMORY
MOTOROLA
4-15
gage the security option is that the NOSEC bit in the CONFIG register be programmed
to zero. Programming NOSEC to zero does not engage the security mode unless the
MCU was manufactured with the capability to recognize the security option. The rea-
son for a two-level enable is to prevent accidental activation of the security option in
applications that never intend to use it.
Bootloader firmware is used to disengage the security option. Bootloader firmware
checks the NOSEC bit in CONFIG to determine whether or not the security option is
on. If security is on, the entire EEPROM is erased, and the entire RAM is written with
$FF to overwrite anything that was in RAM before. The EEPROM and RAM are then
rechecked to make sure the erase operations were successful. If the operations were
not successful, they are repeated until successful. Once the EEPROM and RAM have
been verified as erased, the CONFIG register is erased to disengage the security op-
tion, and the downloading operation is started. It is not necessary to actually download
a program via the bootstrap mode to disengage security. All that is required is to come
out of reset in the bootstrap mode. The security option is disengaged regardless of
whether anything is downloaded.
The presence of the security option can be detected while the MCU is in reset by forc-
ing the mode A (MODA) and mode B (MODB) pins to one and monitoring the strobe
A/address strobe (STRA/AS) pin. When MODA and MODB are ones, the normal ex-
panded mode is requested. If security is engaged, the STRA/AS pin will act as a high-
impedance input because the security option causes the MODA pin to be interpreted
as a zero even if it is a one. In single-chip modes, the STRA/AS pin is configured for
the strobe A input function. If the security mode is not engaged, the STRA/AS pin will
be acting as the address strobe output, which can easily be recognized on an oscillo-
scope. This checking procedure allows the security mode to be detected without dis-
engaging it. If the MODB pin were low in this experiment, the bootstrap mode would
be requested rather than the normal single-chip mode. In the case of MODB low, care
is required not to release reset because doing so would cause the security option to
be disengaged.
When developing a security strategy, the user should remember ROM contents are
not protected. A software pirate can disengage the security option, read the contents
of the internal ROM, and disassemble the programs and subroutines in that ROM.
Some measures to protect an application program intentionally make the program
more difficult to understand. Programs that are difficult to understand are also difficult
to develop and maintain. Careful documentation of the function and intent of every
written program is essential.
A key can be stored in EEPROM. A user can then be required to supply a matching
key value before the program will operate. This approach is somewhat weak because
all of the operational programs are intact in the ROM; thus, a software pirate could find
and bypass the key-checking routine. However, if the key-checking routine is repeated
in more than one way and place, this approach can make unauthorized access diffi-
cult.
Another approach would be to program a vital subroutine entirely within the EEPROM.
This approach is better than the previous key-checking approach because the ROM