Kernel Panic in NUS app when porting to custom PCB

[PaulJ]

I developed a custom application on the 52840DK and have now moved this over to a custom PCB of my own design. I can compile OK and can start a debug session from "main" but part way through the code, I get a fatal "Kernel Panic" error. I was able to track it down to a interrupt from Timer 0 which I understand is used by the MPSL system. The interrupt takes the program counter to a function in "mpsl_init.c" :

ISR_DIRECT_DECLARE(mpsl_timer0_isr_wrapper)

{

    MPSL_IRQ_TIMER0_Handler();

    ISR_DIRECT_PM();

    /* We may need to reschedule in case a radio timeslot callback

     * accesses zephyr primitives.

     */

    return 1;

The fault occurs when "MPSL_IRQ_TIMER0_Handler();" is called. I probably missed something in one of my Kconfig files to properly setup this handler? 

Here is my existing prj.conf. The comments don't always match the commands in many cases as I was editing the version that came with the NUS project demo. I am not using the UART hardware in my app :

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

# Enable the UART driver

CONFIG_UART_ASYNC_API=n

CONFIG_NRFX_UARTE0=n

CONFIG_SERIAL=n

CONFIG_GPIO=y

# Make sure printk is printing to the UART console

CONFIG_CONSOLE=n

CONFIG_UART_CONSOLE=n

CONFIG_HEAP_MEM_POOL_SIZE=2048

CONFIG_BT=y

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_DEVICE_NAME="MY_PROJECT"

CONFIG_BT_MAX_CONN=1

CONFIG_BT_MAX_PAIRED=1

# Enable the NUS service

# STEP 1 - Enable the Kconfig symbol of the NUS service

CONFIG_BT_NUS=y

# Enable bonding

CONFIG_BT_SETTINGS=y

CONFIG_FLASH=y

CONFIG_FLASH_PAGE_LAYOUT=y

CONFIG_FLASH_MAP=y

# Enable DK LED and Buttons library

CONFIG_DK_LIBRARY=n

# This example requires more stack

CONFIG_MAIN_STACK_SIZE=1152

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

# Config logger

CONFIG_LOG=y

CONFIG_USE_SEGGER_RTT=y

CONFIG_LOG_BACKEND_RTT=n

CONFIG_LOG_BACKEND_UART=n

CONFIG_LOG_PRINTK=n

CONFIG_ASSERT=y

CONFIG_PRINTK=n  

[Turbo J]

Single stepping and continue after a break point won't work as soon as any BTLE radio tasks are up - the timing is checked and the code faults when it detects violations.

[PaulJ]

Thanks for that suggestion Turbo. Indeed, when I commented out all the BT startup functions, I can single step through my own code without getting any random exceptions. I then created a "main" loop that just blinked my LED and I can then re-enable the BT stuff and run it (no stepping) and all is good. The confusing part is that I previously did a lot of code development on the DK hardware and I did not experience this same issue. Vidar has mentioned a change to my config that I was going to try next, except now I have a new issue. While cleaning up some of my own code, the system is now not reaching the "main" thread because I get:

Thread 2 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Remote target]

I tried all the power cycling, resetting, etc and it seems stuck on this new "feature". I am new to VB, Nordic, and operating systems (I'm an old school hardware guy) with most of my recent experience being with STM parts and Eclipse so I am a bit overwhelmed by the mountains of learning required for this Nordic part! Any suggestions on how I can recover my system so I can see what is happening in this mysterious "thread 2?

[PaulJ]

After a LOT of digging around, I found that the solution to my problem was to slow down the JLink speed. After about another HOUR of trying to figure out how this is done, I managed to get a debug session running again (It's done in the JSON file, but the AI helper and older solutions from the internet do not work; I eventually realized that the Intellisense system works in the JSON file so it got things in the correct format for me). I will update my original questions results once I have had some time to do more debugging!