LM3S601 Datasheet, PDF (115/446 Pages) List of Unclassifed Manufacturers – Microcontroller

LM3S601 Microcontroller
Table 7-1. Flash Protection Policy Combinations
FMPPEn FMPREn Protection
0
0 Execute-only protection. The block may only be executed and may not be written or erased. This mode
is used to protect code.
1
0 The block may be written, erased or executed, but not read. This combination is unlikely to be used.
0
1 Read-only protection. The block may be read or executed but may not be written or erased. This mode
is used to lock the block from further modification while allowing any read or execute access.
1
1 No protection. The block may be written, erased, executed or read.
7.2.2.3
An access that attempts to program or erase a PE-protected block is prohibited. A controller interrupt
may be optionally generated (by setting the AMASK bit in the FIM register) to alert software developers
of poorly behaving software during the development and debug phases.
An access that attempts to read an RE-protected block is prohibited. Such accesses return data
filled with all 0s. A controller interrupt may be optionally generated to alert software developers of
poorly behaving software during the development and debug phases.
The factory settings for the FMPREn and FMPPEn registers are a value of 1 for all implemented
banks. This implements a policy of open access and programmability. The register bits may be
changed by writing the specific register bit. The changes are not permanent until the register is
committed (saved), at which point the bit change is permanent. If a bit is changed from a 1 to a 0
and not committed, it may be restored by executing a power-on reset sequence.
Flash Protection by Disabling Debug Access
Flash memory may also be protected by permanently disabling access to the Debug Access Port
(DAP) through the JTAG and SWD interfaces. This is accomplished by clearing the DBG field of
the FMPRE register.
Flash Memory Protection Read Enable (DBG field): If set to 0x2, access to the DAP is enabled
through the JTAG and SWD interfaces. If clear, access to the DAP is disabled. The DBG field
programming becomes permanent, and irreversible, after a commit sequence is performed.
In the initial state, provided from the factory, access is enabled in order to facilitate code development
and debug. Access to the DAP may be disabled at the end of the manufacturing flow, once all tests
have passed and software loaded. This change will not take effect until the next power-up of the
device. Note that it is recommended that disabling access to the DAP be combined with a mechanism
for providing end-user installable updates (if necessary) such as the Stellaris boot loader.
Important: Once the DBG field is cleared and committed, this field can never be restored to the
factory-programmed value—which means JTAG/SWD interface to the debug module
can never be re-enabled. This sequence does NOT disable the JTAG controller, it only
disables the access of the DAP through the JTAG or SWD interfaces. The JTAG interface
remains functional and access to the Test Access Port remains enabled, allowing the
user to execute the IEEE JTAG-defined instructions (for example, to perform boundary
scan operations).
If the user will also be using the FMPRE bits to protect flash memory from being read as data (to
mark sets of 2 KB blocks of flash memory as execute-only), these one-time-programmable bits
should be written at the same time that the debug disable bits are programmed. Mechanisms to
execute the one-time code sequence to disable all debug access include:
■ Selecting the debug disable option in the Stellaris boot loader
October 01, 2007
115
Preliminary