Problem using monitor mode debugging with the nrf connect sdk

[Poorp]

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?

[Øyvind]

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

[Poorp]

Sounds great, thanks!

[Øyvind]

Hey Poorp, 

I'm afraid that I don't have an answer to you regarding MMD and NCS. A developer suggest using semihosting  which was added in Zephyr 2.3.0 as far as I can see. For more information or help on using semihost, please see Zephyr's "Ask for help" for channels to ask for help.

I'm sorry for the inconvenience. 

Kind regards,
Øyvind

[Poorp]

Hi Øyvind

That's sad to hear.

Am I correct in understanding then that there is no official way to use debugging when developing with the NRF Connect SDK?

What do you mean with using semihosting? It's my understanding that semihosting is used primarily for I/O between host and MCU, e.g reading and writing data to a file. It does this by utilizing breakpoints. If that is correct then that would mean that it will experience the same problem as I do when I try to use breakpoints. That is, as soon as it hits a breakpoint (which it uses to send data back and forth to the host) then the softdevice will stop running at everything will crash.

It also wouldn't solve my issue as I'm trying to use breakpoints, not I/O.

Best Regards

Porp

[Øyvind]

Hi Porp, 

You can debug with breakpoints using SES or GDB. However, I know that there have been some issues with debugging using SES on Cortex M33 devices i.e. nRF9160 and nRF5340 due to the complexity. Therefore GDB has been used a lot. 

See this blog post from the same author on MMD.

Kind regards,
Øyvind

[Poorp]

Sorry I was a bit unclear. I meant no way to use debugging with more than one breakpoint. Which was the problem I'm trying to solve with MMD. The underlying problem being that the softdevice gets halted with the rest of the code whenever you hit a breakpoint.

See
https://devzone.nordicsemi.com/f/nordic-q-a/17/how-can-i-debug-a-softdevice-application/70#70

and your post from 7 years ago (thanks for being helpful for 7 years and counting!)

devzone.nordicsemi.com/.../2495

Best Regards
Porp

[Øyvind]

Hi Porp, 

I'm sorry, the only solution, in your case, I found/was suggested is to let the SW fail, read the failing address and find what is failing, reset the device and repeat. 

There is currently no other solution.

Kind regards,
Øyvind