Reset

Having already tired of having to unplug the USB cable to reset the board, I've figured out how to connect a reset button (through the JTAG port).  It should have been obvious, but I had to figure it out anyway.

I'm working on my own custom firmware, which means I can handle reset however I want.  Well, sort of.  I want to have the reset line handled in hardware, and that works, except for one thing.  I'm booting via SAM-BA/sam7, which does not drop the USB pullup because it cannot know which pin it is on or how it is connected (the result being that the host doesn't know that the device has reset, so it's a bit confused).  So what I've done is to catch the reset pin in an interrupt (once I'm running my code) and drop the USB pullup there.  And that works.  Unfortunately, that does me no good if my firmware crashes with interrupts disabled.  So what I really want is to ditch the interrupt thing and go back to doing it in hardware.

All that is to get to this:  I want the reset line (NRST) to also drop the USB pullup.  As such, I've got a hardware modification in mind.  I just want to have a sanity check before performing it, as all such mods have an element of risk.  I have reviewed the schematic online (and the board in hand), and I think I can do what I need by connecting NRST through a resistor to the junction of R20 and the base of Q1.  Assuming that is correct, it just becomes a matter of sizing that resistor.  It has to be small enough to pull the base below 0.6V (typical Vbe) through the 47K of R20, so that means it can be no bigger than 8.54K.  But the hardware should tolerate other firmware (including the standard Make Controller firmware) or improper operation without harm, so it should be bigger than, say, 3.3K, which would pull 1ma through PA11 should it be driven when NRST is driven in the opposite direction.  4.7K is a standard value nicely within that range.

For that scheme to actually work, my firmware has to enable the pullup by disabling the PA11 output driver (letting R20 do the lifting), rather than by driving PA11 high (which would prevent NRST from being able to pull the base down).

So, am I on the right track?  I'd rather find out otherwise now, rather than by risking damage to my hardware.  Hence the sanity check.  This mod involves no cutting of traces, but it does involve tack-soldering to two vias (or component legs) which I have already located on the controller board.

This is only really an issue because I'm booting through sam7, which I realize is not how most people do it.  Once my firmware is to the point where I can boot directly into it, I can take care of dropping and raising the USB pullup myself in precisely the way that sam7 does not.  But I still will probably have to return to this mode periodically for testing new firmware prior to flashing it.  I want to reduce wear on the FLASH and the NVM bits (which have a stated endurance of only 100 erase/write cycles) by testing code in RAM.

Hi, David;

Thank you for looking at my proposal.  I am pleased that you liked how I thought it out.  I put way too much thought into these things, and it's nice to know it's appreciated.

I think that case (PA11 driven high when NRST gets driven low) is handled pretty well by the proposal, assuming it is ok if the USB pullup doesn't get disabled in that case.  PA11 can drive 8ma indefinitely.  In terms of your question, the base voltage would be pretty much the same voltage as PA11 in that situation.  The port pin is much stronger than the 4.7K resistor.

If you wanted to, you could leave the SODR part the way it is (or not) and initialize the port pin to use MD mode (PIO_MDER).  That would basically make it open-drain.  It would offer marginally more protection against anybody accidentally setting the pin high.

However...

You bring to mind an interesting point about port pins having their pullups enabled upon reset (the state that you allude to in SAM-BA).  A fact which I had inconveniently forgotten about.

I need to take that into account in my math.  The port pin pullups may be too strong for this to work.  I, too, thought the pullups were weak, but judging from the figures given for I[PULLUP] in the datasheet, it is not encouraging.  600uA doesn't sound like much until you consider it's 0.6ma.  My 4.7K resistor could never get that down to 0.6V.  This appears to be a showstopper.

There seems to be no way to get around having to make a more extensive hardware modification, which would surely require cutting traces.

So far, the best solution I've come up with is to replace Q1 with something like this: http://www.fairchildsemi.com/pf/NC/NC7S08.html
That particular part is rated for a maximum of 12.5ma, so it ought to be able to drive 2.2ma (3.3v through 1.5K).  Q1 could be retained as a voltage-follower, but the chip ought to be able to handle it.  Reworking that onto the existing board would be a royal pain, though.  As would sourcing small quantities of the part.

Short of that, it might work to put a diode between PA11 and R20 and another between NRST and R20.  Because of the diode voltage drop (and the fact that CMOS low levels aren't necessarily 0V), though, the pullup might not get fully shut off.  I suppose Schottky diodes are an option.  The few tenths of a volt difference could mean the difference between the pullup being fully off and being pulled up to 0.7V.

Either of those two modifications wouldn't require any firmware changes.  Of course, the one you mentioned wouldn't hurt either of them, either.