I need to protect external circuitry from funny power-up pin values, not only for the short time while my PSoC5 is powering up, but also for the longer time when the board is powered but the PSoC5 is blank and hasn't been programmed yet.  These are my two scenarios of concern.

I'm accustomed to other processors whose digital I/O pins always power up as inputs, and therefore do NOT drive external circuitry.  For these processors, a resistor pull-up to power or pull-down to ground can put the pin in at a safe level for the two scenarios of concern.

I'm unsure of corresponding behavoir in the PSoC5, specifically the CY8C5368LTI-026 and its pins 53-56,60-66,68 (all GPIO).  I do read in the "PSoC 5: CY8C55 Family Datasheet" section "6.4.1 Drive Modes" that the High Impedance Analog Drive Mode is "The default reset state with both the output driver and digital input buffer turned off."  However, I'm not certain if this means what I need it to mean!

QUESTION ONE: So, please let me know if the enumerated GPIO pins will NOT drive out and can thus be effectively pulled with resistors in BOTH of my scenarios of concern (unprogrammed, program not yet running or not yet up to a particular place in code).

QUESTION TWO: One reason I'm unsure of the meaning of the "default reset state" sentence is because I'm unsure of how the programmability of the PSoC works in general, with respect to program operation.  Please allow me to explain my confusion.  In a regular processor, the internal wiring is fixed.  The status of a pin is fixed at power up regardless of blankness or program code, and then that status only changes when MY code changes it.  Contrast that with the PSoC5.  I can write program code to change the value of a pin.  I can also draw connections in PSoC Creator's TopDesign.cysch.  How are the connections in TopDesign.cysch implemented?  Is code generated "under the covers" such that this "programming" only happens when the code runs, and prior to this code running the connections are *not* present?  Or are "fuses" in the PSoC5 "programmed" such that *immediately* upon power up those TopDesign.cysh connections are present?  That makes a difference in my scenarios.  A blank chip surely won't have these connections, and so there's particular pin behavior for a blank chip (implied question: are the GPIO's tri-stated?).  A programmed chip microseconds after power up hasn't executed any code yet.  Depending on how TopDesign.cysch is implemented, a chip at this particular moment might look the same as a blank chip ("under the covers" code implementation), or it might have output drive turned on because of TopDesign.cysch connections and this drive is of an undetermined level for me ("fuse" implementation).  Then, finally, a chip that's had time to run a bunch of code will finally be well behaved according to *my* TopDesign.cysch and program code intent.

QUESTION THREE: Question two also implies a side effect.  Is TopDesign.cysch implemented by the "under the covers" code method or the "fuse" method?  If it's the "under the covers" code method, then this means that I *should* be able to reconfigure some connections present in TopDesign.cysch.  I forget the exact detail, but there was a reason I couldn't do what I wanted merely using TopDesign.cysch.  Instead, I wanted TopDesign.cysch to have one particular "default" connection between a mux and an ADC.  However, I wanted the ability in *my* code to change these once at power up to a *different* connection between the mux and ADC.  

Thanks very much.

GPIO are cpomtrolled by registers, laoded from FLASH (your configuration) at boot.

Startup and Low-Power Behavior

Out of the box, all GPIO pins start up in an Analog HI-Z
state and remain in that state until reset is released. The
initial operating configuration of each pin is loaded during
boot  and takes effect at that time. The reset behavior of
GPIOs can be changed in PSoC 3 using the PRTxRDM
fields of the nonvolatile latch array, which are written when
the PSoC is programmed.

In all low-power modes, GPIO pins retain their state until
the part is  reset or awakened. The port interrupt logic
continues to function in all low-power modes so that pins
can be used as wakeup sources.

Take a look at this - http://www.cypress.com/?docID=34818

Insofar as power up any processor takes control of its logic at a minimum specified

voltage, outside that range anything can happen. That being said when Vdd < Vth

of the logic, the logic cannot be "fully" turned on. Especially the high side driver because

of source bulk effect and bias pumps if applicable.

Regards, Dana.

One more comment. This is why we need customers to keep telling Cypress we

need a spice model of GPIO pins, models covering all operating modes.

Lastly a pull down serves to absorb device leakage, preventing turnon of Emitter

Base junctions etc.. If we had a model we would know what that worst case value

would be. Not knowing this you can compromise amount of drive to external circuits

and compute the lowest Rpulldwn still consistant with drive for external circuit.

Regards, Dana.

Hi Helmut,

Let us start to power up a PSoC.

At 0v nothing happens, well, how should something happen, there's no cause.

There is a small region ending at about 1.7 V (I do not have the exact value from datasheet at hand) where a programmable port drive mode takes effekt (for PSoC3 only and a complete port with all pins at same drive mode). Unprogrammed default is High z, but pull up or pull down is programmable.

When power is supplied to the chip, the programming of all the internals start, including the programming of the pin drives and states. During this period the pins are changing their beaveour from the POR (Power on-reset) state.

AfaIk a "Blank" (virgin) chip has no data in it to change pin-states, but in my opinion the first (or later re-)programming should never be made with critical hardware attached or powered.

Bob

When you look at the PSoC5 Register TRM, you see registers for all aspects you are asking for. This means that everything should be under software control. So Bob is right - everything should configured as input on startup, and is configured by software. (Though this is nowhere stated explicitely - if you want to have a definitive answer you need to ask Cypress directly).

But working with the registers, away from all the APIs, will make thing much more complicated. Especially you might lose all the support from PSoC Creator and need to do everything manually.

What is it what you really want to do? One way to achive what you described is to power up your peripherals later than the PSoC, so they don't see the glitches. Or you can add controlled buffers between them and the PSoC.

There is a 4 part series on Power Supervisor on the PSOCm Today video area.

http://www.cypress.com/?rID=60521

In summary -

1) The primary problem in power up with external loads/drivers/components is exceeding

some threshold of some device prematurley, when the Host is not in control of itself. This

includes setup time issues. TI exhausted itself in 70's trying to create a F-F that would

handle any runt pulse. Still can't buy it.

2) A thorough datasheet normally includes ramp rates for its Vdd supply. Classic problem is

ramping a supply too slow and simple gates will exhibit analog effects rather than digital behaviour

if their Tr, Tf at input is too slow. That is also the way you test a design for faults, ramping

supply at various rates.

3) Generally the threshold in most designs that is a problem is that of a bipolar transistor,

there are special technologies even lower. Many techniques of voltage offset, dropping,

can be used to keep something for turning on prematurely. Even RC delays to hold

off or remove transients.

4) Do not be afraid of register manipulation. It has its place, and gives us more flexibility.

Especially in designs where UDB limnitations can be overcome with devices with large

FLASH that can be used to reprogram chip on the fly. One of PSOCs great examples.

Happened to be in PSOC 1, was a coke machine. There was too little HW in device. So

during day counted change, kept track of inventory, cash, monitored compressor.....At night,

reconfigured into DTMF, dialed up distributor, and uploaded all bottle and cooler information,

then went back to being an accountant. Done it a super cheap part, there were and are

millions of coke machines, a dime saved is ........well you know the rest :)

Regards, Dana.