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:

(bigger version here)

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

[RK]

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.

[Nguyen Hoan Hoang]

get the latest jlink software. They repaired the bug already