1. Locate the manufacturer boot service
ST AN2606 describes a bootloader stored in the internal boot ROM, also called system memory, of the STM32 products covered by the note. It is programmed during production. Its described task is to download an application program into internal Flash. The service that performs that transfer and the application being transferred therefore occupy different architectural roles. The first is manufacturer-provided boot functionality; the second is the program intended to perform the customer's application. Calling both firmware without retaining their roles can conceal which program a description actually identifies.
The production origin of the ROM service explains why its documented presence is not a declaration that customer software has been installed. The service exists to support a transfer operation; the application image is the information that operation can place in a different memory context. A statement about one consequently cannot establish the identity or release of the other. This distinction concerns the STM32 architecture described by AN2606, rather than a universal rule for every microcontroller. It also concerns the boot service's purpose, without extending into the separate question of OTP erasure or other retained data regions.
2. Separate code transfer from program identity
AN2606 links the download task to serial peripherals and describes a communication protocol for each interface. The peripheral identifies a communication facility, while the protocol describes the communication used for the boot service. The application program is the payload being transferred. These are three different subjects even when a short description mentions them together. An interface name can identify the route available to a documented bootloader; it does not describe the instructions, configuration or customer release carried over that route. The communication mechanism and the identity of its payload remain distinguishable throughout the described transfer task.
This separation matters when a firmware record contains a familiar transport label but no application identifier. Repeating the transport name leaves the program-identity question unanswered because transport describes how information moves, not which information was supplied. Conversely, a known application release does not establish every interface supported by the device's ROM service. The note makes peripheral support dependent on the product concerned. A technically precise description can retain the boot service, its documented communication context and the separate application identity without supplying a pin allocation, a command sequence or an inferred transfer result.
3. Distinguish presence from entry availability
The activation discussion in AN2606 is product specific. Architectural presence of a system-ROM service and the conditions under which execution enters that service are separate properties. Presence says that the documented resource belongs to the product architecture. Entry availability concerns whether the applicable conditions permit that resource to execute in the relevant context. A catalogue statement that an STM32 has a bootloader therefore cannot be shortened into a statement that the bootloader is running whenever the part is powered.
The same distinction applies in the other direction. A description of application execution is about the program currently in control, rather than a complete catalogue of other boot resources. These statements can refer to different execution contexts without contradicting the architecture. AN2606's product-dependent treatment is the reason to retain the exact STM32 context when discussing availability. It provides no basis here for a common activation method across families. This explanation stops at the distinction between a documented service and conditional entry; it does not reproduce activation patterns, protection exceptions or any method for changing execution state.
4. Separate bootloader and protocol versions
ST's identification prose distinguishes the serial-peripheral communication-protocol version from the identifier associated with the device bootloader. The former qualifies the communication protocol used by the boot service. The latter concerns the STM32 bootloader and its supported peripheral context. These identifiers describe parts of the manufacturer boot mechanism. Neither is, by definition, the release number of the customer application that may be transferred into internal Flash. A field labelled version becomes ambiguous when the object being versioned is removed.
Keeping the subject attached to each identifier resolves that ambiguity without decoding it. A protocol-version description belongs beside the communication reference; a device-bootloader description belongs beside the applicable STM32 documentation; an application release belongs to the application record. Agreement in one field cannot fill another merely because all three refer to software on the same packaged MCU. The resulting account distinguishes location and production role, transfer and payload, conditional execution and identifier meaning. It explains the boot architecture while leaving actual application contents and observed device execution to their own evidence.
Sources and further reading
ST AN2606 Rev 70: bounded introduction and the opening activation/identification prose on physical pages 1, 34 and 37. Product activation tables, security exceptions, commands, identifier encodings and individual device chapters are outside this explanation.