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);
Device "NRF52832_XXAA" selected.
Found SW-DP with ID 0x2BA01477
Scanning AP map to find all available APs
AP: Stopped AP scan as end of AP map has been reached
AP: AHB-AP (IDR: 0x24770011)
AP: JTAG-AP (IDR: 0x02880000)
Iterating through AP map to find AHB-AP to use
AP: Core found
AP: 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
ROMTbl @ E00FF000
ROMTbl: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
ROMTbl: E0001000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl: E0002000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl: E0000000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
ROMTbl: E0041000, CID: B105900D, PID: 000BB925 ETM
J-Link: connected to target device
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
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.
1) Nope, 32MHz is not require to flash and executing simple code. It is required if you use the radio
2) Something is not right with your firmware. Either you did not map the memory correctly or your firmware requires the softdevice.
3) No, the 32MHz is by default off.
Have you tested your firmware on a known reference working board such as the DK ?
Thank you for the quick response!
The firmware does load and run on a different custom dev board. Also, of the three new custom boards, one of them did start running and executing the firmware, so it seems unlikely to me to be a problem with the firmware itself. I have no idea why the one board miraculously started working after initially not working, and why the other two continue to not function. I was leaning toward it being something wrong with the crystal, but since you say it is possible to execute code without it, that seems less likely.
It could be soldering issue too. Try reflow it a bit.
Can you read out the flash of one working device and compare it to a non-working device?
This was a great suggestion, and Nguyen's suggestion #2 seems to be correct. When flashing through Ozone, the softdevice/MBR wasn't being loaded properly onto the device. The board that started working had been flashed with an old project using a different method from Ozone, and this was retained in flash when re-flashing using Ozone. The boards are working now.
Thank you both for your help! Nordic support is the best.