Skip to main content
Associate
October 1, 2026
Question

MX_WIFI_Socket_setsockopt() rejects MX_SO_BLOCKMODE (0x1000) on EMW3080 - non-blocking sockets unusable; select() is a stub

Hi,
I am developing application on B-U585I-IOT02A (STM32U585), using mx_wifi component V2.3.3 (SPI transport, socket mode MX_WIFI_NETWORK_BYPASS_MODE == 0), EMW3080B module firmware V2.3.4, bare-OS shim, link associated and DHCP lease verified before every test.
Symptom. MX_WIFI_Socket_setsockopt() returns -1 immediately for MX_SO_BLOCKMODE (0x1000) at level MX_SOL_SOCKET (0xfff). The refusal is value-invariant: optval 0 and 1 behave identically (0 would request the module's default state), and OptLen 1, 2 and 4 all fail — so the option name, not the payload, is rejected. MX_WIFI_Socket_getsockopt() on the same option is refused as well, so the effective mode cannot even be read back. Mainstream options on the same socket (MX_SO_REUSEADDR, MX_SO_SNDTIMEO, MX_SO_RCVTIMEO) succeed.
Minimal repro

int32_t sock = MX_WIFI_Socket_create(obj, MX_AF_INET, MX_SOCK_STREAM, MX_IPPROTO_TCP);
int32_t optval = 1;                        /* 1 = non-blocking */
int32_t ret = MX_WIFI_Socket_setsockopt(obj, sock, MX_SOL_SOCKET, MX_SO_BLOCKMODE,
                                        &optval, sizeof(optval));
/* FAILS HERE: ret == -1 immediately, for optval 0 and 1 alike */

For my application it is important because other library that i am using recommend socket to be non blocking, for now it works with blocking implementation, but I would like to determine the reason.
Has anyone got MX_SO_BLOCKMODE accepted on the EMW3080 (any module firmware version), or can ST confirm whether the option is implemented in the module firmware for plain TCP sockets? Is there another sanctioned non-blocking read/write mechanism?
Wi-Fi component: https://github.com/STMicroelectronics/stm32-mx-wifi