TCP/IP server and client with esp32-s3

General
1

Hello everyone,

I’m currently working on a project to understand how to communicate using WiFi HaLow. For now, my goal is to learn the basics of communication by setting up a TCP/IP server and a client.

I’m using:

  • 2 MM6108-MF08651-US modules, each connected to an XIAO ESP32-S3.
    • One module is in AP (Access Point) mode to host the server.
    • The other is in STA (Station) mode to send requests.

I found a component from MorseMicro that is still under development: MorseMicro/halow. I’m basing my project on the softAP and sta_connect examples provided in their repository.

However, I’m unable to send or receive any messages between the two devices.

Here’s how my project is structured:

AP / TCP-IP Server

main/
├── app_main.c       (main entry point)
├── halow_ap.c       (copied from the softAP example)
└── tcp_server.c     (TCP server implementation)

STA / TCP-IP Client

main/
├── app_main.c       (main entry point)
├── halow_sta.c      (copied from the sta_connect example)
└── tcp_client.c     (TCP client implementation)

IP Address Assignment:

  • I’m confused about how IP addresses are determined in this setup.
  • I don’t think there’s a DHCP server assigning IP addresses automatically.
  • I’m unsure what the default configuration values are for the IP addresses.

Library Usage:

  • Can I use other ESP-IDF libraries (e.g., lwIP) alongside the MorseMicro mm_* libraries?
  • Or do I have to stick exclusively to the mm_* libraries for WiFi HaLow communication?

I’m completely lost with all of this. If anyone has experience with WiFi HaLow or similar setups, I’d appreciate guidance on:

  • How the architecture should be structured.
  • How to properly initialize each block (AP, STA, TCP server/client).
  • Whether I need to manually configure IP addresses or if DHCP is required.

Any insights or examples would be incredibly helpful!

2

@Benyeh the examples from the MorseMicro/halow component that you reference are your best starting point. This component brings our driver in as a netif interface in ESP-IDF. So the same functions to connect, set IP, etc from regular WiFi via netif work with our driver. You can use our mm_* API functions for HaLow or Morse Micro specific things like enable/disable power save, get RSSI, etc.

Here’s a link to the ESP-IDF docs on netif that should help you along with following along our examples.

3

You will either need to configure the IP address statically, or enable the ESP NETIF DHCP server ESP-NETIF Programmers Manual - ESP32 - — ESP-IDF Programming Guide v6.0.2 documentation

In general you should be able to use the esp libraries, and the mm API will generally be a shim layer between, or for core halow components

4

@david.rice @ldennis Hello, thanks for your replies. I figured out that the netif on my AP was down after configuration. However, it seems like there is only one configuration in the mmhalow_init() which is ESP_NETIF_DEFAULT_WIFI_STA(). This default configuration does not enable the flag ESP_NETIF_FLAG_AUTOUP which provokes the netif to be down in AP mode.

Does it means that only the STA mode ?

I tried to modify the mmhalow.c file to manually change the flag between esp_netif_config_t cfg = ESP_NETIF_DEFAULT_WIFI_STA(); and esp_netif_t *netif = esp_netif_new(&cfg); like this :

esp_netif_config_t cfg = ESP_NETIF_DEFAULT_WIFI_STA();
esp_netif_inherent_config_t base = *cfg.base;
base.flags |= ESP_NETIF_FLAG_AUTOUP;
cfg.base = &base;
esp_netif_t *netif = esp_netif_new(&cfg);

But I have a new error when the client is trying to communicate with the tcp server :

E 14243 ti mmwlan_tx_pkt[1253] Unable to infer VIF ID
E (14726) Morse Micro HaLow NetIF: Packet failed to send - 12

I don’t really understand this error, do you know what could be the origin of this ?

5

Good to hear you made some progress. The AP mode support integration into mmhalow is quite new, so there is likely some little issues like you’ve identified. I’ll pass those on to the team.

This suggests your system has started both an AP and a STA interface.

You’ll want to only start the AP interface. Are you calling mmhalow_connect somewhere in your AP app?

6

This default configuration does not enable the flag ESP_NETIF_FLAG_AUTOUP which provokes the netif to be down in AP mode.

I don’t think you actually want this, the AP will signal to the netif when it is up. This might be an issue with the STA and the AP.

I’ll talk to the team that maintains the ESP halow port, but for now can you see if you are calling mmhalow_connect and if so remove the call?

7

Hi!

I didn’t have mmhalow_connect anywhere in my code. However, after printing a lot of debug information, I managed to identify the problem and find a quick fix.

It is not very elegant, but I changed two lines in mmhalow.c:

  • In mmhalow_init() , I changed esp_netif_config_t cfg = ESP_NETIF_DEFAULT_WIFI_STA();to ESP_NETIF_DEFAULT_WIFI_AP();
  • In halow_transmit(), I added the .vif parameters as follows :
struct mmwlan_tx_metadata metadata = {
        .tid = 0,
        .vif = MMWLAN_VIF_AP,
    };

So, I am forcing everything to use the AP virtual interface instead of the STA one. Or at least that is how I understand it. ^^’

This may be unrelated, but I sometimes get the following error message (was already getting it before):

E      780 dr morse_pageset_write[458] Failed to write page: -32768
E      780 dr morse_pageset_tx[786] morse_pageset_tx could not write 1 pkts - rc=-32768 items=1 pages=1

I don’t really understand where it is coming from, and it does not happen every time. If I reset the card or close and reopen “Monitor Device,” the error usually disappears, although this behavior seems quite random.

8

Hmm thinking on it more, I think I know why you are hitting the VIF issue (minor bug on our end) but the fix you’ve identified of explicitly signalling that the frame is for the AP VIF is correct. I believe we do this in the mmnetif shim in the standard SDK, and this must have been missed in the ESP port. We’ll get that one tidied up on our end, thanks for reporting back.

Regarding the pageset error message, this is a known issue that was resolved in 2.12 - the SDK has been released and we should have the 2.12 ESP port up soon. For now you can “ignore” the error

9

The 2.12 port is available on our GitHub’s main branch. This is still in a development cycle so it’s not ready for tagging on the registry yet, but it’s available for use.

10

I tried to follow your advice. I deleted the previous HaLow component, downloaded the latest version of esp-halow, and added it as an external component. (By the way, I also downloaded the latest version of mm-iot-sdk because it was empty when I downloaded esp-halow from GitHub.)

I managed to remove the component from idf_component.yml and update my CMakeLists.txt, but I’m still getting the same error.

It’s not a big deal but I just wanted to check whether everything I did was correct or if I missed something.

11

Sorry, I misspoke - there was a similar error we would see on our MM8108 chip which we fixed.

You may occasionally see it on the MM6108 - it won’t be catastrophic and you should be able to ignore it.
We’ve got a note of this one to investigate internally.