said by Stewart:I was under the impression that the jumper reset was equivalent to the normal power-up reset, but your theory implies that this is not the case. Do you know what sort of additional initializations are performed? Have you been able to recover from situations where power cycling did not help?
The PAP2 uses a tiny 5 pin "reset controller" chip, located on the bottom side of the board. This chip has, besides power and ground pins, an input for an external reset (that goes to the reset switch, pull-up resistor, and the diode-capacitor circuit that asserts the reset input on initial power-up), a reset output that feeds the processor, ethernet controller and SLIC chips, and a 5th pin, which is an input that the processor writes to periodically to keep the reset controller's watchdog function from triggering a reset pulse on its output.
The PAP2's processor has a status register that identifies the cause of the last reboot. It can tell whether it was a cold (power-on) reboot (as a result of it's reset input pin having been asserted), or a warm (soft) reboot (there is a register that can be written to to cause a software reboot). On boot-up, the PAP2's code looks at this register, and depending on whether it's on a cold or warm boot, it will do or skip certain initializations (in order to speed up the boot up, if triggered by software).
With certain critical errors, it will deliberately cause a watchdog triggered reboot by ceasing updates to the reset controller's watchdog. A watchdog reset looks identical to a power-on reset, but by writing 'magic' words into a specific location in DRAM, and looking for those on boot-up, the PAP2 can distinguish between a power-on boot-up and various deliberately caused reboots via the watchdog and the soft reboot mechanism.
However, it has no way of reading the current state of the reset switch, as this is only visible to the reset controller, and furthermore, the processor does not provide any way to read the real time state of its reset pin, so there's no way for the PAP2 to do as many other devices do, that reset their configurations depending on whether one keeps a reset button depressed for an extended period of time.
If the capacitor is bad and open circuited, the reset controller will not produce a reset pulse on its output on power-up, and therefore none of the components that rely on this to initialize their states upon power-up will start up correctly, and may instead end up in hopelessly locked-up states. If the PAP2's processor starts up at all, it will likely boot up as if from a warm boot, and therefore skip a number of initialization steps, so some components (including perhaps the ethernet controller) may not be initialized correctly.
When shorting the reset pins, all components of the PAP2 are normally properly reset just like from a normal power up, which might explain why this works for the OP. However, when the PAP2 goes into a critical failure state reflected by a solid red power LED, it will not update the reset controller's watchdog, and will thus be automatically reset and rebooted after a delay of some 5 to 6 seconds. Since the watchdog reset looks exactly like a power-on reset to the processor (and the other main chips on board), the PAP2 should boot up normally after being hit by the first watchdog reset after the initial power-on boot.
If I've interpreted the OP's description right, it seems that the watchdog isn't kicking in, so it would appear that there may be more to it than just a bad power-on reset capacitor (or possibly the diode labeled D251, located just to the left of the capacitor, which may have gone poof, instead of or in addition to the capacitor), with a likely cause being the reset controller malfunctioning.
That's not to say that you haven't hit the nail on its head with your diagnosis of the capacitor as the culprit, but I would expect the watchdog to correct the situation the first time it kicks in after each initial boot-up.
