About an ASSERTION FAIL and ZEPHYR FATAL ERROR 4

Hi

Right now I'm using NCS2.0.0 & nRF52832 for development the mesh application.

Whenever My setting the "Light CTL Default Set"(in the file light_ctl_srv.c for function handle_default_set),it will ASSERTION.

After my tracking, I found that the problem is in the timer call from "light_ctl_srv.c" file.The calling sequence is as follows:

handle_default_set() of Line:268
default_set() of Line:232
lightness_srv_default_set() of Line:324
store_state() of Line:55
static void store_state(struct bt_mesh_lightness_srv *srv)
{
#if CONFIG_BT_SETTINGS
	k_work_schedule(
		&srv->store_timer,
		K_SECONDS(CONFIG_BT_MESH_MODEL_SRV_STORE_TIMEOUT));
#endif
}
In the function "store_state() " it will calling "k_work_schedule()".At this times, an assertion is triggered.And the k_work_schedule() return value 1.
finally in the work.c file of work_queue_main function "__ASSERT_NO_MSG(handler != NULL)" assertion.
The RTT LOG as follows:
D: Store: Last: 47607 Default: 45498 State: On Range: [656 - 65535]
ASSERTION FAIL @ WEST_TOPDIR/zephyr/kernel/work.c:648
E: r0/a1:  0x00000004  r1/a2:  0x00000288  r2/a3:  0x00000001
E: r3/a4:  0x2000a2f6 r12/ip:  0x00000000 r14/lr:  0x0003e0f5
E:  xpsr:  0x61000000
E: Faulting instruction address (r15/pc): 0x0004372c
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
E: Current thread: 0x20005a30 (sysworkq)
E: Resetting system

Why does calling the k_work_schedule here cause an assertion, but calling it elsewhere does not?

Parents
  • Hi,

    One initial guess is that it might have something to do with the work queue stack size, i.e CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE. Could you try to increase this and see if this removes the error?

    If this does not work, can you supply a minimal sample that reproduces this error for me so I can investigate it closer? Please remember that you don't add any sensitive information in the sample.

    Let me know about these things and I'll do my best to see if I can help you solve this issue!

    Kind regards,
    Andreas

Reply
  • Hi,

    One initial guess is that it might have something to do with the work queue stack size, i.e CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE. Could you try to increase this and see if this removes the error?

    If this does not work, can you supply a minimal sample that reproduces this error for me so I can investigate it closer? Please remember that you don't add any sensitive information in the sample.

    Let me know about these things and I'll do my best to see if I can help you solve this issue!

    Kind regards,
    Andreas

Children
No Data
Related