Separate the memory regions
ST’s programming manual for STM32F205/215 and STM32F207/217 describes several distinct stores within the device. Main Flash contains the application-memory area. System memory has a manufacturer bootloader role. The OTP area provides user-data storage with an associated locking arrangement, while option bytes carry configuration and protection functions. Calling all of these simply firmware loses the architecture that determines what a programming or erase statement actually covers. A description of one region cannot silently become a statement about every other store merely because they occupy the same packaged microcontroller.
The separation concerns purpose as well as location. Manufacturer bootloader memory and customer application memory are not interchangeable descriptions of code ownership or programming history. Likewise, user data in an OTP area need not be executable application code, and configuration information has another function. A statement that application Flash was cleared therefore needs to retain that region name. It leaves the other stores as separate subjects. This named-family example explains the distinction without identifying any offered device’s contents, reconstructing a memory map or assigning the same organisation to another MCU family.
Separate OTP contents from its lock mechanism
Within the described OTP arrangement, ST distinguishes data blocks from a corresponding lock area. The data store answers what information may have been programmed. The locking mechanism concerns whether further programming of its associated block is permitted. These are different properties even though the manual discusses them together. A report saying only OTP locked would omit the distinction between a programming restriction and the information already held in the data region. Conversely, describing a data region does not by itself identify the state of its associated programming lock.
The manual also explains that both the OTP data and lock blocks are non-erasable in this architecture. This prevents an unlocked description from being interpreted as a promise that existing data can be removed. Permission for further programming and the ability to erase are separate capabilities. The qualitative distinction is enough to explain why lock state needs its own meaning; it does not require publishing the lock encodings, assigning a block number or giving a programming sequence. No lock state or data value is established for surplus material by the existence of the documented mechanism.
Explain the boundary of main-memory erasure
The manual explicitly excludes OTP from the mass erase discussed in its protection section. That exclusion gives a concrete boundary to an otherwise broad-sounding operation name. Mass erase should be understood within the memory scope the manufacturer describes, rather than taken as an ordinary-language promise to clear every nonvolatile store. The technical result relevant here is that main-memory erasure and OTP persistence can coexist. A statement about application Flash can consequently be accurate while a whole-device blank description remains unsupported by that statement.
This is a difference in the objects being described, rather than a dispute about the word erase. If a record concerns the application region, expanding it to OTP changes the claim’s scope. The same problem arises when a blank application image is treated as proof that no user information exists elsewhere. The manual’s region separation gives a reason to keep those assertions distinct. It provides no erasure procedure here, and it does not establish that any operation was performed. An actual programming record would still need to identify which device and which store its reported result concerns.
Keep region permanence separate from access protection
A region’s inability to be erased is different from a restriction on access to it. ST describes read and write protection in the same architecture, but an access label does not reveal the information retained in a region. Similarly, an observation about whether application memory can be accessed is not a substitute for the OTP erase distinction. Keeping permanence, programming permission and access restriction as separate concepts avoids turning one protection-related word into a complete account of the device’s stored state.
For an offered STM32F20x/F21x item, these concepts provide a precise vocabulary: the application-memory statement, the separate OTP-content question, its programming-lock question and any supported access restriction. The existing programmed-MCU guide addresses the wider disclosure record; the contribution here is the technical boundary between those stores and mechanisms. None of the distinctions proves blank contents, security acceptance or unrestricted reuse. Nor does this example resolve another MCU’s architecture. The exact family documentation must supply that separate explanation, without inheriting an erase promise from the familiar presence of Flash.
Sources and further reading
ST PM0059, DocID15687 Rev 5: bounded memory-region, OTP data/lock and mass-erase-exclusion prose supports this named-family explanation. Addresses, capacities, encodings and operating procedures are outside this article.