5V tolerant pins
Marcus76
Posts: 25
in Propeller 2
Something that would be nice to have with the Propeller 2 is 5V tolerant pins. This would allow the P2 to send and receive 5V TTL signals, as well as 3.3V CMOS signals. The logic thresholds for 5V TTL are exactly the same as for 3.3 CMOS (they are 2.5V and under). An example of this is in the LVC logic family, typically used for the 7400 series.
To accomplish this the Vcc steering diodes on the inputs are omitted, preventing a 5V input signal from flowing to Vcc. Also the body terminal of the high-side MOSFET outputs are connected to Vcc with another MOSFET, rather than being directly connected. Turning this additional MOSFET off prevents the driver's parasitic diode from conducting with a 5V signal.
Here is a document that I found that describes the LVC inputs and outputs:
http://documentation.renesas.com/doc/products/logic/rej27d0017_lvlvc_an.pdf
I am not sure how the LVC family does protection from ESD. The steering diode to CMN will protect against negative discharges, but there is no diode to Vcc to protect against positive discharges. The family still manages to have a 2000V HBM and 200V MM rating. Perhaps a Zener is used?
To accomplish this the Vcc steering diodes on the inputs are omitted, preventing a 5V input signal from flowing to Vcc. Also the body terminal of the high-side MOSFET outputs are connected to Vcc with another MOSFET, rather than being directly connected. Turning this additional MOSFET off prevents the driver's parasitic diode from conducting with a 5V signal.
Here is a document that I found that describes the LVC inputs and outputs:
http://documentation.renesas.com/doc/products/logic/rej27d0017_lvlvc_an.pdf
I am not sure how the LVC family does protection from ESD. The steering diode to CMN will protect against negative discharges, but there is no diode to Vcc to protect against positive discharges. The family still manages to have a 2000V HBM and 200V MM rating. Perhaps a Zener is used?
Comments
That's a key issue.
To make a chip 5V tolerant needs special oxide steps (aka extra cost) and they can still have caveats,
Often you find in the fine print, the 5V tolerance is under bias (ie 3v3 must be present), and operating with 5V on a unpowered part is outside spec.
I tested an Atmel CPLD once and found the ESD clamps were ~5.6V, but they would not spec it as 5V tolerant, IIRC due to the oxide not being rated for sustained 5V.
(ESD events are very brief, and unlikely too )
These days virtually every ARM I see has 5V tolerant pins, and often that includes when they are running below 3.3V. Yes the part has to be powered for that tolerance, but that is also true of LVC parts, otherwise you are trying to power the device through the parasitic diodes.
The last place I worked they spent a lot of engineering time on the pads, so I don't expect you will see documented how they did it.
Any links for that requirement ?
The NXP LVC data I have here, says this :
{"[2] When Vcc = 0 V (Power-down mode), the output voltage can be 5.5 V in normal operation."}
But is that just as far as the clamping diodes permit (in which case input current would 'take off' near extremes), or can this range be wider?
So the LVC-A revision adds 5V tolerance to the outputs, when powered and unpowered.
Also, I disagree with the notion that ESD events are rare. ESD events below sensation threshold happen all the time, and can cause damage that doesn't lead to immediate failure. Just look at the measures taken to prevent it: ICs are shipped in anti-static bags and/or foam, and nearly all modern digital ICs have ESD protection on all pins just for handling before installation on a board.
99.99+% of any pins life, it will not be clamping an ESD event.
I think the design could be tweaked so that we can get away with not increasing the gate voltage rating:
Pin - > low-side diode clamp + ESD circuit + output -> resistor -> high-side diode clamp + low-side diode clamp -> input gates
The high-side diode clamp would ensure that the gate voltage does not rise much higher than the input voltage. The resistor would ensure that the current through this diode is very small. Then the pin could tolerate any voltage lower than the max drain-source voltage, which should be higher than the max gate voltage.
http://120.118.152.72/paper/Jrnl/J009.pdf
AFAICT, the standard set is that all NMOS' bodies are basically the same as the IC's substrate, so you can only control where the PMOS' bodies connect to. So we cannot achieve 5V tolerance when *unpowered* without adding another silicon processing step.
However, it should be possible to raise the voltage tolerance of the inputs while powered to Vcc+Vth by connecting the PMOS driver bodies to a second PMOS that controls whether the driver's body is connected to Vcc. This second PMOS' body would be connected to the first PMOS' body (preventing current from the pin to Vcc through the parasitic diode). So long as the pin's voltage does not exceed Vcc+Vth, the second PMOS can be driven high to open the circuit.
Once the pin voltage exceeds Vcc+Vth, the gate of the second PMOS will be "low" relative to the pin and the circuit will close. However, Vcc+Vth should be just above 5V when Vcc is 3.3V (Vth is ~2.5V IIRC), so the circuit will be able to tolerate 5V input/output while *powered*.
Does this sound feasible? Do the typical cell libraries include a configuration like this for input/output?
What you are talking about, Marcus76, all sounds right to me, though.
As you say, it is technically feasible, but so are many things.
Also technically feasible is to have a 1.8~5.5V operating spec on the whole device, other MCUs manage that, on finer process too - but there is no free lunch.
Easy to say - However, I wonder what OnSemi give as the price-adder for actually implementing this ?
Hmm.. 5V supply, seems to not even be on the table ?
http://www.onsemi.com/PowerSolutions/content.do?id=16678
However, they DO have a column 5 V Tolerant, with some ticks.
Thus 5V Tolerant may be on the table.
A quick check finds these new FAB IP blocks
The ten (10) new IP blocks that have most recently been qualified, provide functions that range from small-pitch column-parallel ADC and cryogenic-compatible LVDS drivers to ultra-low power oscillator and very-small footprint OTP memory.
Of those, the very-small footprint OTP memory could open custom-ROM offerings from Parallax, and the ultra-low power oscillator is not clear if that is 32KHz Crystal, or on-chip RC Osc ?
The later is useful for Watchdog and meeting IEC 60730 etc standards.
The link above shows 5V tolerant, so you could check into the impact of adding 5V tolerance to the 3.3V IO pads ?
In fact, it seems to be only 1.8V IO and 1V ,1.8V operation that excludes 5V Tolerance ?
He does say 5V IO is not available, and On-Semi's website does suggest the same.
Just what the exact impact of OnSemi's various 5V tolerant, 3.3V PAD choices are, is not yet clear.
Looking at another vendors parts with 5V tolerance, in similar process size, shows Digital IO and Analog in pins can be 5V tolerant, but their 4 high drive DAC out pins, are not 5V tolerant.
1.8~5.5V power.
http://www.silego.com/products/greenpak_dualsupply.html
Packages
20-pin STQFN: 2.0 x 3.0 x 0.55 mm, 0.4 mm pitch
12-pin STQFN: 1.6 x 1.6 x 0.55 mm, 0.4 mm pitch
I guess from Parallax/Treehouse's position, even with custom layout at their disposal, they just don't have that level of customisation available.
From OnSemi's position, I find it surprising given the obvious advantages to it's customers if the option was available.
We could do it, but I'm quite sure we'd have to have two series PMOS devices to drive high, even at 3.3V. This would compromise things quite a bit. If we only had digital pins, and not analog, I'd look more into it.
It's probably worthwhile asking OnSemi, about true 5V, as things get close, as they seem to be adding IP all the time to their process library.
eg The very-small footprint OTP memory seems a somewhat recent addition to the 180nm process, which would seem worth checking against ROM.
I think XMOS have a small OTP block, and once you have OTP, many more applications open up.
(This is also how SiLego and the cheapest Lattice FPGA/CPLD operate)
On the topic of Pin-design, will the P2 Crystal choice register settings match P1 ?
Other XTAL details to cover :
There is also an emerging use case, which most current MCU Xtal amplifiers do not formally spec to cover, and that is Clipped Sine TCXO.
These have moved significantly in price, so much they now outflank many CMOS OSC, and they offer lower ICC and less RFI, so they are accelerating in use. (that will further drive the price skew)
Quite serious specs of 0.5~2ppm, VCTCXO come for under $1 in modest volumes from Epson/Abracon/AVX
Common MHz values are 19.2MHz, 26MHz, 52MHz etc
To support this, the Xtal amplifier needs minimal CL setting, and needs to clock correctly with 0.8v p-p clipped sine drive (AC coupled).
Most Xtal amplifiers (Buffer and following schmitt) will do this, up to some MHz value.
The expected design of flags outputs is usually open drain, which should be ok (sink only)
I presume you can resocket the USB plugs and the problem temporarily goes away? USB is prone to data glitches in general, I'm guessing its state engines tend to get corrupted and need resetting.
Doing all the usual noise immunity tricks can make a world of difference but the software does probably need to handle resetting each USB controller as they crash as well.
PS: What is the FTP2700? I'm not getting any google hits.
Have you swapped out likely failed parts, then tested those in known-good boards - just to confirm it is a permanent failure mode you are seeing, & on which device(s).
We recently had a flood in our lab and several pieces of test equipment was damaged. I'm going to start by replacing the Propeller chip. I'm also thinking of buffer chips between any 5v or greater chip and the Propeller.
I just hate to change the microcontroller before I know the cause of the failures.
Sorry about the typo earlier..it is a FPF2700 Adjustable over current load switch...
In these days, 5V is less used and it is becoming rare. Most modern micros don't even implement it.