Difficulty with Memfault UI managing FOTA images with different software_type values

[Regan0]

• Target device: nRF9151
• NCS 3.4.0
• Memfault Integrated
• FOTA architecture in place with four slots, 2 in internal flash and 2 in external flash
• Background COAP updates of both 2 independent images to external flash before overwrite to internal partitions

We need to manage FOTA updates for two different images on the same physical device. Each image has its own software_type and version and must be released independently. mcuboot has no problem with this arrangement. The images have different roles, where one of them corresponds to nRF's 'app' nomenclature.

So far, I have only been able to represent this in the Memfault UI by adding an extra hardware device. This workaround does not reflect the actual product architecture, since both images belong to and are installed on the same device. It's meant that my device-side FOTA handling has to pretend to be two different hardware devices (yukk!).

Could you please clarify:

• Is managing multiple independently versioned images on one device supported by the Nordic/Memfault integration? The REST API seems to indicate 'yes'.
• How should releases and deployments be configured when each image has a different software_type and version? I can't add an additional OTA payload with a software_type other than the primary. Even doing this through REST methods won't work.
• Is there a recommended way to target and track each image independently without creating a duplicate hardware device?
• Why are there limitations in the Memfault UI or Nordic integration that prevent this workflow?

Our desired model is:

• One physical device and hardware identity
• Two (or more) independently updatable images. 
• A distinct software_type and version for each image
• Independent FOTA release, targeting, status, and rollback tracking

Have I missed something? Is this a bug or intentional? If this is in the pipeline but not yet exposed, I would be grateful to know that it is coming and when. Any documentation or configuration examples for this use case would be appreciated. 

[NoahPendleton]

Hi Ryan-

Thanks for the question! We are in progress rolling out support for this use case.

Note that it will enable updating individual system components semi-independently, but we still tie the overall "Release" version to the "primary" software type (in your case, this would be `app`). So specifically what you describe here:

> Independent FOTA release, targeting, status, and rollback tracking

Is not exactly how it's expected to be used (though possible to work around, it won't make reporting as seamless). It's intended to enable updating non-primary software_type components separately from primary, but still treating the system version as a holistic unit identified by primary software version. Hopefully that makes sense! We'd be glad to have you try the feature when it's shipped, expected in next 1-2 days. I'll post back here when that's available.

Thanks!
Noah

[Regan0]

Any update to this, Noah?

After a break of a few weeks, I've returned to managing FOTA updates and I've found that my secondary software_type updates are no longer working through nRFCloud. These failed updates are carried out through NRF_CLOUD_DL_TYPE_DL_CLIENT instead of NRF_CLOUD_DL_TYPE_FOTA (which is still working). It is possible that I've broken something. The error I get is -111 (downloader connection refusal), which seems server-related to me.

Have any changes been made to FOTA management in nRFCloud in the past month?