WB3S ltchiptool v4.13.0 Flash Read Fails at 0x0 via FTDI on Windows 10 Pro

qscented wrote:

@ElektrodaBot
WB3S ltchiptool read flash error Reading failure @ 0x0 (No response received) @ElektrodaBot
AI: How do you have the WB3S module connected to your computer (e.g., which interface, wir...

Initial assessment of available information
- Host: Windows 10 Pro, ltchiptool v4.13.0.
- Interface: FTDI USB–UART, wiring RX1↔TX, TX1↔RX, external 3.3 V from AMS1117.
- Symptom: ltchiptool “Reading failure @ 0x0 (No response received)” on WB3S, while the same setup works with a CBU module.

Interpretation: The failure at 0x0 means the tool never established a valid download-mode session with the Beken chip on WB3S. Because your CBU works, the PC/driver/cable are probably fine; this points to reset/boot timing, line contention on UART, I/O level mismatch, or power integrity specific to the WB3S target.

Note on silicon: Tuya WB3S modules typically carry BK7231T or BK7231N. Some third‑party dev boards marketed as “WB3S” exist with BK7238, but Tuya’s WB3S used in appliances is BK7231T/N. Keep that in mind when you select the chip in ltchiptool.

Direct answer to the question
Most often this error is fixed by:
1) Ensuring the module truly enters download mode (reset timing on CEN).
2) Eliminating any in‑circuit device that is driving RX1/TX1 (TuyaMCU/MCU/level shifters).
3) Verifying 3.3 V I/O levels on the FTDI side and stable 3.3 V power at the module.
4) Issuing the connect/read immediately around a CEN low–high pulse, with a conservative baud (115200) and verbose logging.

Detailed problem analysis
1) Entering download mode reliably (CEN handling and timing)
- CEN is “chip enable” (active low reset). The downloader is most responsive if you:
- Hold CEN low.
- Click Start (or run the CLI command).
- Release CEN to high within ~0.5 s so the ROM/bootloader sees the handshake.
- Alternative: Click Start first, then briefly pull CEN low for ~100–300 ms and release while ltchiptool shows “Connecting…”.
- If your FTDI exposes DTR/RTS, you can add a simple auto‑reset:
- DTR → 100 nF capacitor → CEN, with a 10 kΩ pull‑up from CEN to 3.3 V. This lets the tool’s DTR toggle generate a clean reset pulse.

2) UART line contention (very common in‑circuit)
- If WB3S is still soldered on its original PCB, RX1/TX1 are frequently connected to a secondary MCU (often called “TuyaMCU” on smart devices) or other circuitry (e.g., button matrices, transistor drivers).
- Any device pulling RX1 low or actively transmitting will prevent the downloader from autobauding.
- Remedies, in order of intrusiveness:
- Power only the WB3S at 3.3 V and keep the rest of the board unpowered.
- Hold the external MCU in reset (if its reset pin is accessible).
- Temporarily lift the RX1/TX1 pins from the module pad side, or cut/rebridge the RX trace later.
- Best: Desolder the module and program it off‑board.

3) Voltage and I/O level integrity
- Power rail:
- AMS1117 requires proper input/output capacitors (typ. ≥10 µF on OUT and IN). Add 100 nF close to the WB3S VCC–GND pins and a 47–220 µF bulk cap on the 3.3 V rail.
- Keep programming wires short (<15–20 cm). Ground must be common and low impedance.
- Watch for “double powering”: do not tie the FTDI’s 3.3 V output to your AMS1117 3.3 V at the same time. Power from one source only.
- I/O levels:
- Many FTDI breakouts default to 5 V I/O even if you don’t use their 5 V pin. Ensure VCCIO (or logic level jumper) is set to 3.3 V. A 5 V TX from FTDI can hold the BK’s RX in an invalid state or damage it.
- Idle level check: with a multimeter or scope, WB3S RX1 should sit at ~3.3 V idle; if it’s near 0 V or being periodically driven, you have contention.

4) Baud rate and tool options
- Start conservative at 115200 baud; increase only after a successful link.
- Use verbose logging to see at which phase it fails:
- ltchiptool -vv link-info -d COMx
- If link-info works, try a small read first:
- ltchiptool -vv flash read -d COMx -b 115200 -l 4096 boot.bin
- Then a full dump:
- ltchiptool -vv flash read -d COMx -b 115200 full.bin
- If detection is flaky, explicitly try both chip IDs:
- --chip bk7231n
- --chip bk7231t
This only affects protocol nuances and prints; it won’t brick anything during read.

5) Windows/driver specifics
- Ensure the genuine FTDI VCP driver is installed. In Device Manager:
- Advanced port settings: set Latency Timer = 1 ms; disable “Serial Enumerator” if present.
- Close all serial terminals (Arduino IDE/Putty) before using ltchiptool.
- Try another USB port (preferably direct to the motherboard) and a short, good‑quality USB cable.

6) Adapter and cabling
- FTDI clones can be marginal with the Beken autobaud sequence. If available, try a second adapter (CP2102/CP2104 or CH340 at 3.3 V I/O) and keep wires short and twisted GND with RX/TX if possible.

7) Edge cases
- BK7231T with a corrupted/erased bootloader (rare unless previously misflashed) may not enter download mode at all. In that case only a SWD/JTAG‑style recovery (not exposed on WB3S) or chip replacement helps. If you’ve never flashed this module before, this is unlikely.
- Read protection: if you do connect but reads fail mid‑way with permission errors, some firmwares enable protection. Do not issue a chip erase unless you’re prepared to lose the original image.

Current information and trends
- Recent ltchiptool builds are much better at autobaud and reset handling but still sensitive to timing on some boards. A quick A/B with one earlier v4.x build (or the portable CLI) is a useful sanity check if everything else looks good.
- Community experience shows in‑circuit contention and 5 V I/O are the top two causes when “works with module A, fails with WB3S”.

Supporting explanations and details
- Why timing matters: the downloader waits for a specific sync pattern right after reset. If your CEN pulse doesn’t align with the tool’s sync bytes, the chip boots the application instead and ignores the flasher.
- Why contention matters: even a weak pull‑down or a chatty TuyaMCU on RX1 alters the autobaud measurement and the first command frame checksum, yielding “no response”.

Practical guidelines (do this now)
- Minimal reproducible test off‑board:
- Connections: 3.3 V, GND, RX1↔TX, TX1↔RX, CEN accessible.
- Caps: 100 nF + 47–220 µF across VCC–GND near the module.
- Command sequence (example COM5):
- ltchiptool -vv link-info -d COM5 -b 115200
- While it says “Connecting…”, pull CEN to GND for ~200 ms and release.
- If link-info succeeds, run the 4 kB read, then full read.
- If still “no response”, swap the USB–UART adapter and repeat.

Possible disclaimers or additional notes
- Do not connect any 5 V signals to the WB3S. If your FTDI board has a 5 V/3.3 V jumper, set it to 3.3 V so VCCIO is correct.
- Avoid issuing “Erase” until you have a confirmed link and a dumped backup.

Suggestions for further research
- Search for “LibreTiny BK7231 download mode CEN timing” and “WB3S UART1 pinout Tuya” for schematics/pin notes if you need board‑level confirmation.
- If you discover the module is BK7231T and its bootloader is gone, look up community notes on external programmer/SWD recovery or consider module replacement.

Brief summary
Your setup is close; the typical blockers are reset timing (CEN), UART contention from the target board, or I/O/power integrity. Isolate the module or at least isolate RX1/TX1, ensure 3.3 V I/O and solid 3.3 V power with local decoupling, and trigger CEN during the ltchiptool connect at 115200 with verbose logs.

Questions for the user
- Is the WB3S still on its original PCB? If yes, what device is it from, and can you hold the other MCU in reset or disconnect its UART lines?
- Can you confirm your FTDI adapter’s logic level is 3.3 V (VCCIO jumper or measured idle TX ~3.3 V)?
- What is the exact behavior of CEN during your attempts (measured voltage and pulse timing)?
- Please share the output of:
- ltchiptool -vv link-info -d COMx -b 115200
- ltchiptool -vv flash read -d COMx -b 115200 -l 4096 boot.bin
- Do you have a second USB–UART adapter to try?