ST67W611M1 (T01) – AT+BLESCAN starts failing (ERROR / TIMEOUT) after ~20–70 min of repeated scan stop/start; only a module reset recovers

[orb]

• Host MCU: STM32G491METx, FreeRTOS, SPI host interface (SPI_RDY on EXTI, CHIP_EN controlled by host)
• Module: ST67W611M1, T01 binary (LwIP offload profile)
• Host middleware: X-CUBE-ST67W61, ST67W6X Network Driver v1.3.0
• Clock: W6X_CLOCK_MODE = 1 (internal RC); W6X_POWER_SAVE_AUTO = 0 (also tested with 1; the driver disables it in W6X_Ble_Init because of the RC clock)
• BLE only, no Wi-Fi in use

Use case

The module is used only as a BLE observer. It continuously scans for manufacturer-data advertisements from 2 ble devices, among a crowded environment (40+ devices around).

• W6X_Ble_Init(W6X_BLE_MODE_DUAL, …)
• W6X_Ble_SetScanParam(ACTIVE, PUBLIC_ADDR, FILTER_ALLOW_ALL, interval 105 (65.6 ms), window 104 (65 ms))
• W6X_Ble_StartScan(cb)
• W61_BLE_SCAN_TIMEOUT reduced from 5000 to 1000 ms, and W61_BLE_MAX_DETECTED_PERIPHERAL = 40
• On every scan-done callback the application calls W6X_Ble_StopScan() and then W6X_Ble_StartScan() immediately. This gives one stop/start cycle every ~0.35–1 s, i.e. thousands of cycles per hour.

Problem

After ~2,700 to ~10,000 stop/start cycles (20–70 min), the module starts refusing scan commands. We have seen three variants:

1. AT+BLESCAN=0 returns OK, the following AT+BLESCAN=1 returns ERROR, and every later stop/start returns ERROR.
2. AT+BLESCAN=0 returns OK, and AT+BLESCAN=1 gets no response (timeout).
3. Every AT command returns ERROR, including non-BLE ones (e.g. the NCP heap-state query).

In all cases:

• The SPI link is alive: replies are received, SPI_RDY is behaving, and no SPI transport errors were seen.
• The ST67 heap (W61_GetNcpHeapState) is stable at ~36 KB before and during the failure, so it doesn't look like a memory leak.
• The host heap and stack are stable.
• The state never clears by itself. Only a full power-cycle via CHIP_EN plus a complete re-init (W6X_DeInit / W6X_Init / W6X_Ble_Init) recovers it.
   

  Questions

• Is this a known issue in the T01 BLE scan handling? Is it fixed in a newer T01 release?
• AT+BLESCAN=0 returns OK right away. Is the scanner actually stopped at that point? Is there a minimum delay required before AT+BLESCAN=1, or an event that signals the stop is complete? The p2pClient example waits 2 s, but the API docs don't mention any requirement.
• Is continuous scanning with frequent stop/start (to get periodic result delivery) a supported pattern? Or is there a recommended way to scan continuously and receive advertisements without restarting the scan?

[EPASZ.1]

If you go over the w6x_ble.c driver, you may see that the stop/start mechanism is mostly implemented from the host side. I.e. the W6X driver waits (inside an RTOS thread) for either X number of scan reports or a set time. It collects those reports and then sends them all together in a batch to the higher layer through a callback.

On the basic level, the ST67 module should continue to send scan reports one-by-one, until it is stopped by ‘BLESCAN=0’. If your application could process each report as it comes, you would not need such buffering, but this will depend on other aspects.

The approach with batching the reports is mainly intended to free up the application for other tasks while the scan is running. I believe the 2s pause is chosen purely to free up time for other tasks.

 

I’m not aware this would be currently a known issue. You specify that you are using the SDK 1.3.0 - did you also update the NCP binary to the latest version?

There can be additional scan reports coming after the ‘BLESCAN=0’ command. These will be ignored by the driver on the W61 level. Launching a new scan should happen after this, I believe.

As mentioned above, you can technically keep the scan running continuously - but that would need some modifications on the driver level. And your application would probably need to process the data quite fast.

 

I will try to replicate the issue on my side, as this should not be happening with the driver. But it will take some time, probably.

[orb]

Thanks for the detailed explanation and for trying to reproduce it, I'm waiting for your results.

NCP binary: we're running st67w611m_mission_t01_v2.0.106.bin

To help you reproduce it, here's our setup:

• Scan: active, public address, filter allow-all, interval 105 (65.6 ms), window 104 (65 ms).
• Driver changes: W61_BLE_SCAN_TIMEOUT = 1000 ms (instead of 5000), and W61_BLE_MAX_DETECTED_PERIPHERAL = 40.
• Environment:  40+ advertisers, so the 40-entry list often fills and a batch is delivered after ~350 ms.
• Cycle: on every scan-done callback we call W6X_Ble_StopScan() and then W6X_Ble_StartScan() immediately, with no delay. That's one stop/start every ~0.35–1 s, i.e. thousands of cycles per hour.
• Failure: after ~2,700–10,000 cycles (20–70 min).