Skip to main content
jiwony_pitchlab
Explorer
September 30, 2026
Question

ST67W611M1 AT 1.0.0.1 (sdk 2.0.106): station module stops serving the SPI host exactly 60 s after AT+CIPSTART, independent of traffic

  • September 30, 2026
  • 0 replies
  • 20 views

Hello,

We use two ST67W611M1 modules with STM32H563 hosts (bare-metal, SPI host interface at 10 MHz; reproduced at 20 and 40 MHz as well). Both modules run the NCP/AT build reporting AT version:1.0.0.1 (Mar 20 2026 09:32:19), sdk 2.0.106. One module is a SoftAP with a TCP server, the other is a station that opens one TCP client link to it.

We have a reproducible failure on the station module that we would like you to look at, because its timing is too regular to be load-related.

Symptom. Exactly 60 s after AT+CIPSTART succeeds (about 62 s after +CW:CONNECTED), the station module stops serving the SPI host: the next AT+CIPSEND=0,<n> never gets its > prompt, the RDY (data-ready) line stays low, and every subsequent AT command goes unanswered. There are no SPI framing errors on our side (header sync and length checks are clean up to the last frame). The Wi-Fi association and the DHCP lease survive — the AP module's AT+CWLIF still lists the station — so it is the SPI/AT service inside the module that has stopped, not the radio. Only a CHIP_EN restart recovers it. After the restart the station rejoins, reconnects, and fails again 60 s later, indefinitely: in one 11-minute run we counted nine cycles of 71 s (60 s alive + 11 s restart/rejoin).

Measured time from AT+CIPSTART OK to the first unanswered AT+CIPSEND: 59.0, 60.0, 60.0, 60.0 s in four consecutive cycles on 2026-09-30, and 61, 62 s in an earlier run (our status log has 1 s granularity).

What does not change it.

  • Traffic: it happens identically while the host is streaming 10 × 1013-byte CIPSENDs per second, and while it is sending only one 28-byte CIPSEND per second.
  • AT+PWR=0 issued after the join (station power save off) — no change.
  • The AP's DHCP lease time (AT+CWDHCPS=1,3,… vs =1,20,…) — no change, so it is not a DHCP renewal.
  • SPI clock 40 / 20 / 10 MHz — no change.
  • Host CS timing: we instrumented the interval between CS release and the next CS assert; in the second before the failure it is the same as at any other time (min 64 µs, mean 10–18 ms, max 98 ms).
  • Signal: the two modules are on the same bench, station-side RSSI −24 dBm.

AT sequence on the station, as issued (from our host log):

AT+CWMODE?  /  AT+CIPAP?  /  AT+SYSSTORE?          (probes)
AT+SYSSTORE=0
AT+CWMODE=0
AT+CIPRECVMODE?  /  AT+CIPDINFO?                     (probes)
AT+CWMODE=1
AT+CWDHCP=1,1
AT+CWJAP="<ssid>","<password>"      -> +CW:CONNECTED, +CW:GOTIP, OK
AT+CIPSTA?  (x3 during a 1.2 s settle)  -> 192.168.4.2
AT+PING="192.168.4.1",32,1  (x3 in total)
AT+PWR=0
AT+CIPRECVMODE=1
AT+CIPMUX=1
AT+CIPCLOSE=0                         (ERROR, ignored — issued defensively)
AT+CIPSTART=0,"TCP","192.168.4.1",5000   -> 0,CONNECT / OK        <- T0
steady state: AT+CIPSEND=0,<n> + payload; AT+CIPRECVDATA=0,1232 on +IPD; AT+CWJAP? every 5 s (RSSI)
T0 + 60 s: AT+CIPSEND=0,28 -> no ">" prompt, RDY stays low, module silent from here on

AP side: AT+CWMODE=2, AT+CWSAP="<ssid>","<password>",1,3,4,0, AT+CWDHCPS=1,20,"192.168.4.2","192.168.4.20", AT+CIPMUX=1, AT+CIPSERVERMAXCONN=3, AT+CIPSERVER=1,5000,"TCP", AT+CIPRECVMODE=1, AT+SYSSTORE=0.

Questions.

  1. Is there anything in the station firmware that runs 60 s after a TCP connection or association is established — a background/roaming scan, a keep-alive, a power-management re-negotiation, a periodic flash write — that could block the SPI slave task? The regularity points to a timer rather than to buffer exhaustion.
  2. Is there an AT command in this build to disable such periodic activity (background scan interval, roaming, TCP keep-alive, TWT), or a setting that changes the 60 s?
  3. Is the module expected to recover on its own from this state, and is there a host-side way to recover it other than CHIP_EN? (On the AP-side module we once saw the same signature clear by itself after ~10 s; on the station it never has.)
  4. Is this a known issue, and is it addressed in a newer NCP release than sdk 2.0.106?

For completeness: the AP-side module occasionally shows the same signature (no > prompt, RDY low) under combined load of ~36 kB/s outbound plus ~16 kB/s inbound, after several minutes, but without the 60 s regularity; that case is described in our earlier post.

We can provide full timestamped host logs (AT transcripts, SPI diagnostics, the CS-interval statistics) and a Wireshark capture of the station's link for any of the runs above.

Thank you, Jiwon

Terms & ConditionsAccessibility statement