Prop 2 Fuse conundrum - Vpp ?!

From the other thread... thinking some more, on how designers will use P2 in volume production cases :
cgracey wrote: »
...

I've asked OnSemi for more fuse info, but not much has come back. So, the fuses remain the same. They are supposed to be blown at 5V,, I just learned, but we are set up for 3.3V. I had one stubborn fuse in the last test batch. Worst case, we must build a special programmer to briefly drive higher voltage into the VIO of the 4-pin bank whose 16 fuses are being blown. That sounds crazy, I know, but how else to get 5V at 35mA? We could come up with a programmable power supply circuit for common board use that normally outputs 3.3V, but can jump up briefly to 5V for the fuse blow. That would need one I/O pin and be under software control. The blow time is under 1ms.
" cgracey : Worst case, we must build a special programmer to briefly drive higher voltage into the VIO of the 4-pin bank whose 16 fuses are being blown."

How wonderfully last century. I don't think I've used a chip that needed a special voltage to program it since the days of the 2764.
There are quite a few parts with Vpp pins, (both Flash and OTP) in volume production today. It is just less visible than on the 2764.


Thinking more on this, and how designers might use P2 in systems, the presence of a Vpp pin is less than ideal, but Chip is actually saying something much worse : "briefly drive higher voltage into the VIO of the 4-pin bank whose 16 fuses are being blown"

That means every VIO is a Vpp(over voltage) pin, and this has serious design impacts: Much of what P2 connects to, will not be 5V tolerant.
If they cannot tolerate 5V, they cannot modulate Vpp - it is a drop dead ISP problem.

This forces users into a ZIF socket, and pre-insertion programming & handling. (*ugh*)

That's a rather serious and unexpected bump in P2 deployment, seems the choices from here are to

a) Shift the Fuse supply to a single, Vpp pin, so every VIO pin does not have to 5V spike.

b) Change to an OnSemi OTP/MTP cell, for the Fuses, that does not need Vpp-Pin at all.

In 2017+, users certainly will expect MTP and no Vpp-Pin.
«13

Comments

  • 61 Comments sorted by Date Added Votes
  • msrobotsmsrobots Posts: 1,539
    edited June 23 Vote Up0Vote Down
    Bad.

    I read the post but did not make the connection (pun intended).

    This is scary. Not sure how you want to use a ZIF-socket for the current planned packaging of the P2 to burn them before placing and soldering.

    really bad.

    Mike

    I am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • jmgjmg Posts: 10,206
    msrobots wrote: »
    Bad.

    I read the post but did not make the connection (pun intended).

    This is scary. Not sure how you want to use a ZIF-socket for the current planned packaging of the P2 to burn them before placing and soldering.

    really bad.

    Actually, the news gets worse...

    I've looked for TQFP100 ZIF sockets, and yes, those do exist.

    Problem is P2 is not just TQFP100, it is EPAD TQFP100 and GND is only via EPAD, so > 100 connections are needed.

    I've not yet found an EPAD TQFP100 ZIF socket, but maybe you could hand-craft one from a TQFP100 and multiple spring pins on the EPAD area .. ?

  • Cluso99Cluso99 Posts: 12,632
    edited June 24 Vote Up0Vote Down
    I cannot recall how many times I have pleaded with Chip to ask OnSemi about adding FLASH/EEPROM/OTP to the P2. There is probably an easy way to add this in, and it would solve the fuse problem as well as booting.

    Sorry Chip, but it's insane that you haven't even asked. You are about to do another expensive shuttle run and just now you discover these problems. Why weren't they discovered on the last shuttle???



    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • I hope I'm not intruding here but could someone enlighten us about this fuse thing, what they actually are and what they are used for. And what does this "fuse problem" mean to the hobbyist / user?
    Are these "fuses" similar in purpose to Microchip's config parameters used at the top of every program?
    Just a little concerned...

    Hal
    Florida, between St. Petersburg and the Gulf of Mexico

    Do not look directly into laser with remaining good eye...
  • They are mainly for the security key, but if not used for that then they can be used as user bits. IIRC there are around 200 bits/fuses.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • It is the security feature P2 is supposed to have.

    Fuses are one time programmable bits. Once written to a P2 they can not be changed and can be hidden from the running software.

    The basic idea here is code protection, but some of the fuses are supposed to be able to be used by your own software, to put in some serial numbers or whatever.

    They are called fuses, because they kind of get burned away, so no recovery or reset to old state is possible.

    The basic security aspect of the P2 (witch seems to be important for some customers) is that the ROM boot loader in the P2 can be set to just accept a program if it is encrypted with sha256 and the corresponding 256bit key is programmed/burned into the fuses.

    if you have a key 0 in your encryption-key fuses it will accept any program, but if a key is set, the program to load has to be encrypted with that key or it will not run.

    As far as I recollect there are 256 bits for the SHA-key and some (also256?) to be used for other purposes, like serial numbers, or so.

    The problem now seems to be that them fuses need a higher voltage to be set/burned as the normal operation voltage of the P2. By now P2 needs already 2 supply Voltages, 1.8 Volts for the core and 3.6 for the I/O pins.

    If we need a third voltage of 5V to burn the fuses, as it seems to be, we are in big trouble, because then things connected to 3.6 Volt P2 pins would need to sustain a Voltage of 5V while the fuses get burned. Not nice.

    Or you would have to burn them fuses before you solder the chip on your board. Not nice either.

    Mike


    I am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • jmgjmg Posts: 10,206
    Hal Albach wrote: »
    I hope I'm not intruding here but could someone enlighten us about this fuse thing, what they actually are and what they are used for. And what does this "fuse problem" mean to the hobbyist / user?
    Are these "fuses" similar in purpose to Microchip's config parameters used at the top of every program?
    Just a little concerned...

    Hal

    P2 DOCS say this about fuses :

    256 programmable fuses for code security and user application
    * First 128 are used for SHA-256/HMAC loader signature verification
    * Next 127 can be used for AES-128 main code decryption or user application
    * Last 1 write-protects the rest
    Fuses can be hidden before user code executes


    Other vendors use fuses to define Boot Sources, Default Pin States, Oscillator Sources, and device security.
    P2 fuses are OTP, so currently are used for security and user-applications.


  • Cluso,
    I am pretty sure Chip did ask them about flash and replied in one of these threads about it. If I recall right it would require a different process and lots of money.
  • Hi all

    Did someone read the following document, from OnSemi, about available ONC18 process options?

    Aparently, ONC18 G/MS has all the options to satisfy P2 needs, including 5V tolerant I/O, high voltage/low Rsp PLDMOS devices (to burn the fuses) and even OTP (Sidense IP; 1kb and 128kb instances).

    I've had also linked it to my post about fuses, at the other thread.

    Henrique

    https://onsemi.com/pub/Collateral/ONC18GMS-D.PDF
  • ElectrodudeElectrodude Posts: 1,074
    edited June 24 Vote Up0Vote Down
    Can't you just leave it as it is now, and have the fuse-burner program repeatedly attempt to burn a random fuse and then test if it was actually burnt, repeating until enough are burnt (where "enough" is also determined randomly, probably Gaussianly distributed around half), then send which fuses were actually burnt to the programming computer? Get rid of the write-protect fuse and instead make it check all the fuses on boot and write-protect them if any were blown on boot. (This introduces a race condition where the device can be bricked if it loses power during fuse-blowing, but a robust serial protocol for the fuse burner that sends each fuse as it is blown and waits for an acknowledgment before moving on would solve this race condition).

    This means every P2 will have a unique key, but cryptography says this should be done anyway - otherwise, if every P2 in a given product had the same key, all it would take to crack the code protection would be for one sufficiently determined cracker with access to the appropriate expensive machinery to determine the state of the fuses via silicon surgery and distribute his results.

    This suggestion, of course, would only work if half-blown fuses are reliable.
  • jmgjmg Posts: 10,206
    Yanomani wrote: »
    Aparently, ONC18 G/MS has all the options to satisfy P2 needs, including 5V tolerant I/O, high voltage/low Rsp PLDMOS devices (to burn the fuses) and even OTP (Sidense IP; 1kb and 128kb instances).
    Err, yes, but what is in the PDF, and what is in the P2 Analog design, currently diverge somewhat (not all of what OnSemi can do is being used...), which is why we have this issue..


    Can't you just leave it as it is now, and have the fuse-burner program repeatedly attempt to burn a random fuse and then test if it was actually burnt, repeating until enough are burnt (where "enough" is also determined randomly, probably Gaussianly distributed around half), then send which fuses were actually burnt to the programming computer? Get rid of the write-protect fuse and instead make it check all the fuses on boot and write-protect them if any were blown on boot. (This introduces a race condition where the device can be bricked if it loses power during fuse-blowing, but a robust serial protocol for the fuse burner that sends each fuse as it is blown and waits for an acknowledgment before moving on would solve this race condition).

    This means every P2 will have a unique key, but cryptography says this should be done anyway - otherwise, if every P2 in a given product had the same key, all it would take to crack the code protection would be for one sufficiently determined cracker with access to the appropriate expensive machinery to determine the state of the fuses via silicon surgery and distribute his results.

    This suggestion, of course, would only work if half-blown fuses are reliable.

    hehe, I like the Russian-sounding nature of this solution :)
    I'm not sure a software based protection decision, is very robust ?

  • Roy Eltham wrote: »
    Cluso,
    I am pretty sure Chip did ask them about flash and replied in one of these threads about it. If I recall right it would require a different process and lots of money.
    Chip did ask years ago. May have even been TSMC back then. But as far as I recall he has not asked in recent years. Things have changed plenty, including lower leakage which just may have saved the P2HOT, but that's a different story. Even the public ONC18 includes OTP now. What this means remains to be asked. No point putting your head in the sand and after P2 is complete, finding out it was a simple question that was never asked.

    Seems we are there with the fuses now.

    Chip found out after manually laying out the Dual Port RAM that OnSemi had a library of RAMs. Lots of wasted money and effort IMHO because questions hadn't been asked.

    OnSemi make EEPROM (24C512) and FLASH. I am sure they make micros with Flash too.
    Maybe they have a library, maybe they don't. Surely it's worth asking. Would also solve the fuse problem.

    If the fuse problem ends up being as Chip now suggests, might as well delete them, because the P2 will be a joke if it required a higher voltage to program, and cannot be done in circuit.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • yes
    I am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • YanomaniYanomani Posts: 371
    edited June 24 Vote Up0Vote Down
    jmg wrote: »
    Err, yes, but what is in the PDF, and what is in the P2 Analog design, currently diverge somewhat (not all of what OnSemi can do is being used...), which is why we have this issue..

    If I understood it right, including the many discussions had when P2 analog test chip arrived, one of the many design goals of burying the fuses under the pad metal was to difficult any reverse engeneering efforts to read them.

    Any way, if this was the design goal at the fuse area, and this is causing so much trouble, please do read Sidense explanations about their 1T antifuse IP technology and how it defends itself from reverse engeneering attempts.

    If programming voltage/current are concerns, they also have an extra IP for an on-silicon power source, to programm the fuses, without stressing anything. But I must confess that I didn't follow that path too far, them I can't even talk about its programming method nor power requirements.

    Try Googling "Sidense oxide rupture OTP 180nm", lots of info about them and their proccess.

    Note: I have nothing to do with Sidense nor any other company or enterprise. I'm 100.0000000000000000% Parallax-blooded, by free will choice!

    Continuing... If the fuses are causing so much trouble, why don't give them a try, letting everything (actual fuses) where they are and re-routing the individual bit-read lanes to a sample of their 1kbit OTP instances?

    Again, please escuse me if I had understood it in an unusual way, as many times things like this has impaired my communication with some (if not all) members of the forum.
    Sure i'ts my fault by having 25% brazilian canibal's blood running in my veins, 25% basque, 45% portuguese, 3% french and 2% mixed between spanish and arab (ouch!), but, I swear I don't have any intention to bite no one! (at least consciously, in case of human flesh!) :lol:

    Henrique
  • jmgjmg Posts: 10,206
    Cluso99 wrote: »
    Maybe they have a library, maybe they don't. Surely it's worth asking. Would also solve the fuse problem.

    They do have some libraries.
    In the PDF linked above, under NON−VOLATILE MEMORY there are 5 lines in the table. ALL show N (None?) in the Added Masks from Base column

    A little strangely, not all choices push-right, and some seem to be only one subset process
    - eg High Temperature CMOS LogicEE Trim is I4T 45 V/70 V subset only.

    In July 2016, MTP shows as R&D in 2 columns (but not base ONC18 G/MS ? )
    There is a CMOS LogicEE Trim showing for base ONC18 G/MS, which might be ok for low-count fuse use.

    I note their Poly Fuse OTP is limited to higher voltage process, so maybe they already know what Chip discovered, that 3v3 is just a bit light weight for Poly Fuse OTP ?

  • cgraceycgracey Posts: 7,737
    edited June 24 Vote Up0Vote Down
    On six test-chip boards we built using the last test chip, there were 24 fuses, total, and I had a hard time blowing one of them. I recall upping VIO to 3.6 volts did the job. If heightened voltage was applied to the VIO pins, it would not mean that any pIn would be outputting a high voltage, as they may remain inputs. All it means is that the voltage is internally available to blow the poly fuses. I will ask OnSemi on Monday about their other non-volatile memory options for their ONC18 process.
  • Sure i'ts my fault by having 25% brazilian canibal's blood running in my veins, 25% basque, 45% portuguese, 3% french and 2% mixed between spanish and arab (ouch!), but, I swear I don't have any intention to bite no one! (at least consciously, in case of human flesh!)

    Actual it can not be your fault, where your heritage comes from. You had no influence on it. and your English is quite good so no need for excuses.

    I personally would fear the 25% basque more then the 25% Brazilian canibal's, but that is just me, never been in Brazil, just Portugal and Spain, and as a German I avoided France somehow.

    Mike




    I am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • cgracey wrote: »
    If heightened voltage was applied to the VIO pins, it would not mean that any pIn would be outputting a high voltage, as they may remain inputs. All it means is that the voltage is internally available to blow the poly fuses.

    Can the reset pin be used for that purpose ? If I'm not wrong, it should be tied to Vcc with normal operations, while programming it could be raised to Vpp for the time needed.
  • macca wrote: »
    cgracey wrote: »
    If heightened voltage was applied to the VIO pins, it would not mean that any pIn would be outputting a high voltage, as they may remain inputs. All it means is that the voltage is internally available to blow the poly fuses.

    Can the reset pin be used for that purpose ? If I'm not wrong, it should be tied to Vcc with normal operations, while programming it could be raised to Vpp for the time needed.

    It would require a huge amount of metal to get 35mA near 5V all around the pad frame. Each I/O pad has four fuses and a low-Z connecrion to the local VIO. I will see if OnSemi has something like a 256-fuse block. That will be better for future reduced-pin-count versions.
  • cgracey wrote: »
    On six test-chip boards we built using the last test chip, there were 24 fuses, total, and I had a hard time blowing one of them. I recall upping VIO to 3.6 volts did the job. If heightened voltage was applied to the VIO pins, it would not mean that any pIn would be outputting a high voltage, as they may remain inputs. All it means is that the voltage is internally available to blow the poly fuses. I will ask OnSemi on Monday about their other non-volatile memory options for their ONC18 process.
    So if a P2 is already soldered into a circuit it seems like jumpers will be required to isolate the VIO pins from the rest of the board. And a circuit will be needed to momentarily pulse the VIO pins with a higher voltage. I suppose that could be designed into the circuit board, or maybe a small circuit board could be attached to a header.

  • cgraceycgracey Posts: 7,737
    edited June 24 Vote Up0Vote Down
    Dave Hein wrote: »
    cgracey wrote: »
    On six test-chip boards we built using the last test chip, there were 24 fuses, total, and I had a hard time blowing one of them. I recall upping VIO to 3.6 volts did the job. If heightened voltage was applied to the VIO pins, it would not mean that any pIn would be outputting a high voltage, as they may remain inputs. All it means is that the voltage is internally available to blow the poly fuses. I will ask OnSemi on Monday about their other non-volatile memory options for their ONC18 process.
    So if a P2 is already soldered into a circuit it seems like jumpers will be required to isolate the VIO pins from the rest of the board. And a circuit will be needed to momentarily pulse the VIO pins with a higher voltage. I suppose that could be designed into the circuit board, or maybe a small circuit board could be attached to a header.

    Or, the 3.3V supply could be variable and via a resistor connected to an I/O pin, it could be increased momentarily.

    Or, a programming tool could drive 5V briefly into the 3.3V VIO net during fuse programming.
  • jmgjmg Posts: 10,206
    cgracey wrote: »
    Or, the 3.3V supply could be variable and via a resistor connected to an I/O pin, it could be increased momentarily.

    Or, a programming tool could drive 5V briefly into the 3.3V VIO net during fuse programming.

    All of this requires careful design of dual supply nets, to avoid OTHER parts being damaged.
    BOM goes up, and 2 layer design is getting harder.

    P2 suddenly gets a lot more complex, if multiple rails must be used, and some users will simply overlook this, and need PCB respins, or worse, discover nagging failure rates in the field..
  • Either we live with this complexity, find a better solution from OnSemi, don't have code-protect, or make a dedicated 5V VPP pin into which all the fuses are grouped.
  • jmgjmg Posts: 10,206
    cgracey wrote: »
    Either we live with this complexity, find a better solution from OnSemi, don't have code-protect, or make a dedicated 5V VPP pin into which all the fuses are grouped.
    #1 is not much of a choice :(, #2 sounds ideal, #3 rather like #1, prunes-off whole market areas :( , and #4 is tolerable, if #2 proves impossible.
    The fuses can then pull into one area, close to Vpp ? which makes family support easier than spread around ring.


  • Or use nRES to gate the 5V VIO away from the pin power and into the fuse circuitry. Of course, this assumes that the fuses can be blown somehow during a reset condition. Not sure how that works ...

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • jmgjmg Posts: 10,206
    Or use nRES to gate the 5V VIO away from the pin power and into the fuse circuitry. Of course, this assumes that the fuses can be blown somehow during a reset condition. Not sure how that works ...

    ? - Parts often use RSTn as VPP, so Vpp is high which is reset-released ?

    Examples:
    Microchip/Atmel have Vpp pins.
    On most of their new devices, Vpp is optional, and used to over-ride a fuse that make RST an IO pin.
    In CPLDs Vpp over-rides the JTAG disable fuse, which releases 4 pins as IO.
    Again, here current specs are modest, it is more a high threshold pin, than a power supply.

    It is common for parts to not allow Vpp permanently present, as it pushes into the stress region on some.

    Other parts with Vpp shipping today :
    SiLabs CP210x, OTP, older series. Spec: Voltage on VPP with respect to GND during a programming operation VPP >= 5.75V (VIO > 3.3 V)
    The new CP2102N is Flash based, so OTP and Vpp are gone. Much nicer to use, but does not yet cover all CP21xx family

    FTDI FT4222H OTP config, Spec : VPP Supply Voltage 6.5±0.25 V

    If another part that did not need Vpp was available, we would choose that instead. (NUC505 is on the short list)

    However FT4222H does have some nice specs (QuadSPI and fast i2c) that force us to tolerate Vpp, and for most testing we do not need Vpp yet.
  • Hopefully OnSemi have an acceptable solution, because frankly, the alternatives are IMHO intolerable. This and the requirement for external Flash will severely limit P2's markets.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • jmgjmg Posts: 10,206
    edited June 24 Vote Up0Vote Down
    Cluso99 wrote: »
    Hopefully OnSemi have an acceptable solution, because frankly, the alternatives are IMHO intolerable. This and the requirement for external Flash will severely limit P2's markets.

    I did find this news item related to XMOS OTP, seems they use Sidense OTP cell, mentioned in OnSemi's list

    http://www.eetimes.com/document.asp?doc_id=1249417

    & this from March 2017 Multi-Time Programming using Sidense 1T-NVM

    mentions using multi-pass OTP as MTP (or FTP, Few Times Programmable), and says ..

    "The bits are physically encoded by irreversibly breaking down the gate oxide with tiny conductive holes. "

    "Field programmability : Multi-time programming of all or part of an embedded memory should easily be done “in the field” without special equipment, either during chip development or when the silicon is already in the final system. This can be done using an integrated charge pump with the OTP, eliminating the need for an external voltage source and an extra power supply pad on the chip."


    This could allow Parallax to include an OscCal byte, for example, and Unique ID serial numbers...
  • YanomaniYanomani Posts: 371
    edited June 24 Vote Up0Vote Down
    jmg wrote: »
    #1 is not much of a choice :(, #2 sounds ideal, #3 rather like #1, prunes-off whole market areas :( , and #4 is tolerable, if #2 proves impossible.
    The fuses can then pull into one area, close to Vpp ? which makes family support easier than spread around ring.

    Hi jmg

    Your suggestion to put all the fuses into a single area, closer to any Vpp pin sounds very good, because, if there are 256 fuses, for example, eight consecutive pins and the their surrounding Vios could be used to concentrate all the signals and current paths needed for fuse programming purposes.

    If this could be restricted to a group of pins, whose I/Os where not expected to deal with high frequencies, the extra-long connections, needed to route the proggraming signals into some connector or exposed gold-flashed pad area, would not severely affect the signal integrity that any other device connected to the same pins will see, at the final product.

    I'ts a pity we can't go way back up to five decades ago, when we use to have negative-biased diode switches (missing my early organ keyboards harmonic-mixers). :lol:

    It would be good If we could, during programming, left the exposed GND pad floating and use negative-biasing to insulate the programming region, restricting high-current/voltage paths to a minimum die area...

    Henrique
    Diode_Switch.png
    277 x 166 - 870B
  • jmgjmg Posts: 10,206
    Yanomani wrote: »
    Your suggestion to put all the fuses into a single area, closer to any Vpp pin sounds very good, because, if there are 256 fuses, for example, eight consecutive pins and the their surrounding Vios could be used to concentrate all the signals and current paths needed for fuse programming purposes.

    If this could be restricted to a group of pins, whose I/Os where not expected to deal with high frequencies, the extra-long connections, needed to route the proggraming signals into some connector or exposed gold-flashed pad area, would not severely affect the signal integrity that any other device connected to the same pins will see, at the final product.
    ...
    If you use RST as Vpp, there is no need to involve VIO at all.
    The high current metal 'came for free' with VIO, and the Fuses were spread around the die, because that used spare space for the larger Fuse-set transistors.
    Moving these into one area keeps the Vpp metal to a minimum, but would have a impact because the Fuse-set drivers are not 'dropped into gaps' as much, but the plus is they are now freed from IO ring, which allows variant Size P2s.

    I would expect only one fuse is 'set' at a time.

    Parallax might like to consider one or more GND pins (not just the TAB) if they want to use standard sockets during factory testing ?

Sign In or Register to comment.