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?

[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