m_drv_state == NRFX_DRV_STATE_POWERED_ON assertion

[tldr]

I'm using a thingy53 on ncs v2.7.0.

I turned on CONFIG_ASSERT to try and find issues.  This issue pops up randomly, it asserts the program crashes and causes me to have to remove the battery to get the accel reporting the proper device id.

ASSERTION FAIL [m_drv_state == NRFX_DRV_STATE_POWERED_ON] @ WEST_TOPDIR/zephyr/drivers/usb/common/nrf_usbd_common/nrf_usbd_common.c:1275
[00:00:00.621,917] <err> os: r0/a1:  0x00000004  r1/a2:  0x000004fb  r2/a3:  0x00000000
[00:00:00.623,016] <err> os: r3/a4:  0x00000004 r12/ip:  0x00000400 r14/lr:  0x0002c7c1
[00:00:00.624,114] <err> os:  xpsr:  0x01000000
[00:00:00.624,877] <err> os: Faulting instruction address (r15/pc): 0x00040ca0
[00:00:00.625,885] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:00:00.626,861] <err> os: Current thread: 0x20006838 (usbd_workq)

arm-zephyr-eabi-addr2line -e build/zephyr/zephyr.elf 0x00040ca0
C:/ncs/v2.7.0/zephyr/lib/os/assert.c:44

https://github.com/zephyrproject-rtos/zephyr/issues/12016 - Crash while disconnecting device from USB

This project does wake sense and turns off and on.  It crashes and I find something about a work->handler being null (and the code I'm working in doesn't use workq) or now this NRFX_DRV_STATE_POWERED_ON assertion.  Which based on the discussions in the above github link theres a workq involved here.

I can't remember if there was a physical disconnect or not.  I will continue to try to reproduce.

[Sigurd Hellesvik]

Hi,

This issue pops up randomly, it asserts the program crashes and causes me to have to remove the battery to get the accel reporting the proper device id.

Have you set CONFIG_RESET_ON_FATAL_ERROR?

Regards,
Sigurd Hellesvik

[tldr]

Just looked and 
# CONFIG_RESET_ON_FATAL_ERROR=n
it is commented out.

It is not resetting when this assert occurs.

[Sigurd Hellesvik]

tldr said:

Just looked and 
# CONFIG_RESET_ON_FATAL_ERROR=n
it is commented out.

To verify what is really set in the final build, check build/zephyr/.config and build/mcuboot/zephyr/.config

[tldr]

Both of those files do not contain CONFIG_RESET_ON_FATAL_ERROR

[Sigurd Hellesvik]

In that case, I suggest that you set CONFIG_RESET_ON_FATAL_ERROR to yes.
Does that workaround the issue?
I ask about this first because it would be good to have a generally reliable app first. Then we can look into the specific issue after.

[tldr]

CONFIG_RESET_ON_FATAL_ERROR=y hides the error as a unknown reboot.  That's the problem, getting a generally reliable app is hard to do if the device resets itself when something goes wrong.

I can't reproduce this.  If I come up with a way to reproduce we have some hope, but at this point I'm just able to report that such events occur.  If you have any suggestions on how to address, reproduce, or other thoughts I would be happy to hear them.

If I turned that setting on, this issue would just be another strange behavior reboot.

[Sigurd Hellesvik]

Right, it does not happen all the time.

I recommend that you set up a device with a stress test over a longer period to try to force this error. In general, it is a good idea to have a long-time test of your devices.

So there are two cases here:

1. The issue happens very rarely, so you see it infrequently in the test.
   1. In this case, having a reset on the error would have a low impact on your users.
2. The issue happens often in your test.
   1. In this case, it will be easy to look at the issue, and test alternative fixes

https://github.com/zephyrproject-rtos/zephyr/issues/12016 - Crash while disconnecting device from USB

This project does wake sense and turns off and on.  It crashes and I find something about a work->handler being null (and the code I'm working in doesn't use workq) or now this NRFX_DRV_STATE_POWERED_ON assertion.  Which based on the discussions in the above github link theres a workq involved here.

Is the fix in https://github.com/zephyrproject-rtos/zephyr/pull/12335 applied in the SDK you are running?