• State Not Answered
  • Replies 0 replies
  • Subscribers 67 subscribers
  • Views 23 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 336352
Options

Kernel panic

kaushalyasat

Hi,

I am working on implementing an I2C node in my nRF52840 based sensor. However I am getting the following kernel panic.

*** Booting nRF Connect SDK v3.5.99-ncs1 ***
[00:00:00.272,491] <inf> coap_client: Reset reason : SREQ
[00:00:00.273,010] <dbg> coap_utils: coap_init: CoAP socket receive thread started
ASSERTION FAIL @ WEST_TOPDIR/zephyr/kernel/work.c:671
[00:00:00.296,661] <err> os: r0/a1:  0x00000004  r1/a2:  0x0000029f  r2/a3:  0x00000004
[00:00:00.296,691] <err> os: r3/a4:  0x200023a0 r12/ip:  0x00000010 r14/lr:  0x0002661b
[00:00:00.296,691] <err> os:  xpsr:  0x41000000
[00:00:00.296,722] <err> os: s[ 0]:  0xffffffff  s[ 1]:  0xffffffff  s[ 2]:  0x00000000  s[ 3]:  0xaaaaaaaa
[00:00:00.296,722] <err> os: s[ 4]:  0xaaaaaaaa  s[ 5]:  0x000265dd  s[ 6]:  0x00000000  s[ 7]:  0x00000000
[00:00:00.296,752] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
[00:00:00.296,783] <err> os: s[12]:  0x00000000  s[13]:  0x000462fb  s[14]:  0x00000000  s[15]:  0xaaaaaaaa
[00:00:00.296,783] <err> os: fpscr:  0x2000b5c0
[00:00:00.296,783] <err> os: Faulting instruction address (r15/pc): 0x000467c0
[00:00:00.296,844] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:00:00.296,875] <err> os: Current thread: 0x20004968 (sysworkq)
[00:00:01.418,121] <err> fatal_error: Resetting system
uart:~$

I removed all I2C node related code that I have added, but no help.

When I check the fault address, it is generated from "C:\ncs\v2.6.0\zephyr\lib\os\assert.c" line 44, which is execution of k_panic(). So it doesn't give me a clue who is raising the assert.

The kernel panic log says "ASSERTION FAIL @ WEST_TOPDIR/zephyr/kernel/work.c:671" which is 

"__ASSERT_NO_MSG(handler != NULL)"

I have multiple work queue items, but they all used to work previously and I have not changed anything.

After a debug session, I can see this happens in my init function when I run

'k_work_init(&on_connect_work, on_connect);'

'on_connect_work 'is a k_work structure and on_connect is of type 'ot_connection_cb_t'. 

Could it be a stack issue?

I am revisiting the code after some time so it could be I have missed something.

Can you please help?

Cheers,

Kaushalya

Related