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);