• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 69 subscribers
  • Views 3882 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 104149
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Stack trace starting from a hex address?

405nm

Hello,

I'm learning how to use s110 and the debugger. I am porting the hids_keyboard app from the PCA10001 to the PCA10003 (nrf51822 -> nrf51422).

As described in this thread, I am having a hard time figuring out why the program is crashing when it tries to send a keypress. I set a breakpoint, but I'm unsure how to interpret the stack trace - it starts at a hex address that isn't correlated to my human-readable code. Here's a screenshot:

image description

(bigger version here)

I'm new at this, so any help as to how to trace/debug this would be much appreciated!

  • 0

    Well you are in your code, you're in your softdevice assertion handler. There's lots of information in there, the error code, in hex (always look in hex) is 0xDEADBEEF which is a standard marker in the nordic code (it's in the source you compiled). You actually crashed at line 1377 of rem.c, which isn't in your code, it's in the softdevice. If you type 'rem.c' into the search box ^^ up there ^^ you'll see questions about it.

    Anyway what's happened is the softdevice itself has asserted and called you back. And the most likely reason for that is .. you can't debug code which uses the softdevice by single stepping it As soon as you hit a breakpoint in your code, that also stops the softdevice from handling its interrupts, which it absolutely has to do on a timely basis and the next time it starts going again and services an interrupt, it asserts.

    Unfortunately debugging with the softdevice running is hard and frustrating, you need to use other techniques, like printf or outputting data on the UART or tracing (the nordic chip doesn't support tracing but the crossworks studio I use does sampling which can occasionally help). You basically get one only one chance to break and look at your program once the softdevice is up and running, you can't resume, it'll assert.

  • 0 in reply to RK

    Ah, ok. Thats exactly what I needed to know. Will try my usual debugging techniques then, and will prob have to start another thread as I wrap my brain around how this BLE stack works.

    I've been using RKNRFGO 1.0.6 to flash my chip, but it keeps telling me that I need to disable the CDC drivers. I noticed from one of your other posts that they have fixed the CDC driver issue on mac...any chance of an update so I don't have to keep enabling and disabling? :-)

  • 0 in reply to RK

    get the latest jlink software. They repaired the bug already

  • 0 in reply to RK

    405nm - if you have anything after about 4.90 of JLink it'll work just fine without disabling the CDC drivers. I don't remember if I ever got around to putting code in RKNRFGO to try and figure out what the version of JLinkExe is, I don't think I did actually. I believe that as long as there is a device connected and it sees it, the CDC disable warning is supposed to be removed, i.e. you don't see it, but probably if there isn't one connected and it sees the CDC drivers are enabled it assumes (incorrectly) that's the problem and puts the message up. I'll put that on the list for the next time I'm in that code, checking the JLinkExe version and just not even bothering checking CDC at all.

  • 0 in reply to RK

    Ok, it kind of works -- have to connect the debugger before opening RKNRFGO, otherwise it seems to automatically disable the CDC drivers (according to my /dev directory anyway) and the enable button seems to have no effect. Also, when you are back in the code, mind adding PCA10003 support to your eclipse plugin? :-)

Related