The current configuration including UDB-settings will be re-written from your design. Any changes to redisters you made during the run of the program will get lost.
Bob, I did a hunt for the underlying mechanism that programs a UDB, non of the ap notes
speaks to its loaded from flash into ram configuration registers. There obviously was an
assumption users were FPGA knowledgable, which is a mistake in my estimation.
afaik there are a handfull of "Registers" for each UDB which settings are extracted from the generated verilog, including the necessary routing. Even Datapath objects are realized the same way. Changing these settings at run-time IS possible, but I question the need for that. Would make me feel like living at the brink of the world playing baseball.
Hi Dana and Bob,
thanks for your kindly reply. are there any documentation to describe the UDB initial mechanism?
what I mean is if a Software reset happened, are there any ways to avoid UDB re-configred, just keep previous logic which has been implemented?
In that ap note is a section -
The startup procedure may be altered to better fit a
specific application’s needs. There are two ways to
modifying device startup: using the design wide
resources (DWR) interface in the PSoC Creator GUI, and
modifying the PSoC 3 startup code stored in the CPU
specific source files and CyFitter_cfg.c.
Just for my curiosity: What is the reason you do not want the UDBs (ant probably Analog parts) to be excluded at reset.
OMG! a double negation! I WOULD LIKE TO HAVE AN EDIT FEATURE. And if possible in this decade.