NRF9160 w_lte_lc_init_and_connect throws __usage_fault after at_cmd(at_socket_fd, subscribe...)

[GJSea]

Hi,

I have the latest 0.4.0 tag, flashed the latest modem firmware 0.7.0-29.alpha, and debugging the asset_tracker app under nrf9160_pca10090ns.

When I debug the app it throws a __usage_fault sometime after at_cmd(at_socket_fd, subscribe, AT_CMD_SIZE(subscribe)); within  w_lte_lc_init_and_connect 

Any idea what is asyncronously happening behind the scenes that is throwing the __usage_fault?

Thx!

[Martin Lesund]

Hi GJSea,

I would like to know a little bit more about your "setup".

Is this an unmodified asset_tracker app running on the nrf91?

Have you at any times changed or provisioned any keys to the modem?

I want to reproduce this if possible, so any more information would be helpful.

Best Regards,

Martin L.

[GJSea]

Hi Martin,

I'm tracking the issue down further, it seems even with the most basic app that does nothing per below, that a stack overflow fault is raised, likely on another OS thread. Anyway of knowing where in Zephyr this is coming from as there isn't any call stack context.

I'm using the regular 9160DK board, v.0.4.0 tag, latest nRF Connect

void main(void)
{
	printk("Application started\n");
	while (true) {
		k_sleep(K_MSEC(10));
		/* Put CPU to idle to save power */
		k_cpu_idle();
	}
}

This is the output from LTE Link:

SPM: NS image at 0x8000
SPM: NS MSP at 0x20029468
SPM: NS reset vector at 0x10039
SPM: prepare to jump to Non-Secure image.
***** Booting Zephyr OS v1.14.99-ncs1 *****
Application started
***** HARD FAULT *****
Fault escalation (see below)
***** USAGE FAULT *****
Stack overflow (context area not valid)
***** Stack Check Fail! *****
Current thread ID = 0x200209ec
Faulting instruction address = 0x20026750
Fatal fault in thread 0x200209ec! Aborting.

Thanks!

[Martin Lesund]

Hi GJSea,
I am having a hard time trying to reproduce the issue at hand.
Could you please share what you have configured in the "prj.conf" file?

---

From the output you are sharing, it does look like a stack overflow.

• It is possible to check which thread that crashes by looking at the thread-ID (remove the '0x' first) in the ".map" file found in [/build/zephyr].
• Then you can also see which function/instruction that caused it in the ".lst" file.

Best Regards,
Martin L.

[GJSea]

I believe I figured out the cause of the problem, if I turn compiler optimizations off using CONFIG_NO_OPTIMIZATIONS=y in PRJ.CONF then the stack overflow occurs per below, if optimizations are on per the default then the fault doesn't occur. I guess somewhere deep in the Zephyr code there is a sensitivity to timing of optimized code or some other related cause. I can get by by debugging using printk for now, as using the SES debugger with optimizations on is pretty much unusable.

Thx!

**** USAGE FAULT *****
Stack overflow (context area not valid)
***** Stack Check Fail! *****
Current thread ID = 0x20020d1c
Faulting instruction address = 0x20028190
Fatal fault in thread 0x20020d1c! Aborting.
ASSERTION FAIL [z_spin_lock_valid(l)] @ C:/Nordic/NRF9160-040/ncs/zephyr/include/spinlock.h:78
Recursive spinlock
***** Kernel Panic! *****
Current thread ID = 0x200221dc
Faulting instruction address = 0x3633e

[Martin Lesund]

Hi GJSea,
As you have found out this is a classic stack overflow issue.

The solution would be to find out which stacks that overflows with the help of the thread ID and zephyr.map, and then increase the size of these.

Typically it will be to increase the size of these two from 512 to 1024:

- https://github.com/NordicPlayground/fw-nrfconnect-nrf/blob/master/lib/at_host/at_host.c#L27

- https://github.com/NordicPlayground/fw-nrfconnect-nrf/blob/master/lib/modem_info/modem_info.c#L21

Best regards,
Martin L.

[GJSea]

Yes increasing these stack size values solved the overflow problem. Thanks!!! The code might want to check for CONFIG_NO_OPTIMIZATIONS and have a #ifdef for the values there.