WB2S (BK7231T) UART Flashing Error: BytesToRead 0 at 0x11000, Erase OK but Write Fails

User question

I'm getting an error trying to flash my WB2S board via UART. I can read the firmware just fine and also erase, but writing it fails with an error. This is the log output:

All selected sectors erased!
Going to do erase, start 1970176, sec count 1!
Erasing sector 1970176... ok!
All selected sectors erased!
failed with serial.BytesToRead 0 (expected 15)
The beginning of buffer in UART contains data.
Writing sector 0x11000... Writing sector 69632 failed!
Writing file data to chip failed.

Artificial Intelligence Response

Direct answer to the question

• Your log shows the ROM loader is alive (read/erase OK) but the target stops responding exactly when the tool expects a 15‑byte ACK during the first data write at 0x11000. That is almost always a signal‑integrity or power‑integrity issue during sustained TX/RX at your chosen baud rate, sometimes compounded by a tool/firmware mismatch (BK7231T vs BK7231N).
• Fix order (highest yield first):
  • Power the WB2S from a robust 3.3 V source (not from the USB‑UART’s 3.3 V pin), tie grounds together, and keep leads short.
  • Lower the flashing baud to 115200 and retry.
  • Add a second GND lead from the adapter to the module; keep TX/RX under ~10 cm, twist each with a GND return.
  • Verify you are flashing the correct silicon variant (WB2S is BK7231T in most devices) and using an image/offset that starts at 0x11000.
  • Try a different flasher (BK7231 GUI/CLI tools) and a known‑good 3.3 V TTL adapter (FT232/CP2102/CH340).

Detailed problem analysis

• What your log tells us:

  • “All selected sectors erased! … Writing sector 0x11000 … failed … serial.BytesToRead 0 (expected 15)” means the PC sent a block, then waited for the bootloader’s block‑level status frame (15 bytes). It never arrived before timeout. Read/erase use short commands and tolerate marginal links; block writes stress the link and the target’s power.
  • Address 0x11000 (69632) is the standard application start for BK7231T images; failure here is “first large write,” not necessarily a bad flash block.

• Most probable root causes: 1) Power droop/brownout when the SPI flash enters a program cycle

  • USB‑UART 3.3 V pins often source <100 mA with poor transient response. During SPI‑NOR page‑program/verify the WB2S current can step up; a brief 3.3 V dip resets or stalls the core, so no ACK returns.
  • Symptoms align perfectly: erase passes (chip mostly idle), write fails (first program). 2) Marginal UART link at high baud
  • Breadboard leads, loose Dupont jumpers, noisy ground reference, or long wires corrupt the returning ACK. The PC then times out with BytesToRead=0. 3) Tool/firmware/offset mismatch
  • If a BK7231N image (or wrong offsets) is used on a BK7231T module, the tool may still erase but fail on program/verify, often right at the first region (0x11000). 4) Adapter/driver edge cases
  • Some cheap adapters/driver settings drop bytes under burst load. Windows “Latency Timer” too high, USB hub power saving, or macOS/Linux tty buffer overruns can all present as missing ACKs. 5) Far less likely: worn/locked flash
  • If every attempt fails at the same address after all SI/PI fixes, suspect protection bits or a weak sector. That’s rare on new Tuya modules.

Current information and trends

• Community experience on WB2S/CB2S (BK7231 family) shows:
  • Stable 3.3 V power and a second ground lead dramatically reduce “no ACK/BytesToRead 0” failures.
  • WB2S is typically BK7231T; CB2S is typically BK7231N. Using the wrong OpenBeken build (T vs N) or old vendor tools (e.g., BKWriter 1.60) is a frequent pitfall.
  • The commonly used application image offset is 0x11000; many GUI/CLI tools default to it for BK7231T.

Supporting explanations and details

• Why read/erase succeed while write fails:
  • Erase is command‑driven with the SPI flash doing the heavy lifting; the MCU can idle between polls. Power dips are less damaging. Program requires tight MCU–SPI interaction and verify, keeping the core and bus active, so any VDD sag or UART corruption is exposed immediately.
• The “expected 15 bytes” ACK:
  • Most BK7231 flashers return a fixed‑size status frame per block (opcode, status, checksum, etc.). If the target resets or the return path is noisy, the host sees BytesToRead=0.
• Signal‑integrity practices that matter at UART speeds:
  • Keep TX and RX short and close to a ground return. Twisting TX‑GND and RX‑GND pairs reduces loop area and common‑mode pickup.
  • Avoid breadboards for flashing; use direct clips/solder if possible.
• Power integrity tips:
  • Use a dedicated 3.3 V LDO/DC‑DC rated >300 mA with low ESR decoupling at the module (e.g., 10 µF + 0.1 µF close to VDD).
  • Tie GND of the supply, the USB‑UART, and the module together at one point.
  • If available, watch VDD with a scope during “write” to spot dips below ~3.1 V.

Ethical and legal aspects

• Safety:
  • If the WB2S is still mounted in a mains device (smart plug/bulb), fully isolate from mains before connecting UART. Never mix bench 3.3 V and live mains on the same PCB.
• Licensing:
  • Respect firmware licenses and only flash images you’re authorized to use.
• Privacy:
  • If the original firmware contains unique IDs/keys, ensure they’re not unintentionally shared.

Practical guidelines

• Minimum‑change recovery recipe 1) Power: External regulated 3.3 V supply; do not power from the USB‑UART’s 3.3 V pin. Connect grounds together. 2) Wiring: Add a second GND lead; keep TX/RX <10 cm; avoid breadboard; twist each signal with GND. 3) Baud: Set 115200 for the entire session; retry write. 4) Reset cadence: Start the write in the flasher, then pulse CEN/RESET low for ~50–100 ms to let the tool catch the ROM loader promptly. 5) Tool/firmware: Use a current BK7231 flasher (GUI/CLI). Select BK7231T for WB2S and confirm offset 0x11000 for the main image. 6) Adapter: If still failing, swap to a different 3.3 V TTL adapter (FT232R/CP2102/CH340). Avoid level shifters; the adapter must be native 3.3 V logic. 7) Host settings (Windows): In Device Manager → Port → Advanced, set Latency Timer to 1 ms; disable USB selective suspend while flashing.

• Diagnostics if problems persist

  • Loopback the adapter (TX↔RX) and blast a few hundred kB at your chosen baud; confirm no drops.
  • Try 57 600 or 38 400 baud to prove a pure SI issue.
  • Try another WB2S (or the same setup on a CB2S) to isolate board vs setup.
  • If failure is always the same address even at low baud with solid power, attempt programming a tiny test image; then consider off‑board programming (rarely required).

Possible disclaimers or additional notes

• Not all WB2S are identically populated on host PCBs; some routes add series resistors or share the UART with other ICs. In‑circuit loading can distort signals—lifting the module or isolating series parts may be necessary in stubborn cases.
• Some vendor builds enable logs on UART at boot; stray prints can collide with the flasher. A clean reset precisely when the tool is “Waiting for device” usually avoids this.

Suggestions for further research

• Check the module’s exact marking and a WB2S datasheet/application note to confirm the SoC (expect BK7231T) and recommended programming pins.
• Review recent community flashing guides for OpenBeken on WB2S/CB2S for tool versions known to work and example offset maps.
• If you have access to a scope/LA, capture one failing transaction to confirm whether the target stops transmitting or the PC misses bytes.

Brief summary

• Your symptoms match a classic combination of marginal power and UART link stress during the first program operation at 0x11000. Provide a solid 3.3 V supply with common ground, shorten/twist the UART leads (add a second ground), drop the baud to 115200, verify you’re using a BK7231T image for WB2S with offset 0x11000, and retry—preferably with a known‑good BK7231 flasher and adapter. This resolves the vast majority of “BytesToRead 0 (expected 15)” failures.

If you share your exact flasher/tool, baud rate, USB‑UART model, how you power the module, and whether the WB2S is in‑circuit or on the bench, I can tailor the next steps and commands precisely.

Disclaimer: The responses provided by artificial intelligence (language model) may be inaccurate and misleading. Elektroda is not responsible for the accuracy, reliability, or completeness of the presented information. All responses should be verified by the user.