nRF51 target behaving differently from DK

RE: nRF51 target behaving differently from DK

Bret Foreman — Mon, 23 Nov 2015 22:27:44 GMT

Found the problem. This was a code dependent power supply glitch. No problem using the example code but my test code was creating current spikes. I had only examined the power supply integrity with example code and it was solid. But my application causes bigger spikes. I added a BAC (big-ass-cap) on the power supply pins and all is well (so far).

RE: nRF51 target behaving differently from DK

Bret Foreman — Mon, 23 Nov 2015 17:59:20 GMT

I tried using a DK in place of my target and all my code and the example code runs perfectly. The debugger also works fine. RTT is still flaky so you should be able to reproduce that.

I don't think trying to isolate hardware versus software is going to be productive. The example code works fine on my target. My code works fine on the DK. It's a hardware/software interaction and it's particular to my use of the hardware to test throughput with a custom Characteristic. I tried using the same technique with the hr monitor code where I send notifies as fast as I can and it works fine on the DK and the target. As soon as I drop in a custom characteristic it breaks (on my target, not the DK).

RE: nRF51 target behaving differently from DK

Bret Foreman — Thu, 19 Nov 2015 23:02:26 GMT

I'm able to single step into the main for a number of init calls, then it hangs on one of them. The init that hangs varies randomly as far as I can tell. I can also move a breakpoint down the list of inits and hit "run" and see if it reaches a given spot. That result is also completely random. I always have a breakpoint in the app error handler and it's never hit it. I'm seeing the code hang at the definition of automatic variables, which is characteristic of stack corruption.

Since all this weird behavior is completely in the target and never in the DK, is there any difference between the nRF51822 (my target) and the nRF51422 that might account for this?

RE: nRF51 target behaving differently from DK

Vidar Berg — Thu, 19 Nov 2015 20:24:04 GMT

Thanks for testing, think we can rule out HW issues then. My assumption was based on the fact that you was not able to keep the link on your custom board while it worked with the DK kit. However, later you mention that the advertising function is asserting, which is unexpected because the same parameters should've been passed regardless of target.

Were you able to single step at all after entering main, or is it a after a particular function where you are unable to halt? You can also try to place a breakpoint in the app error handler in app_error.c and see if it is reached (set DEBUG define to keep it from resetting), and read out the parameters passed to this one if it did.

Regarding your comments on the clock source; the clock source is only set once when you call SOFTDEVICE_HANDLER_INIT, and it will not get passed this if using a non-existent source (i.e., crystal), but you will still be able to halt the core as it's only in wait loop withing the SD stack. The application will not overwrite this configuration.

RE: nRF51 target behaving differently from DK

Bret Foreman — Thu, 19 Nov 2015 19:34:45 GMT

I really wish the debugger would work on my target. Debugging with printfs is very difficult. I'm still getting the same errors as in the original post when trying to use the debugger.

RE: nRF51 target behaving differently from DK

Bret Foreman — Thu, 19 Nov 2015 17:12:12 GMT

The target advertises and connects fine (to the Android MCP) using the heart rate monitor example so I don't think it's a hardware problem. My application (the one that doesn't work on the target) has a custom characteristic and was derived from the UART example in the BLE Central tutorial.

RE: nRF51 target behaving differently from DK

Bret Foreman — Thu, 19 Nov 2015 01:14:20 GMT

OK, I cut loose the external 32KHz crystal on one of my DKs and it still works perfectly. So it's some other difference between my target and the DK. I'm wrapping up for today and pick it up again tomorrow, including trying any ideas that might be proposed in this thread.

RE: nRF51 target behaving differently from DK

Bret Foreman — Thu, 19 Nov 2015 00:26:58 GMT

I'm continuing to try experiments. The latest thing was to switch from fast to slow advertising. In that case ble_advertising_start(BLE_ADV_MODE_SLOW) returned with an error code 7, invalid parameter. I'm going to look around for an example of slow advertising and try to figure out what parameter it's hating.

The next big step will be to cut the 32KHz clock on a DK and see if I can reproduce the problem that way.

RE: nRF51 target behaving differently from DK

Bret Foreman — Wed, 18 Nov 2015 22:51:05 GMT

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

RE: nRF51 target behaving differently from DK

Bret Foreman — Wed, 18 Nov 2015 22:50:08 GMT

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.

RE: nRF51 target behaving differently from DK

Bret Foreman — Wed, 18 Nov 2015 18:15:26 GMT

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.

RE: nRF51 target behaving differently from DK

Bret Foreman — Wed, 18 Nov 2015 17:52:19 GMT

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.

RE: nRF51 target behaving differently from DK

Vidar Berg — Wed, 18 Nov 2015 09:38:24 GMT

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