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 