• State Verified Answer
  • Replies 5 replies
  • Subscribers 65 subscribers
  • Views 244 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 327814
Options

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