✔️ Enable memfault integration

[coderbyheart]

https://memfault.com/ is available from NCS 1.6 on.
Add option to enable it for customers that want to use it.

Memfault supports these "modules"

• Coredumps: there is little benefit of publishing them through the cloud (except for not needing to configure the memfault project key), because they are large and the publication happens after a reboot, before the application starts.
• Reboot Reason Tracking is similar. It's a once-per-reboot occurance and can be sent alongside the coredump (if one exists), or standalone at the start of the application.
• Device Metrics and Trace Events will benefit from sending via the active cloud connection, because they occure during the normal application operation. Here it will be valuable to re-use the existing cloud connection.
  • we collect some device metrics already (like RSRP, Battery voltage), because they are relevant to the user, but metrics like memory consumption, modem connection time, are some candidates that are interesting for the manufacturer and it will also be valuable to visualize them alongside firmware version information in memfault.

However, there is a benefit of sending all memfault data through the cloud connection: it provides per-device based authentication (using the device credentials), while device-to-memfault requests are authenticated with a global project key. Using the cloud connect would allow to have more fine-grained control over which devices are sending data into memfault, and also allow to change the project that a device is reporting to at runtime on the cloud side, because currently the memfault project setting is hardcoded at compile time using the CONFIG_MEMFAULT_NCS_PROJECT_KEY KConfig option.

Proposal for memfault integration

Device information

Meta information about devices is populated by cloud when devices report their values

• board type (hardware_version) is inferred cloud side from dev.v.brdV
• nickname is inferred from the user's name setting for the device

Chunks

Because the memfault SDK packages the data from all modules in chunks, using the cloud connection applies to all modules.

Memfault embeds offset information in each chunk so they can re-assemble data that arrives out of order, no need to buffer chunks on the cloud side.

Device publishes the chunks to memfault.

• the outgoing message size must not exceed the 2 KB size limit of the secure socket buffer; if more chunks need to sent, multiple MQTT messages are to be sent
• the Memfault SDK can create chunks of the size up to the possible message size (2k), so each message will only include one chunk, but chunks can contain multiple modules. This minimizes the number of MQTT messages to be sent.
• memfault embeds offset information in each chunk so we can re-assemble data that arrives out of order on our side
• device ID is inferred cloud side from the connection
• memfault project key needed for chunks API is stored cloud side in an SSM parameter (AWS) or in Keyvault (Azure)

See:

• Uploading Data With MQTT
• Data from Firmware to the Cloud: Advanced Operation Mode

Implementations

• AWS
• Azure