Troubleshooting sporadic resets (application soft reset)

[cscase]

Hi all,

I am working on troubleshooting intermittent application resets with an nRF52840 and nRF Connect 2.6.1.  Codebase is small, complexity of the project is still small, and I suspect this is something simple, but I'm just not sure what I should be looking at to get to the bottom of it.

My target board an Adafruit nRF52840 Feather Express board. (https://www.adafruit.com/product/4062).

The project I have on here doesn't have a lot to it yet. I started from the observer example project. I have console output being sent to virtual COM port/USB CDC. I'm watching for Bluetooth advertisements which have a particular manufacturer ID and for each of these, creating a message in a message queue. Another thread continually removes messages from the queue. For each message it removes, it logs a message to the console but doesn't actually do anything further.

Sporadically, the device resets. The reason logged is "application soft reset." This seems to happen unpredictably, but typically the project will not run for more than 15-20 minutes without this happening at least once. It might sometimes happen sooner, too.

My configuration is as below:

#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#~~ MEMORY ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=1024

#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#~~ BLUETOOTH ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONFIG_BT=y
CONFIG_BT_OBSERVER=y
CONFIG_BT_EXT_ADV=y
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#~~ SERIAL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONFIG_SERIAL=y
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#~~ UART ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_LINE_CTRL=y
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#~~ LOG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONFIG_LOG=y
CONFIG_LOG_PRINTK=y
CONFIG_LOG_BACKEND_SHOW_COLOR=y
CONFIG_LOG_PROCESS_THREAD_STACK_SIZE=2048
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#~~ USB CDC ACM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="PRODUCT_NAME"
CONFIG_USB_DEVICE_PID=0x0004
CONFIG_USB_WORKQUEUE=y  #--sc 30 May 2024
CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=y #--sc 30 May 2024
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Thread analyzer
CONFIG_THREAD_ANALYZER=y
CONFIG_THREAD_ANALYZER_USE_PRINTK=y
CONFIG_THREAD_ANALYZER_AUTO=y
CONFIG_THREAD_ANALYZER_AUTO_INTERVAL=5
CONFIG_THREAD_NAME=y

I tried setting the debugger to break on Zephyr errors, and it stops with the BT_TX thread highlighted. I'm not doing any (intentional, anyway) advertising or transmit, so I'm not sure what's going on here. Here's a screenshot:

What kinds of things should I be looking at to figure out what's going on here? At first I was thinking maybe I need to allocate more resources for something, but these threads seem to have plenty of stack available.

[Susheel Nuguru]

Are you testing multi connection in your app?

What is the value of CONFIG_BT_MAX_CONN? This config have influence in the hci_tx_thread on the event buffer size.

[cscase]

No, this config option is not currently set. The intent is that the device be an entirely passive listener and no connections should be made to it.

[Susheel Nuguru]

If this is something you can reproduce on the nRF52840 DK, then Can you please attach the project here? I can make this thread private if you do not want to share the project with public yet. But if it is nothing confidential yet in your project, it is better to leave it public.

If you remove the breakpoint and run, then the log should give some debug info regarding the fault. What info does it give?

[cscase]

Hi Susheel,

I apologize - I was replying on mobile and I think I accidentally must have ticked "Verify answer," resulting in ticket being closed prematurely.

I don't have an nRF52840 DK, but I'm working on getting one and should have it tomorrow. I'll see if I can reproduce this symptom on that board.

I'm actually having problems reproducing this error message on my own hardware now. It makes no sense to me that it would have fixed itself over the weekend, but I have been fiddling with a lot of variables and maybe something I did sorted it out.

What if we leave this cased closed for now, and if / when I am able to reproduce the issue and test it on the DK board, I'll create a second post with all of the relevant information, and upload the project if applicable?

Thanks,

Scott

[Susheel Nuguru]

Scott, 

Happens when your prototype is evolving constantly. I hope that it got fixed but it is always good to know why we saw failures just to have a feeling that we have things in control.

I will close this as you suggested and please reopen it when you find some other related issue.