Distinguish external read restriction from internal execution
The word protected is incomplete without identifying who is trying to access memory. ST's AN5156 describes readout protection in terms of external access contexts and the behavior of code executing internally. In its named protected context, a restriction on access through debug or other external paths can coexist with access by the user application running from Flash. An external reading restriction and the ability of the application to execute are therefore different statements. They refer to different actors and access circumstances rather than opposite conclusions about whether the memory exists.
This actor distinction also matters when considering modification. The note separates externally initiated content updates from changes performed by an internal application in the described context. It does not follow that a restriction visible to an external tool describes every operation the executing application may perform. Keeping the access origin explicit avoids treating protection as one undifferentiated block on all memory use. The mechanism explains how confidentiality against a particular external path can coexist with intended internal operation. It supplies no finding about an offered device's settings, stored application or available access paths.
Separate write inhibition from copy protection
Write protection asks a different question: whether a specified Flash area can be erased or updated. AN5156 describes WRP as inhibiting those alteration operations. Its scope is an identified memory area rather than a generic promise that every kind of access is prevented. The operation matters because preserving existing contents against alteration is a different responsibility from restricting their disclosure. A statement about inhibited writing consequently does not, by itself, describe whether an external reader or an executing application may obtain the contents.
The area boundary adds another independent part of the description. A protection applied to a selected region does not become a claim about the entire device merely because the general feature is called write protection. The note relates the granularity to the applicable device's memory organization. Retaining both the area and the prohibited operation makes the protection account precise without teaching its configuration. This is useful when reading a description containing several protection names: WRP contributes an alteration boundary, while another mechanism may address access or execution. Their different responsibilities should remain visible instead of being compressed into a single protected-memory label.
Explain execute-only instruction access
Execute-only protection separates instruction fetch from data access. AN5156 explains PCROP through an area whose firmware can be fetched by the CPU instruction bus while attempts to read or write it as data are restricted. The allowed instruction operation and the restricted data operations concern the same protected area, but they are not the same kind of transaction. This is why executing code does not necessarily imply that its stored representation is available through an ordinary data-reading operation. The operation category is central to the protection's meaning.
The note also makes clear that this account is not simply the external-versus-internal distinction used to explain readout protection. Its execute-only restriction addresses data access from internal firmware as well as external debug contexts. Actor and operation must therefore be retained together. Saying only that an application runs internally would leave out whether it is fetching instructions or trying to read an execute-only area as data. The feature's availability and protected-area organization remain device dependent. This explanation preserves that access matrix without deriving settings, compiler procedures, an actual protected-region map or a way to recover a stored application.
Retain content-loss and family boundaries of transitions
Changing protection and preserving contents are separate questions. AN5156 describes protection regressions with erase consequences, including consequences that depend on the transition and applicable memory domain. A change to a less restrictive state is therefore not inherently a content-preserving operation. The transition can affect the information that was being protected. This is a consequence of the documented state change, not evidence that the contents of a particular removed MCU have already been erased or remain recoverable.
The note also retains family-specific boundaries. Protection levels and permitted transitions are not one universal matrix shared identically by every STM32. Its description includes named-family exceptions involving preconfigured OEM authorization, so a blanket statement that the highest protection level is always irreversible would lose a documented exception. Those qualifications can be stated without presenting keys, encodings, connection modes or a regression procedure. Together, the actor, operation, region and transition consequence form distinct parts of a protection description. They explain why an unknown protection state cannot be reconstructed from the broad term programmed or from a general claim that an application still executes.
Sources and further reading
STMicroelectronics AN5156 Rev 14, bounded sections 6.2, 6.8 and 6.9: qualitative RDP, WRP, PCROP and transition-content consequences. Family exceptions remain specific. No actual state finding, key, option-byte value, entry, clearing, erase or bypass procedure.