Two HT-HC33 boards communicating over HaLow without a gateway — is AP mode possible?

Software Embedded
1

Hi, I’m trying to get two HT-HC33 boards (ESP32-S3 + MM6108) communicating directly over HaLow without a gateway using mm-iot-esp32 v2.10.4 with ESP-IDF v5.1.4.

The MM6108A1 chip initializes correctly, firmware 1.17.6 loads, and mmwlan_ap_enable() returns success with the message “AP Mode started successfully”. However, a HaLow scan from the second HC-33 finds 0 networks — the AP is not actually beaconing.

I believe the issue is a linker conflict: ESP32-S3’s built-in esp_wifi and esp_phy components pull in wpa_supplicant which has duplicate symbols with Morse Micro’s hostap library. Without --allow-multiple-definition the build fails. With it, the build succeeds but the radio doesn’t transmit.

Has anyone successfully built and run the ap_mode example on an ESP32-S3 board with ESP-IDF v5.1.4? How do you handle the wpa_supplicant/hostap symbol conflicts?

Thanks

2

Try the latest version of mm-iot-esp32, I did same test with HT-HC33, it works for me.

3

Thanks! I’m already on 2.10.4 which appears to be the latest. What ESP-IDF version are you using, and did you have to do anything special to resolve the wpa_supplicant/hostap symbol conflicts during the build? I’m on ESP-IDF v5.1.4 and the only way I can build is with --allow-multiple-definition, but that causes the AP to not actually beacon

4

Hey @pikachu

Make sure you add CONFIG_BUILD_SUPPLICANT_FROM_SOURCE=y to your sdkconfig for your project. In the 2.10.4 release of mm-iot-esp32 this will compile hostap/supplicant from source and, importantly, run a python script over part of the compilation to “mangle” some symbols.

Also keep in mind that we will be deprecating mm-iot-esp32 very soon in favour of a package in the Espressif component registry. See morsemicro/halow • v2.10.4-esp32-2 • ESP Component Registry