LM3S818 Datasheet, PDF (214/572 Pages) Bookham, Inc. – Microcontroller

Internal Memory
6.2.2.3
Table 6-1. Flash Protection Policy Combinations (continued)
FMPPEn
1
0
1
FMPREn
0
1
1
Protection
The block may be written, erased or executed, but not read. This combination is unlikely to
be used.
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.
No protection. The block may be written, erased, executed or read.
A Flash memory access that attempts to read a read-protected block (FMPREn bit is set) is prohibited
and generates a bus fault. A Flash memory access that attempts to program or erase a
program-protected block (FMPPEn bit is set) is prohibited and can optionally generate an interrupt
(by setting the AMASK bit in the Flash Controller Interrupt Mask (FCIM) register) 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. These settings create a policy of open access and programmability. The register bits may
be changed by clearing 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. The changes
are committed using the Flash Memory Control (FMC) register.
Execute-Only Protection
Execute-only protection prevents both modification and visibility to a protected flash block. This
mode is intended to be used in situations where a device requires debug capability, yet portions of
the application space must be protected from external access. An example of this is a company
who wishes to sell Stellaris devices with their proprietary software pre-programmed, yet allow the
end user to add custom code to an unprotected region of the flash (such as a motor control module
with a customizable motor configuration section in flash).
Literal data introduces a complication to the protection mechanism. When C code is compiled and
linked, literal data (constants, and so on) is typically placed in the text section, between functions,
by the compiler. The literal data is accessed at run time through the use of the LDR instruction,
which loads the data from memory using a PC-relative memory address. The execution of the LDR
instruction generates a read transaction across the Cortex-M3's DCode bus, which is subject to the
execute-only protection mechanism. If the accessed block is marked as execute only, the transaction
is blocked, and the processor is prevented from loading the constant data and, therefore, inhibiting
correct execution. Therefore, using execute-only protection requires that literal data be handled
differently. There are three ways to address this:
1. Use a compiler that allows literal data to be collected into a separate section that is put into one
or more read-enabled flash blocks. Note that the LDR instruction may use a PC-relative
address–-in which case the literal pool cannot be located outside the span of the offset–-or the
software may reserve a register to point to the base address of the literal pool and the LDR
offset is relative to the beginning of the pool.
2. Use a compiler that generates literal data from arithmetic instruction immediate data and
subsequent computation.
3. Use method 1 or 2, but in assembly language, if the compiler does not support either method.
214
July 14, 2014
Texas Instruments-Production Data