Unable to properly initiate softdevice, stuck in a loop forever

[Mitch996]

Hello:

I'm trying to get an example program ble_app_hrs running on my custom board, because earlier last month I couldn't write the cccd descriptor properly and I suspect there is something buggy on the board side, and I'm trying to see if official examples will run on my board properly.

So I'm using the nRF5_SDK_13.1.0_7ca7556 example, and the s140_nrf52840_5.0.0-2.alpha softdevice which comes within the 13.1.0_7ca7556 package.

I can manage to get the program run to softdevice_handler_init, shown in the picture below:

and from this point on, I'm stuck in an ls loop forever, here's the code:

#PART 1
0x00009F3E 2800      CMP           r0,#0x00
0x00009F40 D0FA      BEQ           0x00009F38


#PART 2
0x00009F38 4630      MOV           r0,r6
0x00009F3A F008FC57  BL.W       0x000127EC

#PART 3
0x000127EC 4906      LDR           r1,[pc,#24]  ; @0x00012808
0x000127EE 310C      ADDS          r1,r1,#0x0C//after this, r1 will have value of 0x40000418
0x000127F0 680A      LDR           r2,[r1,#0x00]//the value read from 0x40000418, which is LF STATUS register, is 0x00010001
0x000127F2 03D2      LSLS          r2,r2,#15
0x000127F4 D506      BPL           0x00012804
0x000127F6 6809      LDR           r1,[r1,#0x00]
0x000127F8 F0010103  AND           r1,r1,#0x03
0x000127FC 4281      CMP           r1,r0
0x000127FE D101      BNE           0x00012804

#PART 4
0x00012804 2000      MOVS          r0,#0x00
0x00012806 4770      BX            lr //which goes back to 0x00009F3E, the beginning of this loop.

By reading through this loop, I found something problematic:

A. there is no code which could possibly break out of this loop, is this a hardfault handler of some sort? See a more complete #PART 3 here:

0x000127EC 4906      LDR           r1,[pc,#24]  ; @0x00012808
0x000127EE 310C      ADDS          r1,r1,#0x0C
0x000127F0 680A      LDR           r2,[r1,#0x00]
0x000127F2 03D2      LSLS          r2,r2,#15
0x000127F4 D506      BPL           0x00012804
0x000127F6 6809      LDR           r1,[r1,#0x00]
0x000127F8 F0010103  AND           r1,r1,#0x03
0x000127FC 4281      CMP           r1,r0
0x000127FE D101      BNE           0x00012804
0x00012800 2001      MOVS          r0,#0x01
0x00012802 4770      BX            lr
0x00012804 2000      MOVS          r0,#0x00
0x00012806 4770      BX            lr
0x00012808 040C      LSLS          r4,r1,#16
0x0001280A 4000      ANDS          r0,r0,r0
0x0001280C 49C8      LDR           r1,[pc,#800]  ; @0x00012B30
0x0001280E F8110F21  LDRB          r0,[r1,#0x21]!
0x00012812 7849      LDRB          r1,[r1,#0x01]

My assembly-fu isn't high enough so I could be wrong. Anyway the code looks very much like it tries hard to see if the LF clock was properly configured, which brings up problem B.

B.Unable to change the source of LF clock: as you can see from the above assembly code comment, the value of 0x40000418 is 0x00010001, it means 1. the lf clk is running, 2. the source is xtal 36.768, which is really, really weird because I don't have any external lf crystal mounted and I'm positive that I've set the source to RC, in the code below:

This is all very weird, I want to enable the sd, but couldn't, what should I do next?

Best regards!

[Mitch996]

@RK

And no the assembler doesn't require the source to be RC to exit, it will exit when the clock starts. However you shouldn't be there at all. So your problem is elsewhere.

Thank you for your reply, how do you mean by that?

To run to 0x12800, the r1 & r0 must not equal.

r0 is 0 at that point, r1 is whatever value after the 0x40000418 register masked by 11B, and to be equal with 0, the content of r1 must also be 0, the only content, after being masked by 11B and turns out to be 0 is 0, 0 in 0x40000418 register means the lf clk source is RC.

Edit, "must not equal" should be "must equal". Damn this whole thing is really taking a toll on me.

[Mitch996]

@RK

Are you compiling with the header files for the soft device you are using? A structure mismatch issue would cause this.

I'm not sure what qualifies as "header files for the soft device", all I know is that I'm using all the files under the "component" folder extracted the same sdk .zip file as the softdevice.

I just moved my mouse cursor over to some .h files, yes they are from the same sdk .zip file as the softdevice.

However I agree with your general direction of suspicion.

[RK]

when in the loop - what's the value stored at 0x4000041c

[RK]

and I still don't think why you believe that's an infinite loop because it's not. It starts at 0x9f38 which loads r6 (the desired running clk source) into r0. Then it calls 0x127ec which loads from LFCLKSTAT. It shifts that to get the 'running' bit, if it's running it moves on else it returns zero (false). If it's running it checks the clock source is == r0 ie the desired clock source. If not, it return false (0x12804). If running AND the correct source, it returns 1, true (0x12800) and returns.

then back at 0x9f3e if false was returned it reloads r0 from the (untouched) r6 and does it again, else it drops through and keeps processing.

So that routine does EXACTLY "wait for the clock source in r6 to be running".

what are the register values when you're stepping it? What is r6 @ 0x9f38, what's read from 0x4000418?

[Mitch996]

Hello @RK, regrettably I'm no longer able to produce the same error and everything seems to be fine all of sudden... regarding your question:

when in the loop - what's the value stored at 0x4000041c

I'm no longer able to obtain that value, sorry.

What is r6 @ 0x9f38,

Again, I can't find that out anymore.

what's read from 0x4000418?

If I recall it correctly, the A was 01 which means the source was XTAL, the B was 1, which means it was running. Like I said this is strange because I don't have a external lf xtal, so it shouldn't be running at all.