Stack trace starting from a hex address?

RE: Stack trace starting from a hex address?

405nm — Fri, 24 Oct 2014 21:59:43 GMT

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? :-)

RE: Stack trace starting from a hex address?

RK — Mon, 20 Oct 2014 08:55:16 GMT

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.

RE: Stack trace starting from a hex address?

Nguyen Hoan Hoang — Mon, 20 Oct 2014 08:39:10 GMT

get the latest jlink software. They repaired the bug already

RE: Stack trace starting from a hex address?

405nm — Mon, 20 Oct 2014 04:16:43 GMT

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? :-)

RE: Stack trace starting from a hex address?

RK — Sun, 19 Oct 2014 01:38:43 GMT

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.