Seeking safe power-up pin values | Cypress Semiconductor
Seeking safe power-up pin values
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.