otDatasetCreateNewNetwork () causes a MPU FAULT in SDK 2.6.0

[kaushalyasat]

Hi,

I use the above function to create a new dataset. When I use SDK 2.3.0, this works perfectly. But when I use SDK 2.6.0 I get the following.

[00:00:06.162,597] <err> os: ***** MPU FAULT *****
[00:00:06.162,628] <err> os:   Data Access Violation
[00:00:06.162,628] <err> os:   MMFAR Address: 0x20013e3c
[00:00:06.162,658] <err> os: r0/a1:  0x20013e48  r1/a2:  0x00000000  r2/a3:  0x00000228
[00:00:06.162,689] <err> os: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x0006005b
[00:00:06.162,689] <err> os:  xpsr:  0x410f0000
[00:00:06.162,719] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
[00:00:06.162,719] <err> os: s[ 4]:  0xffffffff  s[ 5]:  0xffffffff  s[ 6]:  0x00000000  s[ 7]:  0x0002d26f
[00:00:06.162,750] <err> os: s[ 8]:  0xffffffff  s[ 9]:  0x20003078  s[10]:  0x2000c280  s[11]:  0xffffffff
[00:00:06.162,780] <err> os: s[12]:  0xffffffff  s[13]:  0x0002edff  s[14]:  0xffffffff  s[15]:  0xffffffff
[00:00:06.162,811] <err> os: fpscr:  0xaaaaaaaa
[00:00:06.162,811] <err> os: Faulting instruction address (r15/pc): 0x0002c206
[00:00:06.162,841] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
[00:00:06.162,902] <err> os: Current thread: 0x200031a8 (shell_uart)
[00:00:06.394,195] <err> fatal_error: Resetting system

When I tried 

arm-zephyr-eabi-addr2line.exe -e C:\nrfwork\zmhostradiofw\release\zephyr\zephyr.elf -a 0x0002c206

I get ??.?. 

I tried adding the following to the prj.conf, but no improvement.

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

CONFIG_MAIN_STACK_SIZE=4096

I can see there is a difference between how SDK 2.3.0 and SDK 2.6.0 implement 'commissioner dataset init new' and 'dataset commit active'. So I tried to bring how the CLI is implemented in SDK 2.6.0  as follows.

otError cli_cmsn (void *aContext, uint8_t aArgsLength, char *aArgs[]) {
    .
    .
    .
    
    otCliOutputFormat ("\n\rCreate new dataset ");
	error = otDatasetCreateNewNetwork(instance, &aDataset);	// create new dataset
	error = otDatasetConvertToTlvs(&aDataset, &aDatasetTlvs);   // SDK 2.6.0
	if (error != OT_ERROR_NONE) {
		otCliOutputFormat ("create new dataset error");
	 	return (error);
	}

	otCliOutputFormat ("\n\r active new dataset ");
	
	//error = otDatasetSetActive(instance, &aDataset);	// active new dataset SDK 2.3.0
	
	error = otDatasetSetActiveTlvs(instance, &aDatasetTlvs);
	if (error != OT_ERROR_NONE) {
		otCliOutputFormat ("active new dataset error");
		return (error);
	}
	
	.
	.
}

But now I get even weirder kernel panic as follows.

[00:00:08.872,985] <err> os: ***** MPU FAULT *****
[00:00:08.873,016] <err> os:   Stacking error (context area might be not valid)
[00:00:08.873,046] <err> os:   Data Access Violation
[00:00:08.873,046] <err> os:   MMFAR Address: 0x20013e68
[00:00:08.873,077] <err> os: r0/a1:  0x2000c280  r1/a2:  0xffffffff  r2/a3:  0xffffffff
[00:00:08.873,077] <err> os: r3/a4:  0x0002edfb r12/ip:  0xffffffff r14/lr:  0xffffffff
[00:00:08.873,107] <err> os:  xpsr:  0xaaaaaa00
[00:00:08.873,138] <err> os: s[ 0]:  0xaaaaaaaa  s[ 1]:  0xaaaaaaaa  s[ 2]:  0xaaaaaaaa  s[ 3]:  0xaaaaaaaa
[00:00:08.873,138] <err> os: s[ 4]:  0xaaaaaaaa  s[ 5]:  0xaaaaaaaa  s[ 6]:  0xaaaaaaaa  s[ 7]:  0xaaaaaaaa
[00:00:08.873,168] <err> os: s[ 8]:  0xaaaaaaaa  s[ 9]:  0xaaaaaaaa  s[10]:  0xaaaaaaaa  s[11]:  0xaaaaaaaa
[00:00:08.873,199] <err> os: s[12]:  0xaaaaaaaa  s[13]:  0xaaaaaaaa  s[14]:  0xaaaaaaaa  s[15]:  0xaaaaaaaa
[00:00:08.873,199] <err> os: fpscr:  0xaaaaaaaa
[00:00:08.873,229] <err> os: Faulting instruction address (r15/pc): 0xaaaaaaaa
[00:00:08.873,260] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
[00:00:08.873,291] <err> os: Current thread: 0x200031a8 (shell_uart)
[00:00:09.121,612] <err> fatal_error: Resetting system

 

What is going wrong with SDK 2.6.0?

Cheers,

Kaushalya

[kaushalyasat]

I run thread analyzer just before calling ' error = otDatasetCreateNewNetwork(instance, &aDataset); // create new dataset' and I get the following.

 Thread stop Thread analyze:
 CoAP-sock-recv      : STACK: unused 592 usage 408 / 1000 (40 %); CPU: 0 %
      : Total CPU cycles used: 1
 rx_q[0]             : STACK: unused 1272 usage 328 / 1600 (20 %); CPU: 0 %
      : Total CPU cycles used: 103
 openthread          : STACK: unused 3500 usage 2676 / 6176 (43 %); CPU: 0 %
      : Total CPU cycles used: 3834
 ot_radio_workq      : STACK: unused 512 usage 448 / 960 (46 %); CPU: 0 %
      : Total CPU cycles used: 119
 nrf5_rx             : STACK: unused 408 usage 328 / 736 (44 %); CPU: 0 %
      : Total CPU cycles used: 64
 sysworkq            : STACK: unused 1608 usage 376 / 1984 (18 %); CPU: 10 %
      : Total CPU cycles used: 149404
 MPSL Work           : STACK: unused 568 usage 392 / 960 (40 %); CPU: 0 %
      : Total CPU cycles used: 117
 shell_uart          : STACK: unused 1152 usage 2016 / 3168 (63 %); CPU: 0 %
      : Total CPU cycles used: 2700
 logging             : STACK: unused 1432 usage 616 / 2048 (30 %); CPU: 0 %
      : Total CPU cycles used: 1568
 idle                : STACK: unused 272 usage 48 / 320 (15 %); CPU: 88 %
      : Total CPU cycles used: 1202459
 ISR0                : STACK: unused 872 usage 1240 / 2112 (58 %)

I cant see any thread starving of stack. I would like to know what you think.

Cheers,

Kaushalya

[Vidar Berg]

Hi Kaushalya,

Please try to increase the CONFIG_SHELL_STACK_SIZE setting. The crash log says you have a stack overflow in your 'shell_uart' thread, so this should hopefully fix the problem.

Best regards,

Vidar

[kaushalyasat]

Hi Vidar, Thanks, I increased it to 4096 and seem to fix it.

Initially the thread analyzer says

'shell_uart          : STACK: unused 1152 usage 2016 / 3168 (63 %); CPU: 0 %'

So there seems enough stack size just before calling otDatasetCreateNewNetwork (). What you think happening is during the function's execution, the stack for shell_uart overflows?

Thanks,

Kaushalya

[Vidar Berg]

Hi Kaushalya,

Thanks for the update. I think the problem was that otDatasetCreateNewNetwork() was simply using more stack than what had been allocated to the UART shell thread. There could be several reasons why it worked in v2.3.0 but not in v2.6.0. Maybe the default stack size was higher, or perhaps the OT function requires more stack in the new version.

Best regards,

Vidar