Kernel Panic in NUS app when porting to custom PCB

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  
  • 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.

  • Hello 

    Are you able to capture the crash log from RTT? It may be easier to catch if you build with CONFIG_RESET_ON_FATAL_ERROR disabled. Faults from MSPL/SDC are almost always raised intentionally after an assertion has been triggered. For example, when timing deadlines are missed due to single stepping with the debugger, as Turbo mentioned.

    Best regards,

    Vidar

  • 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?

  • 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!

  • Hi Vidar

    Thanks for your suggestion. I had some other issues (read my replies to Turbo) but I now have a bare bones implementation that sits in an empty main loop blinking my LED. If I run my code with no breakpoints, all is good. If I try single stepping, I still get the fatal error. I added the CONFIG_RESET_ON_FATAL_ERROR to my prj.config and now I can sometimes single step without error and sometimes not. I will dig deeper to see if I can replicate when it happens but at least for now, I think I have a system that I can continue debugging. If I find the final solution that works 100%, then I will repost here for others to find.

    The good news is that I am now communicating over bluetooth to my phone so I know that part of my hardware is working!

Related