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 WB2S is most likely not failing because of a bad flash offset or a dead flash sector. The log indicates a write-phase UART timeout: the tool sends the first application block at 0x11000 and then never receives the expected bootloader ACK. On WB2S, 0x11000 is the normal app start address for BK7231T, so failing there usually means power instability, UART signal integrity, wrong chip/file selection, or tool/baud-rate issues rather than a defective sector. (docs.libretiny.eu)

Most likely fixes, in order:

• Power the module from a real 3.3 V supply, not the USB-UART adapter’s 3.3 V pin.
• Lower the flash baud rate to 115200 first, then try 460800 if needed.
• Keep TX/RX/GND short, add a second ground wire, and ensure solid connections.
• Confirm you are flashing BK7231T / WB2S firmware at 0x11000.
• If the module is still soldered into the product, try to isolate it from the rest of the circuit or flash it off-board.
• Use a current tool such as recent BK7231GUIFlashTool or ltchiptool. (docs.libretiny.eu)

---

Detailed problem analysis

The important clue in your log is this sequence:

• erase works
• read works
• write fails immediately at sector 0x11000
• error is serial.BytesToRead 0 (expected 15)

That means the ROM/download loader link is good enough to establish communication and accept erase/read commands, but during the first real data program transaction the chip stops replying. That specific address is significant because for WB2S/BK7231T, the application partition begins at 0x011000, so this is simply the first application write, not an unusual location. (docs.libretiny.eu)

From an electronics perspective, flash program operations are much more demanding than reads. During programming, the flash circuitry and internal charge-pump activity produce transient current demand and tighter timing requirements. If your 3.3 V rail dips briefly, the BK7231T can reset or fall out of download mode before it sends the expected response frame. LibreTiny’s BK72xx documentation explicitly warns that most flashing problems are caused by voltage drops during intensive flash operations or bad/loose wires, and also notes that the UART adapter’s 3.3 V regulator is usually not enough. (docs.libretiny.eu)

There is another BK7231T-specific behavior that matches your failure pattern: BK7231T exits download mode when it cannot communicate with the flasher. So if one block is corrupted on the wire, or the device browns out briefly, the bootloader session can collapse immediately and the PC then sees exactly what your tool reports: no ACK bytes returned. (docs.libretiny.eu)

The UART side also matters. WB2S flashing is done on UART1, using P10/RX1 and P11/TX1. The same UART may also be connected to external circuitry such as a TuyaMCU or other host electronics in the product. That means in-circuit flashing can be electrically “good enough” for read/erase yet marginal for sustained writes if another device loads the lines, injects traffic, or distorts edges. This is an engineering inference supported by the platform documentation stating that UART1 is used both for flashing and for external components. (docs.libretiny.eu)

The chip/file selection must also be correct. WB2S is documented as a BK7231T module with 2 MiB flash, and the normal app partition starts at 0x11000. If the tool is told BK7231N instead of BK7231T, or if you feed it the wrong binary type, write attempts can fail even though basic serial linking still works. LibreTiny’s flashing guide also states that choosing the wrong family typically makes the process fail rather than magically succeed. (docs.libretiny.eu)

---

Current information and trends

As of March 22, 2026, BK7231GUIFlashTool build 293 is the current published release on GitHub, and the project describes itself as the replacement for older tools such as bkWriter 1.60 and hid_download_py. The same project also explicitly says that changing the baud rate can help, and that sometimes a higher or lower baud works better depending on the setup. (github.com)

A second actively maintained option is ltchiptool, which supports BK7231 devices through both GUI and CLI. Its current documentation emphasizes:

• automatic file-type detection,
• automatic offset selection for valid firmware files,
• optional baud override using -b,
• and a beginner-friendly GUI flow. (pypi.org)

Tuya also provides an official UART download tool (tyutool). Its documentation shows a default baud of 115200 in the GUI flow, while CLI examples may use much higher rates for some chips. In practice, for a marginal WB2S setup, starting low is the safer engineering choice. (github.com)

---

Supporting explanations and details

Why read/erase can work while write fails

Read and erase transactions are often more tolerant of:

• short interruptions,
• marginal voltage rails,
• poor adapter regulators,
• and borderline signal integrity.

Write is the first stage where all of these are stressed simultaneously:

• sustained UART throughput,
• continuous ACK/response timing,
• flash program current spikes,
• and longer uninterrupted activity windows. (elektroda.com)

Why 0x11000 is not the problem by itself

For WB2S/BK7231T, the documented memory map places:

• bootloader at 0x000000–0x010FFF
• app image starting at 0x011000. (docs.libretiny.eu)

So your failure at 69632 decimal = 0x11000 is exactly where a normal application write begins. That strongly suggests the issue is transport/power related, not “sector 0x11000 is bad.” (docs.libretiny.eu)

Why the supply matters so much

A USB-UART bridge may enumerate and pass serial data perfectly while still being a poor power source. The 3.3 V pin on many adapters is meant for light loads and often has weak transient performance. For flashing Beken/Tuya modules, the documentation recommends a good stable 3.3 V source, specifically noting that the adapter regulator is usually insufficient. (docs.libretiny.eu)

Why wiring matters

At UART flash rates, long Dupont leads act as:

• resistance,
• capacitance,
• EMI antennas,
• and ground-return problems.

A second ground lead reduces loop impedance and improves return current paths. Short twisted pairs or at least short direct wiring reduce susceptibility to edge distortion. The exact-error Q&A for your symptom specifically recommends short leads and even a second ground wire. (elektroda.com)

---

Ethical and legal aspects

If this WB2S is inside a mains-powered switch, plug, or relay product, reflashing can affect:

• electrical safety behavior,
• RF certification assumptions,
• vendor warranty,
• and regulatory compliance of the finished device. (docs.libretiny.eu)

Also, if you erase vendor firmware before verifying your custom image and recovery path, you can make the product unusable. LibreTiny recommends dumping stock firmware first, which is good engineering practice for traceability and rollback. (docs.libretiny.eu)

---

Practical guidelines

Recommended recovery procedure

1. Use external 3.3 V power

   • 3.3 V regulated supply, preferably with comfortable current headroom.
   • Tie all grounds together: WB2S, USB-UART, external PSU. (docs.libretiny.eu)

2. Add local decoupling

   • Place 100 nF ceramic + 100 µF electrolytic near the module’s 3.3 V/GND.
   • This is not quoted from the docs, but it is standard power-integrity practice for flash/program transients.

3. Reduce baud

   • Start at 115200.
   • If stable, try 460800 later.
   • Do not start at aggressive rates until the setup is proven. Tuya’s official tool uses 115200 as default, and BK7231GUIFlashTool explicitly notes baud changes can solve problems. (github.com)

4. Verify wiring

   • USB-UART TX → WB2S P10/RX1
   • USB-UART RX → WB2S P11/TX1
   • GND ↔ GND
   • Reset using CEN to GND if needed. (docs.libretiny.eu)

5. Keep wires short

   • Ideally under ~10 cm if possible.
   • Add a second GND lead if you can. (elektroda.com)

6. Check tool and image

   • Confirm BK7231T, not BK7231N.
   • Confirm the file is intended for 0x11000 app flashing on BK7231T/WB2S. (docs.libretiny.eu)

7. Try a newer tool

   • Use current BK7231GUIFlashTool or ltchiptool.
   • If using ltchiptool, leave Auto-detect advanced parameters enabled unless you know exactly what you are doing. (github.com)

8. If the module is still in-circuit

   • Disconnect or isolate anything else on UART1 if possible.
   • If necessary, remove the module from the host PCB for programming. This is an engineering best-practice inference from the shared-UART architecture. (docs.libretiny.eu)

Suggested test sequence

• First attempt: stable PSU + 115200 + short wires.
• Second attempt: same hardware, different adapter.
• Third attempt: same hardware, different flasher.
• Fourth attempt: isolate module from host board.

That sequence separates:

• power issues,
• serial adapter issues,
• software/tool issues,
• and in-circuit interference.

If using ltchiptool

A practical approach is to use Write flash, choose the firmware file, and let the tool auto-detect file type and offset. The docs state this avoids manual offset mistakes and reduces the chance of overwriting the wrong region. (docs.libretiny.eu)

---

Possible disclaimers or additional notes

• If you already erased the device, OTA recovery through stock firmware is usually no longer available; UART recovery remains the primary path.
• If the board powers other circuitry from the same rail, current spikes elsewhere on the product can interfere with the flash write even if the WB2S itself would otherwise be fine.
• A truly damaged flash is possible, but given that the failure is exactly at the normal app start and only during write, it is less likely than power/UART integrity issues. This is an engineering probability judgment based on the documented map and failure mode. (docs.libretiny.eu)

---

Suggestions for further research

If this still fails after the checklist above, the next useful steps are:

• capture the 3.3 V rail with an oscilloscope during the first write block,
• observe UART TX/RX during failure to see whether the chip resets or simply stops responding,
• try an adapter with better drivers and timing behavior,
• compare results between BK7231GUIFlashTool and ltchiptool,
• verify the exact firmware artifact name you are flashing, especially if the build output contains several .bin, .rbl, .uf2, or .crc files. (docs.libretiny.eu)

---

Brief summary

Your error is most consistent with a write-time loss of bootloader communication, not a mysterious bad block at 0x11000. On WB2S/BK7231T, 0x11000 is the normal app start, and the chip is known to be sensitive to weak 3.3 V power, marginal UART wiring, and download-mode dropouts during flashing. The highest-probability fix is:

1. external stable 3.3 V supply,
2. common ground plus short wiring,
3. baud rate reduced to 115200,
4. correct BK7231T image/tool selection,
5. newer flasher and, if needed, off-board programming. (docs.libretiny.eu)

If you want, send me:

• the exact flashing tool,
• the baud rate,
• whether the WB2S is still soldered into the product,
• and the exact firmware filename,

and I can give you a much more targeted, tool-specific recovery procedure.

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.