Custom Board Programs, Cannot Debug, Firmware Doesn't Run

I'm having what I believe is a hardware problem on a custom board with an NRF52832. Unfortunately I cannot share the schematic, but will try to describe the symptoms and will ask some questions that will hopefully help me understand the problem:

As of now I have three custom boards built. For each, when I initially tried to flash firmware on them, everything seemed to flash okay. I'm loading the program in a debug session using Ozone, and it went through the erase, write verify cycle okay, but it would not go to main to start execution. It would list the stack pointer and program counter as pointing at 0xFFFFFFFF instead of a more reasonable address. I will include the console output below. Strangely, after trying to reflash and otherwise inspecting the boards, one of them flashed and began executing the program successfully. Now all three boards appear to flash, but only one will run the firmware and blink the LED and can be debugged in a debug session. Here are some questions that will hopefully help me debug:

1. Does the 32 MHz crystal need to function in order to successfully flash the NRF52832? If the crystal was busted or otherwise unmatched, would I see this behavior where a device seems to flash okay but won't execute code?

2. The SP and PC are being listed as 0xFFFFFFFF when debugging begins. Is this indicative of a particular error? Could this also be a symptom of the crystal not oscillating? How are these values being determined? Does the debugger get these from the NRF when it is (supposed to be) beginning execution? Or is it something the debugger knows on its own from the code being loaded?

3. On the board that works, I can probe one of the 32 MHz crystal pins with a multimeter (I know this will inevitably throw the load capacitance out of whack) and I can see some activity. On the boards that don't work, I see nothing. Shouldn't I see the crystal oscillating at startup regardless of what firmware is loaded on?

4. On these new boards, the revision is QFAAE0, while a previous revision used QFAAE1. Are there any differences between these revisions?

Thank you in advance!

Console output during flash programming in Ozone:

File.Open: completed in 577 ms

Edit.Preference (PREF_SHOW_EXEC_COUNTERS_ASM, 0);

Edit.Preference (PREF_SHOW_EXEC_COUNTERS_SRC, 0);

Debug.Start();

Device "NRF52832_XXAA" selected.

Found SW-DP with ID 0x2BA01477

Found SW-DP with ID 0x2BA01477

Scanning AP map to find all available APs

AP[2]: Stopped AP scan as end of AP map has been reached

AP[0]: AHB-AP (IDR: 0x24770011)

AP[1]: JTAG-AP (IDR: 0x02880000)

Iterating through AP map to find AHB-AP to use

AP[0]: Core found

AP[0]: AHB-AP ROM base: 0xE00FF000

CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)

Found Cortex-M4 r0p1, Little endian.

FPUnit: 6 code (BP) slots and 2 literal slots

CoreSight components:

ROMTbl[0] @ E00FF000

ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7

ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT

ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB

ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM

ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU

ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM

J-Link: connected to target device

Exec.Reset();

Reset: Halt core after reset via DEMCR.VC_CORERESET.

Reset: Reset device via AIRCR.SYSRESETREQ.

Resetting Program.

Target.SetReg ("SP", 0xFFFFFFFF);

Target.SetReg ("PC", 0xFFFFFFFF);

J-Link: Flash download: Bank 0 @ 0x00000000: 1 range affected (204800 bytes)

J-Link: Flash download: Total time needed: 3.649s (Prepare: 0.008s, Compare: 0.012s, Erase: 0.104s, Program: 3.516s, Verify: 0.004s, Restore: 0.001s)

Initializing PC and SP.

Target.SetReg ("SP", 0xFFFFFFFF);

Target.SetReg ("PC", 0xFFFFFFFF);