SDK Internal Logging with Zephyr

Software Embedded
1

Hello,

I noticed that the SDK contains logging spread throughout the library using the MMLOG macros defined in mmlog.h. I was investigating an issue in which the MAC address used by the Zephyr module is different from the MAC address used in the demo application built from the CMSIS Pack / STM32CubeMX. I was hoping to enable SDK internal logging to discover the source of the new MAC address, but I’m not sure if the Zephyr application has enabled or implemented the correct OSAL functions and macros to support that.

I am using the Zephyr module from mm-iot-zephyr repo main branch, Zephyr Release 3.7.1, Zephyr SDK 0.16.9, and using the halow_client example application from within the module. I am building and flashing for the target board mm6108_ekh05_v3.

Do you have instructions for users of the Zephyr module to enable internal SDK logging?

Also, any clues about the different MAC Address are welcome too :smiley:

Thanks in advance!

2

Hi @RobMakesCents

Any MMLOG calls should be routed through to the implementation of mmosal_printf provided in the Zephyr module - which currently just prints the log. The default log level which is printed is MMLOG_LEVEL_ERR, which may be why you’re seeing a limited output.

While I haven’t tried it myself, adding MMLOG_LEVEL_DEFAULT=MMLOG_LEVEL_DBG to the zephyr_library_compile_definitions of components/morse_sm/libmorse/CMakeLists.txt should compile libmorse with a higher level of debug message.

In the future I would like the mmosal_printf implementation to leverage Zephyr’s logging subsystem instead, but that will require inspection of the string args passed in.

I will need to reproduce this myself to confirm the logic, but I believe this is just the Zephyr port following some legacy implementations - which blindly generated a locally assigned mac address of format 02:00:00:xx:xx:xx, where the last 3 octets are a device specific UID.
I believe the latest mm-iot-sdk and cmsis pack now reads the mac address stored in the MorseMicro chip, and only if this is not set correctly does it fall back to the locally assigned format.

I haven’t attempted this at all yet - but you could modify drivers/wifi/morse_sm/shims/mmhal.c to add #include <zephyr/net/ethernet.h> to the includes and replace mmhal_read_mac_addr with

void mmhal_read_mac_addr(uint8_t *mac_addr)
{
	uint32_t uid = mmhal_read_device_uid();

	if(net_eth_is_addr_valid((struct net_addr *) mac_addr))
		return;

	mac_addr[0] = 0x02;
	mac_addr[1] = 0x00;

	memcpy(&mac_addr[2], &uid, sizeof(uint32_t));
}

to use the mac stored on chip.

I can test this as well in a few days and if it works as expected we can get that change in :slight_smile:

3

Thank you for this suggestion! I was able to get SDK internal logging working by adding that compile definition. I also had to define mm_hexdump somewhere since the implementations in other shims were not compiled in. I added the following definition to mmosal_shim_zephyr.c, copied and slightly modified from the other shims built into the SDK.

diff --git a/components/morse_sm/libmorse/CMakeLists.txt b/components/morse_sm/libmorse/CMakeLists.txt
index deef8ae..7d70aff 100644
--- a/components/morse_sm/libmorse/CMakeLists.txt
+++ b/components/morse_sm/libmorse/CMakeLists.txt
@@ -105,6 +105,7 @@ zephyr_library_compile_definitions(
   MMOSAL_ASSERT\(...\)
   MMOSAL_ASSERT_LOG_DATA\(...\)
   MMOSAL_NO_DEBUGLOG
+  MMLOG_LEVEL_DEFAULT=MMLOG_LEVEL_INF
 )
 
 set_target_properties(libmorse PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${LIBMORSE_INCLUDES}")
diff --git a/drivers/wifi/morse_sm/shims/mmosal_shim_zephyr.c b/drivers/wifi/morse_sm/shims/mmosal_shim_zephyr.c
index a871d0f..ebb3068 100644
--- a/drivers/wifi/morse_sm/shims/mmosal_shim_zephyr.c
+++ b/drivers/wifi/morse_sm/shims/mmosal_shim_zephyr.c
@@ -658,4 +658,48 @@ int mmosal_printf(const char *format, ...)
 	ret = vprintf(format, args);
 	va_end(args);
 	return ret;
-};
\ No newline at end of file
+};
+
+/** Maximum length of buffer to dump inline before going to multi-line mode */
+#define DUMP_INLINE_MAXLEN    (8)
+#define DUMP_OCTETS_PER_GROUP (8)
+#define DUMP_OCTETS_PER_LINE  (16)
+
+void mm_hexdump(char level,
+                const char *function,
+                unsigned line_number,
+                const char *title,
+                const uint8_t *buf,
+                size_t len)
+{
+
+
+    mmosal_printf("%c %s %s[%d] %s", level, mmosal_task_name(), function, line_number, title);
+
+    if (len <= DUMP_INLINE_MAXLEN)
+    {
+        while (len--)
+        {
+            mmosal_printf(" %02x", *buf++);
+        }
+        mmosal_printf("\n");
+    }
+    else
+    {
+        unsigned ii;
+        for (ii = 0; ii < len; ii++)
+        {
+            if ((ii % DUMP_OCTETS_PER_LINE) == 0)
+            {
+                mmosal_printf("\n");
+            }
+            else if ((ii % DUMP_OCTETS_PER_GROUP) == 0)
+            {
+                mmosal_printf(" ");
+            }
+
+            mmosal_printf(" %02x", buf[ii]);
+        }
+        mmosal_printf("\n");
+    }
+}
\ No newline at end of file

Thank you for the suggestion for loading the correct WLAN interface MAC address. That modification uses the MAC stored on the chip, matches the MAC etched into the module’s shield, and the MAC I observed when testing with the default SDK demo firmware. Below are the changes I made based on your suggestion:

diff --git a/drivers/wifi/morse_sm/shims/mmhal.c b/drivers/wifi/morse_sm/shims/mmhal.c
index b41fc84..3239dfe 100644
--- a/drivers/wifi/morse_sm/shims/mmhal.c
+++ b/drivers/wifi/morse_sm/shims/mmhal.c
@@ -14,6 +14,7 @@
 #include "mmhal.h"
 #include "mmosal.h"
 #include "mmwlan.h"
+#include <zephyr/net/ethernet.h>
 
 static volatile atomic_uint_fast32_t deep_sleep_vetos = 0;
 extern const struct device *morse_dev;
@@ -63,6 +64,10 @@ void mmhal_read_mac_addr(uint8_t *mac_addr)
 {
 	uint32_t uid = mmhal_read_device_uid();
 
+	if (net_eth_is_addr_valid((struct net_eth_addr *) mac_addr)) {
+		return;
+	}
+
 	mac_addr[0] = 0x02;
 	mac_addr[1] = 0x00;
2 Likes