I'll start with a quick synposis of what went wrong. There's WAY more detail below! 1: The 'strength' of the on-chip pullup resistors was insufficient to achieve a truly solid '1' on my input pins
2: With the proto shield in place, the Due would refuse to correctly reset on power up
Now for the gory details
I completely bypassed all the Arduino IDE and wrote the requisite code to totally control all aspects of the SAM. (That, in itself is rather a long story best left for some other time... LOL)
1: I'm using the Due in an automotive environment with 4 * on/off switch inputs, 1 * analog (simple pot) input and 5 * digital outputs. In order to avoid 'letting out the smoke' if some idiot (that'd be ME) accidentally connected an input to the car battery, I included some voltage clamps on the input pins. While I've seen designs where inputs are clamped to the CPU supply rail, I tend to dislike this method since it CAN easily cause the supply rail to overshoot to abs max value on the datasheet. Therefore, I individually clamped each input pin to ground with a separate 3v3 zener (and series resistor) on each input pin. The pot input is a simple voltage divider. One side to ground, the other side to supply and the wiper is the analog input. Being a paranoid person, I zener clamped both the wiper input and the supply output to the pot. I can connect the car battery to ANY of the input(s) without letting out the magic smoke! The inputs switches simply switch to ground, so there is a need for a pull up resistor and I had thought that the internal (100k nominal) pull up resistors would do the job, but they couldn't quite make it. (It seems that the 'reverse leakage' through the zener diode input voltage clamps was enough to pull down the signal so much that it was, at best, unreliable). Put simply, the zener leakage was pulling the voltage at the CPU pin down to a point very near the minimum on the 0.7*Vcc minimum on the datasheet. Simply adding a separate 10k pull up resistor to each input gave me a nice strong signal. 2: The second issue was that the Due simply refused to power up properly. It worked fine as a standalone Due, but as soon as I connected the shield, it would stubbornly refuse to reset much of the time. (However, the reset button would ALWAYS work to get things running). I took a quick look at the reset components on the Due schematics in conjunction with the datasheet... The MASTER-RESET signal (which is connected directly to NRSTB on the SAM) is tied to 3v3 via C20 which is a 10nF cap and is switched to ground by the reset switch. Within the SAM there's a pull-up resistor (nominal 15k) on the NRSTB pin. The SAM processor is asynchronously reset whenever it detects a '0' on NRSTB, so I went through the logic of a truly 'cold' power up. Prior to applying power, C20 would be fully discharged.. As soon as the 3v3 rail was powered, both plates of C20 would jump to 3v3. One plate is directly tied to the 3v3 rail, and the other to the NRSTB pin with its 15k pull up. In real terms, it doesn't DO too much at all. (OK, that's not 100% accurate, but I trust y'all get my point). In order to get a solid RESET into the chip, I threw a 10uF capacitor with 1k resistor in series from the MASTER-RESET signal to ground. This HUGE capacitance (compared to C20) serves to hold the MASTER-RESET signal low until the 10uF cap charges up via the pull up resistor associated with the NRSTB pin. (The 1k resistor is simply to limit current to an 'acceptable' level when the 3v3 supply rail falls to zero at switch off).
The outputs are all quite 'safe' and didn't require the same protection. One is simply a local output to an LED and, since it's confined into the same box, I don't see much chance of the village idiot (aka ME) hitting it with the car battery. The other four outputs are also terminated within the box to opto-couplers that are used to 'drive' relays, so I'm pretty confident. If the optocoupler dies AND the relay somehow 'arcs over' from the outputs to the coil, I suspect it'll be caused by a BIGGER idiot than me incorrectly hooking up the ignition coil secondaries and that would require some SERIOUSLY long spark plug leads! LOL
I must say that I REALLY LIKE the Arduino Due platform - especially the ARM processor it contains! With my next 'project', I hope to tie in to the CAN bus on the (aftermarket) ECU in the car. That should be fun!!! (If I have any hair left by the time I'm done with that one I'll be surprised!)