• State Verified Answer
  • Replies 13 replies
  • Subscribers 73 subscribers
  • Views 6293 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 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?

  • 0 in reply to Vidar Berg

    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).

  • 0

    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).

Related
Terms of service