• State Not Answered
  • Replies 1 reply
  • Subscribers 68 subscribers
  • Views 66 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

Parents
  • 0

    Hi Kaushalya,

    Thanks for checking with us. Just share some ideas that may help you debug the issue.

    1. Do you manage your development process with git? If yes, can you simplely compare the codes diff before and after you adding I2C?

    2. Since you said "I have multiple work queue items, but they all used to work previously and I have not changed anything.", is it poissble you development environment like NCS has some change? 

    3. This kernel  painc could be caused by a stack overflow or heap corruption, you can try to adjust the size like CONFIG_MAIN_STACK_SIZE.

    4. Try to disable rest at fatel error, you may see something different on the cause. CONFIG_RESET_ON_FATAL_ERROR=n

    Feel free to update if you have find something new.

    Best regards,

    Charlie

Reply
  • 0

    Hi Kaushalya,

    Thanks for checking with us. Just share some ideas that may help you debug the issue.

    1. Do you manage your development process with git? If yes, can you simplely compare the codes diff before and after you adding I2C?

    2. Since you said "I have multiple work queue items, but they all used to work previously and I have not changed anything.", is it poissble you development environment like NCS has some change? 

    3. This kernel  painc could be caused by a stack overflow or heap corruption, you can try to adjust the size like CONFIG_MAIN_STACK_SIZE.

    4. Try to disable rest at fatel error, you may see something different on the cause. CONFIG_RESET_ON_FATAL_ERROR=n

    Feel free to update if you have find something new.

    Best regards,

    Charlie

Children
No Data
Related