memfault_zephyr_log_backend_disable is called here:

Even when CONFIG_MEMFAULT_LOGGING_ENABLE=n, resulting in compilation errors.

This line selects a Kconfig option, LEGACY_INCLUDE_PATH, that was removed after the release of Zephyr v3.3.0: zephyrproject-rtos/zephyr@9b30667.

There is a workaround implemented in memfault's CMakeLists.txt that should make the select statement redundant.

Zephyr commit zephyrproject-rtos/zephyr@77d2490 renamed this function.

This is breaking the build at least in ports/zephyr/v2.4/memfault_fault_handler.c:

static int prv_install_nmi_handler() {
  extern void z_NmiHandlerSet(void (*pHandler)(void));
  z_NmiHandlerSet(MEMFAULT_EXC_HANDLER_NMI);
  return 0;
}

I'm not sure what the right fix is -- perhaps a new ports/zephyr/v3.4 which uses the new name, z_arm_nmi_set_handler?

Hi,

I'm using nRF9160 on nRF Connect SDK version 2.3.0. We have had some problems with Memfault cloud where the connecting or data sending is taking too much time and the watchdog kicks in and reboots the device.

Could the connect() function be separated from the prv_configure_socket() function? So when the socket would be opened first by calling memfault_zephyr_port_http_open_socket(), then I would be able to setup socket timeouts and then call the new function memfault_zephyr_port_http_connect().

I have some kind of proposal about this:

ports/zephyr/common/memfault_platform_http.c

static int prv_configure_socket(int fd, const char *host) {
...
  return 0;
}

int memfault_zephyr_port_http_connect(sMemfaultHttpContext *ctx) {
  if (ctx->sock_fd < 0) {
    memfault_zephyr_port_http_close_socket(ctx);
    return -1;
  }

  return connect(ctx->sock_fd, ctx->res->ai_addr, ctx->res->ai_addrlen);
}

I think this would require some other code changes too but this would be really nice to have.

enum MfltResetReason is missing an explicit reason for rebooting due to a stack overflow, which is both relatively common and has dedicated hardware to detect this error (see https://docs.zephyrproject.org/latest/hardware/porting/arch.html#hw-based-stack-overflow-detection)

The legacy workaround kconfig (CONFIG_LEGACY_INCLUDE_PATH) has been removed with v3.4 (zephyrproject-rtos/zephyr@9b30667).

The Memfault SDK is globally undoing that change with the following lines:

The default memfault_fault_handler, which is called by the wrapped __wrap_z_fatal_error, reboots the device unconditionally without calling __real_z_fatal_error. z_fatal_error is responsible for calling k_sys_fatal_error_handler, which user applications can hook into to be notified of the error.

memfault_platform_fault_handler is not a sufficient solution as the fault reason has already been abstracted away to kMfltRebootReason_HardFault, and only works when CONFIG_MEMFAULT=y.

Personally, k_sys_fatal_error_handler is used to preserve the current civil time and other metadata across reboots.

Ideally there would be a CONFIG_MEMFAULT_FAULT_HANDLER_RETURN which would remove the reboot call at the end of memfault_fault_handler, with __wrap_z_fatal_error calling __real_z_fatal_error after memfault_fault_handler

It appears that the partition NVMS_LOG_PART is hardcoded and was intended to be swapped with MEMFAULT_PLATFORM_COREDUMP_STORAGE_PARTITION in the code but wasn't.

See:
1a64c90#diff-1b48dc0a21698d35d6e9d452f6a0177c4914d391f245db0d81b2d8a68794ab5aR117

1a64c90#diff-1b48dc0a21698d35d6e9d452f6a0177c4914d391f245db0d81b2d8a68794ab5aR124

For Zephyr ports, Memfault expects the RTC device to be node named rtc. e.g.

rtc: rtc_foo@address {
    compatible = "vendor,rtc_foo";
    reg = <address>;
    status = "okay";
};

When using an external RTC we will encounter issues in the base address validation on nrf parts, e.g.

zephyr/soc/arm/nordic_nrf/validate_base_addresses.c:218:19: error: 'NRF_RTC' undeclared here (not in a function); did you mean 'NRF_RTC0'?
  218 | CHECK_DT_REG(rtc, NRF_RTC);

I propose ( #69 ) that we add a fallback to allow using an alias if the node is not found. This should provide backwards
compatibility and support external RTCs simultaneously.

Zephyr-Sdk: 0.16.5
nrfconnect: v2.6.0
Memfault SDK: 1.6.0

Hello,

I'm looking to use memfault on a project with a ESP32-S2. Do you know if the memfault SDK is compatible ?

Thank you ! :)

Zephyr 3.5 deprecated rand32.h, the new include is random.h, this needs to be updated in ports/zephyr/common/memfault_http_periodic_upload.c

There's a reference to a file named MemfaultWorker.cmake in the header of the Memfault.cmake file, a similar file named MemfaultWorker.mk is located in the makefiles directory.

Hi memfault maintainer

Does memfault support storing coredump information in FLASH for the Zephyr OS? I noticed that the coredump information is

currently stored in the noinit RAM region, but I'm wondering if there is support for storing it in FLASH instead.

Thanks，
Dingisoul

Hi,

We are using memfault SDK for our internal application that uses zephyr rtos. We followed the instructions here: https://docs.memfault.com/docs/mcu/zephyr-guide/

The zephyr RTOS version is 3.4.0, we find the following build error:

are-sdk__ports__zephyr.dir/common/memfault_platform_core.c.obj -MF modules/memfault-firmware-sdk/CMakeFiles/..__modules__lib__memfault-firmware-sdk__ports__zephyr.dir/common/memfault_platform_core.c.obj.d -o modules/memfault-firmware-sdk/CMakeFiles/..__modules__lib__memfault-firmware-sdk__ports__zephyr.dir/common/memfault_platform_core.c.obj -c /root/zephyrproject/modules/lib/memfault-firmware-sdk/ports/zephyr/common/memfault_platform_core.c
/root/zephyrproject/modules/lib/memfault-firmware-sdk/ports/zephyr/common/memfault_platform_core.c:159:22: error: expected ')' before numeric constant
  159 |          APPLICATION,
      |                      ^
      |                      )

I noticed since a recent SDK upgrade to 0.24.1 we are getting a couple of these build warnings in memfault-firmware-sdk/components/panics/src/memfault_fault_handling_arm.c:

#1585-D function declared with "noreturn" does return

I'm using CCS 10.1 and TI CC2652

In memfault_heap_stats_free, there is not a check to make sure the heap item pointer is actually in use. It is only checking the pointer against the items in the stats pool. However, there can be multiple items with the same address in the pool (of which only one is currently in use). This free check doesn't account for that and will exit after the first entry that it sees.

Here is the simple case where this happens:

alloc() --> return address X
free(P1)
alloc() --> return address X --- Now the heap stats will have 2 entries for items at address X, one is in_use and the other is not.
free() --> The heap stats will now be incorrect as it will mark the first entry (which is already not in use) and skip the second entry.

An example of what could fix the issue:

--- a/components/core/src/memfault_heap_stats.c
+++ b/components/core/src/memfault_heap_stats.c
@@ -93,7 +93,7 @@ void memfault_heap_stats_free(const void *ptr) {
 
     // if the pointer exists in the tracked stats, mark it as freed
     for (size_t i = 0; i < MEMFAULT_ARRAY_SIZE(g_memfault_heap_stats_pool); i++) {
-      if (g_memfault_heap_stats_pool[i].ptr == ptr) {
+      if (g_memfault_heap_stats_pool[i].ptr == ptr && g_memfault_heap_stats_pool[i].info.in_use == 1) {
         g_memfault_heap_stats_pool[i].info.in_use = 0;
         break;
       }

I tried out this example on the nRF52840 DK:

https://github.com/memfault/memfault-firmware-sdk/tree/master/examples/nrf5/apps/memfault_demo_app

I found that it seems to hang and get unresponsive after the first run after reset. It will hang for about 10 seconds then it gets reset by the watchdog. After that it becomes responsive and the CLI will work.

Also, I was only every able to see one entry in the core storage at 0xA1000 when reading memory with the debugger, but maybe I didn't look far enough in as I don't know how much space is reserved per core dump entry.

I don't know if I'm supposed to load the softdevice or not with this example. I don't think I had it loaded.

I built it using Ubuntu 20.04.01 LTS on WSL.
gcc-arm-none-eabi 15:9-2019-q4-0ubuntu1 (default gcc-arm on Ubuntu)

Hi memfault maintainer,

Does memfault have support for storing coredump information in FLASH for the Zephyr OS? Currently, I see that the coredump information is stored in the noinit RAM region, but I've noticed that other ports have implemented flash support. I'm wondering if the coredump data in the noinit RAM region will be deleted if the power supply is lost. It would be great to have support for storing the coredump information in FLASH instead.

Thanks,
Dingisoul