This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Problem using monitor mode debugging with the nrf connect sdk

Hello

I'm having some issues setting up monitor mode debugging  with the nrf connect sdk v1.4.99.

I've roughly followed the steps outlined in this guide, the exact steps I have taken are

1) Included the three monitor mode files in our project (JLINK_MONITOR.c, JLINK_MONITOR.h, JLINK_MONITOR_ISR_SES.s)

Sidenote: I have contacted segger support in order to get a hold of the JLINK_MONITOR_ISR_GCC.s file as instructed in the MMD link above, but am still awaiting a response. I am uncertain what if any difference there is between them and whether the GCC file is the correct one to use.

2) Added the following line to my main function "NVIC_SetPriority(DebugMonitor_IRQn, 7UL);" (I have also tried with lower priorities like e.g 16)

3) Ran the below gdb commands, I choose 0x26000 as I'm using a v17 softdevice and that's what seems to be used in the example ld files for that device.

mon exec SetMonModeDebug=1
mon exec SetMonModeVTableAddr=0x26000

Despite this whenever I stop at a breakpoint I still get a crash.


If I use the nordic softdevice link layer (BT_LL_SOFTDEVICE) the crash message is:

[00:00:03.690,948] <err> mpsl_init: MPSL ASSERT: 112, 2147                                
[00:00:03.690,979] <err> os: ***** HARD FAULT *****                                       
[00:00:03.690,979] <err> os:   Fault escalation (see below)                               
[00:00:03.691,009] <err> os: r0/a1:  0x00000003  r1/a2:  0x20002778  r2/a3:  0x20002778   
[00:00:03.691,009] <err> os: r3/a4:  0x00000000 r12/ip:  0x4000b000 r14/lr:  0x00029759   
[00:00:03.691,009] <err> os:  xpsr:  0x61000018                                           
[00:00:03.691,009] <err> os: Faulting instruction address (r15/pc): 0x00025fdc            
[00:00:03.691,040] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0             
[00:00:03.691,040] <err> os: Fault during interrupt handling                              
                                                                                          
[00:00:03.691,040] <err> os: Current thread: 0x20002778 (unknown)                         
[00:00:03.964,294] <err> fatal_error: Resetting system   

If I instead use the zephyr software link layer (BT_LL_SW_SPLIT) I get the error message

ASSERTION FAIL [(ret == 0) || (ret == 2)] @ /home/<censored username>/.local/opt/ncs/zephyr/subsys/bluetooth/controller/ll_sw/ull_adv.c:1641
[00:00:13.674,804] <err> os: r0/a1:  0x00000003  r1/a2:  0x200011b8  r2/a3:  0x200011b8
[00:00:13.674,835] <err> os: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x00017fcb
[00:00:13.674,835] <err> os:  xpsr:  0x6100001b
[00:00:13.674,835] <err> os: Faulting instruction address (r15/pc): 0x00017fd6
[00:00:13.674,835] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:13.674,835] <err> os: Fault during interrupt handling

[00:00:13.674,865] <err> os: Current thread: 0x200011b8 (unknown)
[00:00:13.922,454] <err> fatal_error: Resetting system

Looking in that ull_adv.c the offending line is:

		LL_ASSERT((ret == TICKER_STATUS_SUCCESS) ||
			  (ret == TICKER_STATUS_BUSY));

I'm guessing that means that the softdevice, and therefor the ticker, still gets stopped when ever I hit a breakpoint. Is that correct?

Any ideas about what I am doing wrong?

Are there any tutorials about how to implement monitor mode debugging with the nrf connect sdk and/or zephyr?

Parents
  • Hello, 

    There is unfortunately not much information available of the usage of MMD with nRF Connect SDK. I will need to investigate internally. Will get back to you within Monday or Tuesday.

    Kind regards,
    Øyvind

  • I recall making a little bit of headway with MMD under the NCS toolkit (v120 I believe);

    From re-collection I had to amend vector_table.S to point to the SES DebugMon Handler and the /zephyr/arc/arm/../exc.h ---> _EXC_FAULT_PRIO value to be below the default priority.

    I recall being able to manage limited code stepping in debug mode whilst keeping the mesh up and sending data packets but recall zephyr not being entirely happy. I mothballed things for a while to pursue other projects but let me know if you're interested in following up further.

Reply
  • I recall making a little bit of headway with MMD under the NCS toolkit (v120 I believe);

    From re-collection I had to amend vector_table.S to point to the SES DebugMon Handler and the /zephyr/arc/arm/../exc.h ---> _EXC_FAULT_PRIO value to be below the default priority.

    I recall being able to manage limited code stepping in debug mode whilst keeping the mesh up and sending data packets but recall zephyr not being entirely happy. I mothballed things for a while to pursue other projects but let me know if you're interested in following up further.

Children
No Data
Related