• State Verified Answer
  • Replies 13 replies
  • Subscribers 73 subscribers
  • Views 6287 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 110305
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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?

  • 0 in reply to Vidar Berg

    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.

  • 0 in reply to Vidar Berg

    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.

  • 0 in reply to Vidar Berg

    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.

  • 0 in reply to Vidar Berg

    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.

  • 0 in reply to Vidar Berg

    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.

Related
Terms of service