Separate discoverable parameters from capacity labels
A NOR capacity label describes the storage size, but the host also needs information about supported access behavior. The PSoC6 usage material describes SFDP as a way to obtain device parameters and populate the corresponding host configuration. Discovery therefore answers a richer question than whether a candidate has the expected capacity.
Keep the discovered parameter set distinct from the external product description. A capacity entry can be correct while still leaving the relevant access capabilities unspecified in the comparison. Conversely, the ability to obtain parameter data does not establish that every possible host operation or application requirement is supported by that device.
The useful reading is implementation specific: identify which capabilities the cited PSoC6 flow obtains and how that information is represented in its configuration. This provides a concrete basis for reviewing a NOR candidate without turning SFDP into a universal compatibility label. It also keeps the difference between discovering a supported feature and demonstrating its successful use visible throughout the comparison, rather than allowing the discovery acronym to stand in for the entire substitution decision.
Keep discovery with the hardware slot and initialization
Automatic discovery occurs in a configuration context. The Infineon material associates SFDP population with the selected hardware slot and initialization flow, rather than presenting it as a property that applies independently to every connection. The host must be considering the relevant slot and its enabled configuration before discovered parameters can describe that interface.
This separates the capability of the flash from the preparation of the host. A device can support the discovery mechanism, while a particular host configuration may not be set up to use it for the slot being reviewed. Those are different responsibilities, and neither can be inferred solely from a capacity or package description.
When comparing a proposed configuration, retain the slot association and initialization basis alongside the discovery statement. The result should make clear which host context is expected to receive the parameter information. That is a more precise description than saying that the flash is automatically detected in all circumstances. It preserves the named software flow without providing a transaction sequence, initialization code or a claim that the configuration has actually been exercised on hardware.
Retain manual support for unsupported devices
The cited PSoC6 material retains a manual configuration route for devices that are not supported by its automatic setup. That route is not an extension of an assumed successful discovery result. It requires the appropriate device information to be supplied in the host configuration rather than treating the absence of automatic population as if it had already produced usable parameters.
This is a third question in a substitution review: how is a candidate represented when it falls outside the documented automatic path? The answer concerns the host configuration that describes the device, not simply whether the flash has a familiar size or belongs to a broad technology category.
Keep manual support explicit instead of describing every NOR candidate as self-configuring. Doing so preserves a meaningful distinction between parameter discovery and configuration supplied from another documented basis. It does not establish that any manually entered description is correct or that an unsupported candidate becomes interchangeable by being listed. The named application flow still needs an applicable configuration, and this guide supplies neither device-specific entries nor an execution result for a proposed substitution.
Separate runtime discovery from the flash loader
The flash loader is a separate consumer of configuration information. The Infineon material explicitly states that its documented loader flow does not perform SFDP detection and instead requires stored manual configuration. This exception prevents a runtime discovery statement from being used as an explanation of every stage that may access the flash.
The distinction is functional. A runtime initialization flow can populate information through discovery, while the loader uses configuration available to its own process. A feature supported in one flow does not automatically become an operation performed by the other. Keeping their configuration sources separate explains why two stages associated with the same flash may need different preparation.
For a substitution review, identify which stage is under discussion before accepting automatic discovery as the answer. Preserve the loader requirement with the runtime capabilities rather than burying it as a general caution about software. This completes the configuration picture without claiming a successful boot, programming operation or universal host/flash combination. The positive outcome is an account of where parameters come from in each named flow and where discovery does not replace manual device information.
Sources and further reading
Bounded Infineon AN228740 PSoC6 implementation prose. This is not a full JESD216 interpretation, a device transaction, universal substitution approval or a demonstrated boot result.