Calling date_time_update_async from main thread leads to stack overflow

Dear Nordic Support Team,

I am using nRF Connect 1.9.1 together with the modem firmware 1.3.2 on a nRF9160 DK.

I noticed that calling the function date_time_update_async in the main thread produces a stack overflow error. This is the case even if a connection to the cellular network was established before calling date_time_update_async .

I have attached three files:

  1. [minimalExample.c] Minimal example to produce the error
  2. [log_dateTimeStackOverflow.txt] Error log for the case when date_time_update_async  is called without prior connection to the cellular network
  3. [log_dateTimeStackOverflow_lte.txt] Error log for the case when date_time_update_async  is called after a connection to the cellular network was established

// Zephyr
#include <zephyr.h>

// Nordic
#include <date_time.h>
#include <modem/lte_lc.h>



static bool isDateTimeUpdateDone = false;

static void callback_dateTimeEvent(const struct date_time_evt *evt)
{
    printk("Event %d\n", evt->type);
    isDateTimeUpdateDone = true;
}



void main(void)
{
    printk("I am running!\n");


    int error = 0;

    // error = lte_lc_init();
    // printk("lte_lc_init: %d\n", error);

    // error = lte_lc_connect();
    // printk("lte_lc_connect: %d\n", error);

    error = date_time_update_async(callback_dateTimeEvent);
    printk("date_time_update_async: %d\n", error);

    while (!isDateTimeUpdateDone)
    {
        printk("Waiting...\n");
        k_sleep(K_MSEC(500));
    }


    printk("I am returning!\n");
}
*** Booting Zephyr OS build v2.7.99-ncs1-1  ***<CR><LF>
I: Starting bootloader<CR><LF>
I: Primary image: magic=good, swap_type=0x4, copy_done=0x1, image_ok=0x1<CR><LF>
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<CR><LF>
I: Boot source: none<CR><LF>
I: Swap type: none<CR><LF>
I: Bootloader chainload address offset: 0x10000<CR><LF>
I: Jumping to the first image slot<CR>
*** Booting Zephyr OS build v2.7.99-ncs1-1  ***<CR><LF>
I am running!<CR><LF>
date_time_update_async: 0<CR><LF>
Waiting...<CR><LF>
[00008712] <ESC><err> os: ***** USAGE FAULT *****<ESC><CR><LF>
[00008712] <ESC><err> os:   Stack overflow (context area not valid)<ESC><CR><LF>
[00008713] <ESC><err> os: r0/a1:  0x00038834  r1/a2:  0x41000000  r2/a3:  0x0001001a<ESC><CR><LF>
[00008713] <ESC><err> os: r3/a4:  0xabddef67 r12/ip:  0x00038fd4 r14/lr:  0x41000000<ESC><CR><LF>
[00008714] <ESC><err> os:  xpsr:  0xadffbc00<ESC><CR><LF>
[00008714] <ESC><err> os: Faulting instruction address (r15/pc): 0x00010079<ESC><CR><LF>
[00008715] <ESC><err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0<ESC><CR><LF>
[00008716] <ESC><err> os: Current thread: 0x2000e2b8 (unknown)<ESC><CR><LF>
[00010417] <ESC><err> fatal_error: Resetting system<ESC><CR>
*** Booting Zephyr OS build v2.7.99-ncs1-1  ***<CR><LF>
I: Starting bootloader<CR><LF>
I: Primary image: magic=good, swap_type=0x4, copy_done=0x1, image_ok=0x1<CR><LF>
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<CR><LF>
I: Boot source: none<CR><LF>
I: Swap type: none<CR><LF>
I: Bootloader chainload address offset: 0x10000<CR><LF>
I: Jumping to the first image slot<CR>
*** Booting Zephyr OS build v2.7.99-ncs1-1  ***<CR><LF>
I am running!<CR><LF>
lte_lc_init: 0<CR><LF>
lte_lc_connect: 0<CR><LF>
date_time_update_async: 0<CR><LF>
Waiting...<CR><LF>
[00146596] <ESC><err> os: ***** USAGE FAULT *****<ESC><CR><LF>
[00146597] <ESC><err> os:   Stack overflow (context area not valid)<ESC><CR><LF>
[00146597] <ESC><err> os: r0/a1:  0x00038fc4  r1/a2:  0x41000000  r2/a3:  0xa8044105<ESC><CR><LF>
[00146597] <ESC><err> os: r3/a4:  0xadffbd6b r12/ip:  0x48fc6800 r14/lr:  0x6fedee7e<ESC><CR><LF>
[00146598] <ESC><err> os:  xpsr:  0x00038800<ESC><CR><LF>
[00146598] <ESC><err> os: Faulting instruction address (r15/pc): 0x20010808<ESC><CR><LF>
[00146599] <ESC><err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0<ESC><CR><LF>
[00146600] <ESC><err> os: Current thread: 0x2000e2c0 (unknown)<ESC><CR><LF>
[00148295] <ESC><err> fatal_error: Resetting system<ESC><CR>

In the following are the Kconfig settings I believe to be relevant for this case:

CONFIG_NRF_MODEM_LIB=y
CONFIG_MODEM_KEY_MGMT=y
CONFIG_MODEM_INFO=y

CONFIG_LTE_LINK_CONTROL=y
CONFIG_LTE_NETWORK_MODE_LTE_M=y
CONFIG_LTE_AUTO_INIT_AND_CONNECT=n

CONFIG_DATE_TIME=y
CONFIG_DATE_TIME_AUTO_UPDATE=n
CONFIG_DATE_TIME_UPDATE_INTERVAL_SECONDS=7200

CONFIG_MAIN_STACK_SIZE=32768
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=32768
CONFIG_HEAP_MEM_POOL_SIZE=32768

A little more context:

In my application I have multiple time sources. One of them is Nordic's date time library and another is a RTC. I try to initialize both on system startup when a connection to the cellular network isn't established yet. I am expecting the RTC to do its thing and I expect Nordic's date time library to fail gracefully with the event DATE_TIME_NOT_OBTAINED. However my application crashes with the aforementioned error.

I would like to understand what causes the error and how it can be prevented.

Thank you allot for your help! Please don't hesitate to ask if you have any questions.

Cheers,
Sebastian

Parents
  • Hi Håkon,

    thank you allot for looking into that issue.

    I have been trying to reproduce the issue, however, some context is missing. Would you be able to upload a project folder with a code snippet that causes the stack overflow?

    Certainly. Here is a project directory with code that produces the stack overflow: minimalExample.zip

    I am not sure if any of the following points are relevant, but I mention them anyhow to give you as much context as possible:

    • I am using a nRF9160 DK version 1.0.0
    • I am building and flashing the application with SEGGER Embedded Studio for ARM V5.68
    • I have added a screenshot to the ZIP archive which shows how I load the project in SEGGER ES.
    • Please note that I use a custom firmware (modified Hello World sample) for the nRF52840 to disable some routing in the nrf9160dk_nrf52840.overlay file. You'll find the respective project directory in the ZIP archive as well.

    Furthermore, please note that tomorrow is my last working day this year. I will be back in the office in January 2023. Thus it might take some time before I can answer possible followup questions.

    Thank you again for you support.

    Cheers,
    Sebastian

  • Thank you for sharing the minimalExample.zip. When building and running, I was able to produce a stack overflow. However, when I tried arm-none-eabi-addr2line I was not able to get any reasonable result so far. I will keep you updated on my findings.

Reply Children
No Data
Related