FOTA Not Working

[Nicholas Papachristos]

I am using:

• nRF Connect SDK 3.4.0
• SDK Tools 3.4.0
• Asset Tracker Template
• Thingy91X / nRF9151
• CoAP cloud connection

The device successfully connects to nRF Cloud and reports:

SW type:        app

SW version:   0.0.1

HW version:   thingy91x

I created an OTA Release 0.0.3 in the new nRF Cloud OTA Experience (Memfault-based OTA Releases). The release is activated for cohort 3rd_ota, and the cohort view shows:

Current version: 0.0.1 (app) (thingy91x)

Future version:   0.0.3

Device count:     1

The device is the single member of that cohort.

However:

Asset Tracker FOTA path

Running:

    att_fota poll

results in:

    nrf_cloud_fota_poll: Checking for FOTA job...

    nrf_cloud_fota_poll: No pending FOTA job

Memfault OTA path

Running:

    mflt get_latest_release

results in:

     mflt: FOTA Update Available

     mflt: FOTA Update Available. Starting Download with URL: ...

     mflt: FOTA start failed, rv=-5

I stepped through the code and confirmed that:

     fota_download_any(...)  returns: -5

The device therefore sees the OTA Release through the Memfault path, but the Asset Tracker Template FOTA module does not see a pending FOTA job.

Question

For SDK 3.4.0 Asset Tracker Template:

1. Is att_fota poll expected to work with the new OTA Release / Cohort / Activation workflow?
2. Is the Asset Tracker Template expected to use the Memfault OTA path instead?
3. Is the rv=-5 from fota_download_any() a known issue or indicative of a missing configuration?
4. Are there any additional Kconfig settings required when using the new OTA Release system?

[Øyvind]

Hello,

We are currently in a transition phase between the legacy FOTA solution and the new FOTA implementation. The nRF Cloud team is actively working on updating the Asset Tracker Template (ATT) to use the new FOTA workflow.

As part of this transition, new users are routed to the Memfault UI for firmware updates. However, the current ATT documentation primarily describes the legacy FOTA flow. Despite this, users can still programmatically create and manage FOTA jobs through the legacy FOTA service using the available REST APIs.

For additional information, please refer to the ATT FOTA documentation: https://github.com/nrfconnect/Asset-Tracker-Template/blob/main/docs/common/fota.md

Let me know how this works for you.

Kind regards,
Øyvind

[Øyvind]

Just a small follow-up, there is a PR available for the update: https://github.com/nrfconnect/Asset-Tracker-Template/pull/719

If you follow that, you should be able to succeed.

Kind regards,
Øyvind

[Øyvind]

Can you please confirm how you are compiling and programming your device? Or are you using the Quick Start app in nRF Connect for Desktop?

Thanks! 

-Øyvind

[Nicholas Papachristos]

I am using the Thingy91X as a target device. SDK 3.4.0, and SDK Toolchain 3.4.0. VS-Code for building, build target thingi91x/nrf9151k/ns. I use the SEGGER j-link plus for programming and debugging.

Regarding the PR you mentioned, I implemented the changes. Currently debugging 

tfm_platform_s0_active(), to see why nither s0, nor s1 is valid. Will let you know how I progress.

[Nicholas Papachristos]

TF-M FW_INFO service rejects S0 and S1 image lookups.

FW_INFO request: address=00008000

ret=2

out.result=-1

 

FW_INFO request: address=0001C000

ret=2

out.result=-1

 

status2err:

TFM_PLATFORM_ERR_INVALID_PARAM

-> -EINVAL

-> -22

For Thingy91X / nRF9151 / NCS 3.4.0, are S0 (0x8000) and S1 (0x1C000) expected to be valid FW_INFO locations when accessed through TFM_PLATFORM_IOCTL_FW_INFO, or is the FOTA library using an incorrect assumption about the image layout?

tfm_platform_firmware_info() is called with:

S0 address = 0x00008000

S1 address = 0x0001C000

and both calls return: ret = TFM_PLATFORM_ERR_INVALID_PARAM (2)

out.result = -1

which is converted by status2err() to: -EINVAL (-22)

causing

tfm_platform_s0_active() -> -22

fota_download_b1_file_parse() -> -EIO

fota_download() -> -5

and finally:

nrf_cloud_fota_poll: Failed to start FOTA download, error: -5

All this while debugging....

          tfm_platform_firmware_info()

          tfm_platform_ioctl(TFM_PLATFORM_IOCTL_FW_INFO)

[Nicholas Papachristos]

The instrumentation shows that tfm_platform_firmware_info() fails for both S0 (0x8000) and S1 (0x1C000), with TFM_PLATFORM_ERR_INVALID_PARAM.

For Thingy91X/nRF9151 using NCS 3.4.0 and the Asset Tracker Template, should S0/S1 actually contain valid FW_INFO structures?

Or is fota_download_s0_active_get() incorrectly assuming an NSIB/S0/S1 bootloader topology while this device is using a standard MCUboot slot0/slot1 layout?

[Øyvind]

Hello, sorry for the delayed answer. I have forwarded your questions internally to get some feedback from our developers.

I hope to have an update within end of this week.

Kind regards,

Øyvind