ST67W611M1U AT firmware 1.0.0.1 — static station IP not applied, SPI/AT hang after DHCP and under load, and undocumented SPI RDY timing
Hello,
We are using two ST67W611M1U modules (no on-module antenna; external 2 dBi dipole on MHF4) with an STM32H563ZG host, bare-metal, SPI host interface at 10 MHz (the same behaviour was reproduced at 20 and 40 MHz). AT firmware reports AT version:1.0.0.1 (Sep 4 2025 11:32:47), macsw 1.6.44; we are working from the Web AT Documentation v2.0.106.
Topology: one module runs as SoftAP (AT+CWMODE=2, AT+CWSAP="…","…",1,3,4,0, AT+CIPMUX=1, AT+CIPSERVERMAXCONN=3, AT+CIPSERVER=1,5000,"TCP", AT+CIPRECVMODE=1), with two stations attached: a second ST67 module and a Windows PC. Steady-state traffic is about 36 kB/s outbound from the AP to the PC (AT+CIPSEND=<link>,1024, ~40 per second) plus about 10 kB/s inbound from the second module (passive receive, one AT+CIPRECVDATA of ~1 kB per 100 ms).
We have collected several hundred boot/join cycles with full host-side logs and would appreciate answers or pointers on the following points.
1. Static station IP is never applied to the interface. On the station module we issue AT+CWDHCP=0,1 and then AT+CIPSTA="192.168.4.250","192.168.4.1","255.255.255.0", both answered with OK, followed by AT+CWJAP. Before joining, AT+CIPSTA? returns 192.168.4.250. After +CW:CONNECTED, AT+CIPSTA? returns ip:"0.0.0.0", the AP's AT+CWLIF lists the station as 0.0.0.0,<mac>, and every AT+CIPSTART to the AP fails immediately with ERROR (27 of 27 attempts). Issuing AT+CIPSTA again after +CW:CONNECTED makes no difference. Switching the station back to DHCP connects normally. Is a static station address supported in AT 1.0.0.1? If so, what is the required command order (CWDHCP / CIPSTA / CWJAP, and SYSSTORE setting)? If this is a known defect, in which release is it fixed?
2. SPI host-interface timing limits are not documented. We could not find, in the datasheet, the user manual or the AT documentation, any maximum for (a) the time from CS assertion to RDY going high, (b) the time from an AT response or +IPD event becoming available to RDY going high, or (c) the time from CHIP_EN release to the first RDY. In practice, during the data phase of AT+CIPSEND under TCP backpressure we have measured RDY taking well over 50 ms to rise, so our host watchdogs are currently set by trial (250 ms per command phase, 6 s per transaction) rather than by specification. Could you provide the guaranteed worst-case values, and confirm whether RDY is guaranteed to pulse (fall and rise again) for every frame the module has to deliver? We have observed a single rising edge when the module holds both a > prompt and a +IPD notification, which suggests RDY is level-only in that case.
3. Station module becomes deaf on SPI immediately after DHCP completes. When the station module joins the ST67 SoftAP with DHCP, in 21 of 33 join attempts RDY never rises again within roughly 1–500 ms after +CW:GOTIP. All subsequent AT commands go unanswered, there are no SPI framing errors, and the Wi-Fi association and DHCP lease remain valid (the AP's AT+CWLIF still lists the station with its leased address). Only a CHIP_EN restart recovers the module. The failure does not occur when the station is configured with a static address (0 of 7), which unfortunately is not functional (point 1). Low-power settings, PMF, and credential storage were ruled out as factors. Is this a known issue? Could the lease-persistence path (flash write after DHCP bind) be interfering with the SPI slave? Is there a firmware release that addresses it, or a workaround such as disabling lease storage?
4. AT engine hangs silently under combined SoftAP load. With the traffic described above, after 5–16 s the module stops delivering +IPD notifications, the next AT+CIPSEND never returns the > prompt, RDY stays low, and no ERROR or busy indication is ever produced. The time to failure is inversely proportional to the AT transaction rate: at ~290 transactions/s it failed in ~5 s, at ~120/s in ~16 s, and at ~50/s (after enlarging our receive chunk to one CIPRECVDATA per 1 kB frame) a 291 s run completed without error. The same hang has also occurred at idle when stations repeatedly connect and disconnect. SPI clock has no influence. What are the module's socket/pbuf buffer limits and the recommended maximum AT transaction rate? Is there a command to query buffer occupancy? Is silent hang, rather than ERROR, the expected behaviour on buffer exhaustion? Would active receive mode (AT+CIPRECVMODE=0) reduce the load, and what are the official maxima for a single CIPSEND length and for one SPI frame (we currently assume 1,280-byte frames)?
5. SoftAP DHCP server leased the same address to two stations. With the default DHCP server settings, both stations received 192.168.4.2 (confirmed by AT+CWLIF and by ARP conflicts on the PC), so the second station could not open TCP. Setting an explicit pool with AT+CWDHCPS=1,3,"192.168.4.2","192.168.4.20" resolved it. Is this a known defect of the default pool, and is the lease table cleaned up when a station with the same MAC reconnects?
6. Configuration commands we could not find in v2.0.106. Setting/querying transmit power (dBm), country code, disabling station power save, and SoftAP DTIM/beacon interval. Do these exist, and what is the syntax?
7. Firmware. Is there a newer NCP/AT binary for the ST67W611M1U than 1.0.0.1 (2025-09-04), with release notes indicating which of the points above are addressed, and what is the recommended flashing procedure?
We can provide host-side logs (AT transcripts with timestamps, SPI diagnostics counters) and Wireshark captures for any of the points above.
