nRF52 BLE app hangs on ble_stack_init()

[spaniel]

I am experiencing an issue where the program hangs on one board, but not another.  I am able to program the Evaluation board (EV BT832AF) ok and run everything, but when I program a production board  (BT832AF) The program hangs.  (I am able to program and step through the code, so I'm pretty sure all the connections are good on both boards) I am programming them the exact same way, with the exact same files.  Just using VDD, GND, SWDIO and SWCLK wires connected to an nRF52-DK development board.    Are there any differences between the production BT832AF and the BT832AF included on the Development board that could cause this?

Here's a bit more detail on where it's hanging:   There's no error code being generated, it just goes into an infinite loop inside the ble_stack_init() function.  More specifically, right after the call "SVCALL(SD_SOFTDEVICE_ENABLE, uint32_t, sd_softdevice_enable(nrf_clock_lf_cfg_t const * p_clock_lf_cfg, nrf_fault_handler_t fault_handler));"

Some research has lead me to believe that it's an issue with the NO_VTOR_CONFIG missing from preprocessor definitions, as the behavior is exactly what I'm expecting.  see this question on forum: https://devzone.nordicsemi.com/f/nordic-q-a/14360/ble_app_template-always-end-at-svc_handler/54827#54827      But I've added that, rebuilt and still have the issue.   

Any guidance would be much appreciated!

Versions & Hardware being used

nRF52 SDK  nRF5_SDK_15.2.0_9412b96

Project being used from SDK:  nRF5_SDK_15.2.0_9412b96\examples\ble_peripheral\ble_app_uart\pca10040e\s112\ses

Segger Studio Release 4.12  Build 2018112601.37855

Windows Environment

Boards, Production Board ( BT832AF ) and Evaluation board (EV BT832AF).  being programmed through the nRF52 DK.

Programming output

Preparing target for download
Executing script TargetInterface.resetAndStop()
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Downloading ‘s112_nrf52_6.1.0_softdevice.hex’ to J-Link
Programming 2.3 KB of addresses 00000000 — 00000967
Programming 94.8 KB of addresses 00001000 — 00018b93
J-Link: Flash download: Bank 0 @ 0x00000000: Skipped. Contents already match
Download successful
Downloading ‘ble_app_uart_pca10040e_s112.elf’ to J-Link
Programming 26.5 KB of addresses 00019000 — 0001fa2f
Programming 0.0 KB of addresses 0001fa30 — 0001fa87
J-Link: Flash download: Bank 0 @ 0x00000000: Skipped. Contents already match
Download successful

[Nguyen Hoan Hoang]

I think the 32KHz crystal is missing on your production board.

[spaniel]

thanks for the quick response.  That does seem to be the root cause.  To confirm that the crystal is the problem, I removed the LF crystal from the circuit on the Development board and was able to reproduce the problem.

I've done some interneting and found that the clock source can be changed to RC instead of XTAL for applications where there is no LF crystal.  Here's a resource that seemed to lay it out fairly well:  https://rigado.zendesk.com/hc/en-us/articles/225674668-Example-files-will-not-run-on-my-hardware-LF-Clock-Source-Selection

I followed those steps and rebuilt, but still having the same issue.  Am I missing another step?

thanks!

[Nguyen Hoan Hoang]

That seems correct for setting the RC.  You'll need to trace it out.  There might be some places in your code that may bypass the RC settings.

[spaniel]

I've poked around and found this in nrf_drv_clock.c

#if (CLOCK_CONFIG_LF_SRC == NRF_CLOCK_LFCLK_RC) && !defined(SOFTDEVICE_PRESENT)
#define CALIBRATION_SUPPORT 1
#else
#define CALIBRATION_SUPPORT 1 //  ** This was 0, changed it to 1 to force calibration support. **
#endif

Changing this to 1 seems to have gotten everything up and running.  I really don't know what the consequences of this action are fully yet.  The if statement seems to suggest that if a softdevice is present (which it is) then I shouldn't use calibration support....  I really don't know why this worked, which is scary!

[Einar Thorsrud]

Hi,

The SoftDevice Handler library is used by most BLE example in SDK 15.2. Do you use it? If so you have to configure it to use the RC oscillator by setting NRF_SDH_CLOCK_LF_SRC to 0 (NRF_CLOCK_LF_SRC_RC) in the projects sdk_config.h. You should not have to do any other modifications.