Merge application_update and mqtt_simple

[Thabet]

In my current application I have a combination of some examples and features, but I couldn't add the resource provided by the http_application_update example.

So I tried to make the combination of the mqtt_simple and application_update examples, I realized that there is some incompatibility between the examples or I'm doing something wrong, because I couldn't succeed.

First I was encountering errors related to the settings below prj.conf:

CONFIG_DOWNLOAD_HOST="nrfconnectsdk.s3.eu-central-1.amazonaws.com"

CONFIG_DOWNLOAD_FILE_V2="app_update.bin"

CONFIG_DOWNLOAD_FILE_V1="app_downgrade.bin"

c:\NordicSDK\My_Apps2\MQTT_HTTP_IKS01A2_FOTA\prj.conf:128: warning: attempt to assign the value '"nrfconnectsdk.s3.eu-central-1.amazonaws.com"' to the undefined symbol DOWNLOAD_HOST

I don't understand why I can't add these settings to the prj.conf of the mqtt_simple example, anyway this would get around removing these settings from prj.conf and transforming them into defines in the application. But what is the correct way to add these settings to prj.conf of mqtt_simple?

Getting around this error I found some duplicates, I ended up cleaning everything that was being overlapped between the samples, such as a double definition of void nrf_modem_recoverable_error_handler().

After some time and edits the code compiled. But something is very wrong because the nRF9160 restarts all the time:

*** Booting Zephyr OS build v2.7.99-ncs1-1 ***

I: The MQTT simple sample started
I: Provisioning certificates
W: Failed to retrieve CMEE status, err -1
ASSERTION FAIL @ WEST_TOPDIR/nrf/lib/modem_key_mgmt/modem_key_mgmt.c:76
E: r0/a1: 0x00000004 r1/a2: 0x0000004c r2/a3: 0x00000001
E: r3/a4: 0x00028041 r12/ip: 0x00007000 r14/lr: 0x0002cdc3
E: xpsr: 0x41000000
E: Faulting instruction address (r15/pc): 0x0003e0f6
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
E: Current thread: 0x2000d9a0 (unknown)
E: Resetting system

If I remove CONFIG_MODEM_KEY_MGMT=y from prj.conf, the device stops rebooting but nothing works:

*** Booting Zephyr OS build v2.7.99-ncs1-1 ***
I: The MQTT simple sample started
I: Provisioning certificates
I: Disabling PSM and eDRX
E: nrf_modem_at_printf failed, reported error: -1
E: Failed to disable eDRX, reported error: -1
I: LTE Link Connecting...
E: Failed to get system mode, error: -1
E: Could not get current system mode, error: -14
I: Failed to establish LTE connection: -14
I: Retrying in 120 seconds

I'm using NCS 1.9.1, and modem firmware 1.3.1. I can create firmwares based on both samples individually, but I can't combine the samples!

Have you already managed to add the option to perform FOTA via http (as in the application_update sample) in mqtt_simple?

Thank you.

[Thabet]

I tried to call the function that starts the firmware update from several places, main, workqueue... I always get errors, for example when I call through a thread I get this error:

I: Configuring socket timeout (30 s)
I: Connecting to files.wnology.io
E: ***** USAGE FAULT *****
E:   Stack overflow (context area not valid)
E: r0/a1:  0x0004040a  r1/a2:  0x21040000  r2/a3:  0x0d0f8e00
E: r3/a4:  0x6207ccbf r12/ip:  0x2350734b r14/lr:  0x0000002c
E:  xpsr:  0x2001bc00
E: Faulting instruction address (r15/pc): 0xffffffd9
E: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
E: Current thread: 0x2000f338 (unknown)
E: Resetting system

Please give me tips on how to do this!

[Thabet]

I managed to track down what causes this error! I can't disable new libc nano:

CONFIG_NEWLIB_LIBC_NANO=n

Apparently the application_update example depends on this lib. But I need to disable this lib because of other things in the code. How could I account for this problem and eliminate this dependency on libc nano?

I already use the full libc, shouldn't that be enough and make it possible to disable libc nano without causing any problems?

CONFIG_NEWLIB_LIBC=y

Please give me tips on how to get around this, over 1 week and no response from Nordic!

[Hakon]

Thabet said:

Apparently the application_update example depends on this lib. But I need to disable this lib because of other things in the code. How could I account for this problem and eliminate this dependency on libc nano?

The at_cmd parser depends on the CONFIG_NEWLIB_LIBC_NANO config, you need to somehow get rid of this first.

[Thabet]

In the link you mentioned, here, I can see that the library is dependent on NEWLIB_LIBC, does this refer to CONFIG_NEWLIB_LIBC_NANO? Isn't this referring to CONFIG_NEWLIB_LIBC?

NEWLIBC NANO isn't a shortened version of NEWLIBC? Wouldn't we have to have the resources present in LIBC NANO within the full LIBC?

I'm not able to track where this error comes from, the error occurs when the download is started, but according to the documentation the http_application_update sample uses the download client library to download the image, the same library used in the download_client sample, but in the download_client sample I can disable no problem to lib nano, doing this I don't get any errors! 

So apparently the error is not in the download client library, but why does it occur when it is called in the application_update sample? I've tried tracking the source through "arm-none-eabi-addr2line -e build/zephyr/zephyr.elf 0x0003e0f6" but that doesn't get me anywhere. Could you please help me to track down this error?

[Thabet]

Hello Hakon,

The error occurs inside http.c, on line 83, in the call below:

len = snprintf(client->buf,

            CONFIG_DOWNLOAD_CLIENT_BUF_SIZE,

            HTTP_GET_RANGE, file, host, client->progress, off);

Could someone from Nordic please help? 20 days of topic, 1 reply, 0 solution. This issue is delaying prototype assembly and field testing!

[Hakon]

What thread is giving the assert? If it's the download-thread, you can maybe try changing the stack size, CONFIG_DOWNLOAD_CLIENT_STACK_SIZE=4096.

[Hakon]

Also, try setting CONFIG_THREAD_NAME=y to display the thread name.

[Thabet]

By default I already have this conf:

CONFIG_DOWNLOAD_CLIENT_STACK_SIZE=4096

The sysworkq thread giving the assert!

[Thabet]

Finally this is resolved, thanks @Hakon for showing me this command:

CONFIG_THREAD_NAME=y

After using it I noticed that the problem was related to the workqueue stack size!

Anyone who has this problem, know that the solution is to increase the stack through the configuration: CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE