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  

[Vidar Berg]

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

[PaulJ]

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!

[Vidar Berg]

Hi,

PaulJ said:

If I try single stepping, I still get the fatal error.

But this is not unexpected, As turbo said, he Bluetooth stack can assert when single stepping because you are halting the CPU and break the real time requirements it has. You can however work around this by enable monitor mode debugging in your project: https://docs.zephyrproject.org/latest/services/debugging/debugmon.html (Note: this is supported on the nRF52 series but not on nRF53 and nRF54L which has the Cortex M33 CPU due to missing support from Segger).

PaulJ said:

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

Good to hear!

[PaulJ]

Hi Vidar

Thanks for the additional info. I added this to my prj.conf

CONFIG_CORTEX_M_DEBUG_MONITOR_HOOK=y  

CONFIG_SEGGER_DEBUGMON=y   

and had limited success. However, while working on the system, I found a flakey power connection, and more importantly, another instance of my app running on the CPU on the development kit (I an using the DK as a JLink debugger through its external debug connector). Once I stopped the other program and fixed the power connection. things got a lot more stable. I was then able to remove the two DEBUGMON configs listed above from the prj-conf file and have not had an exception since! I am still using the

CONFIG_RESET_ON_FATAL_ERROR=n 

however so that might still be helping.

Anyway, I am back in business with the ability to send and receive text back and forth to my phone so now I can go back to troubleshooting all the other hardware. Thanks again for your help

[Vidar Berg]

Hi,

Good to hear it's more reliable now. Since you are using the nRF52840 DK to program the custom board, it may also be worth noting that it does not have a built in level shifter like standalone jlink probes. Therefore, it’s important to ensure that both boards use the same VDD -> IO voltage.

https://docs.nordicsemi.com/bundle/ug_nrf52840_dk/page/UG/dk/hw_debug_out.html