nRF51 target behaving differently from DK

[Bret Foreman]

I've got a project that works perfectly on the PCA10028 DK. But the behavior is quite different when downloaded to my nRF51822 production target. My target is connected to the DK via the "debug out" connector and I can see it in nRFgo and download the S110 SD to it.

When I download my application, the same hex that works on the DK won't debug on the target. I can set a breakpoint at the start of the main and get there, but the debugger then gives the following set of errors when I try to step through the code:

**JLink Warning: CPU could not be halted
***JLink Error: Can not read register 15 (R15) while CPU is running
***JLink Error: Can not read register 16 (XPSR) while CPU is running
***JLink Error: Can not read register 0 (R0) while CPU is running
***JLink Error: Can not read register 1 (R1) while CPU is running
***JLink Error: Can not read register 2 (R2) while CPU is running
***JLink Error: Can not read register 3 (R3) while CPU is running
***JLink Error: Can not read register 4 (R4) while CPU is running
***JLink Error: Can not read register 5 (R5) while CPU is running
***JLink Error: Can not read register 6 (R6) while CPU is running
***JLink Error: Can not read register 7 (R7) while CPU is running
***JLink Error: Can not read register 8 (R8) while CPU is running
***JLink Error: Can not read register 9 (R9) while CPU is running
***JLink Error: Can not read register 10 (R10) while CPU is running
***JLink Error: Can not read register 11 (R11) while CPU is running
***JLink Error: Can not read register 12 (R12) while CPU is running
***JLink Error: Can not read register 13 (R13) while CPU is running
***JLink Error: Can not read register 14 (R14) while CPU is running
***JLink Error: Can not read register 15 (R15) while CPU is running
***JLink Error: Can not read register 16 (XPSR) while CPU is running
***JLink Error: Can not read register 17 (MSP) while CPU is running
***JLink Error: Can not read register 18 (PSP) while CPU is running
***JLink Error: Can not read register 20 (CFBP) while CPU is running

In addition to this, I'm using the Segger RTT printf function. That also works perfectly on the DK but is very intermittent on the target through the "debug out" connector - I get some printed lines and not others.

And the reason I'm trying to debug is that the app running on the target keeps connecting and disconnecting to my Central. I'm guessing the app running on my target is rebooting, but it's impossible to tell because I can't debug or get printfs to work. On the DK the same app works perfectly.

Any ideas?

[Vidar Berg]

What chip variant of the nRF51822 are you using (chip overview)?

I'm not sure what could be causing this behavior you describe, but you can try to change the LF clock source to use the internal RC if you haven't already (set SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_4000MS_CALIBRATION) in stack init). Another thing you can try is to load the blinky example without the softdevice and see if you are able to debug the chip then in order to narrow down the issue.

EDIT 11.19

It's starting to sound more like a HW issue, maybe antenna or HFCLK. Please try with a clean copy of one of the ble examples in SDK (e.g., ble_app_hrs) and change the LF clock source to RC. Then see if you are able to connect to it using nRFToolbox on ios/android.

EDIT 11.20

There's is no difference between nRF51822 and the nRF51422 besides that you can use the ANT stacks with the latter. In other words, same FW should work on both targets.

One clue is that debugging isn't working. Please try to power the you custom board from your your DK kit given that it's doable and you haven't tried that already. Were you able to debug the ble_app_hrs example?

Also, you mentioned earlier that RTT didn't work very well through the Debug out header. Tried to reproduce it here by using the DK kit to program an ext. kit with the ble_app_hrs example implemented with RTT logging, but it worked as excepted. Attached the .hex below if you want to try it.

Heart rate example with RTT logging:

nrf51422_xxac_s110.hex

[Bret Foreman]

According to nRFgo, it's the nRF51822CFACA00. I just tried both blinky examples, with S110 and without and they both debug fine on the target. I'm already using the internal RC timer on both the DK and my target because my target does not have an external 32KHz crystal.

My next step is to use a second DK in place of my target, wiring the the debug out of the first DK to the debug in of the second. This will reveal if I'm really dealing with some sort of Segger or Keil problem rather than something with my target.

[Bret Foreman]

The second DK on the debug out of the first DK worked properly with the debugger and also with the RTT printf. It also connected with my Central and ran correctly. So the issue is with my target.

Since I can't debug to it and I can't printf from it, I'm completely stopped. To recap - the same hex works perfectly on a DK and misbehaves badly on my target, including not being able to debug or printf and not being able to connect to my central.

I'm going to open a support ticket now.

[Bret Foreman]

It turns out that my diagnostic printfs were just not getting flushed before the nRF51 crashed. I added a spin-wait after the printf and now I can trace through the code with printfs.

The problem is inside ble_advertising_start(BLE_ADV_MODE_FAST). On the DK, this works fine. On my target, it never returns. One key difference between the DK and my target is the presence of an external 32KHz clock on the DK. I wonder if the advertising module is trying to use the external clock. I'm initializing the clock for the SD like this:

SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_1000MS_CALIBRATION, NULL)

But maybe the advertising module is ignoring this setting? This would explain the failure of the debugger too - some piece of code is waiting for an external clock that never a arrives so the debug can't take control.

[Bret Foreman]

Is there a separate setting to control which clock the advertising module uses?