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
- Your wiring and power arrangement are plausible (FTDI USB–UART, RX↔TX cross, AMS1117-3.3 V). The same setup works with a CBU module, so the adapter/driver is likely OK.
- The error “Reading failure @ 0x0 (No response received)” means the boot ROM on the Beken chip never acknowledged ltchiptool’s initial “link” sequence. This is almost always an issue with: wrong chip family selection, not catching the short UART boot window, UART1 not really connected/available, or marginal 3.3 V power during reset.
- Important difference: WB3S uses BK7231T, while CBU uses BK7231N. WB3S = BK7231T and requires UART1 (P10/P11) and a reset (CEN) timed while the flasher is waiting. CBU = BK7231N; both use the same UART1 pins, but auto-detection/timing sometimes feels “easier” on N. (docs.libretiny.eu)
- You are on ltchiptool v4.13.0 (Windows 10 Pro). That’s the current release as of Feb 2, 2026, so no need to downgrade. (github.com)

Direct answer to the question
The “No response @ 0x0” on WB3S is almost always solved by:
1) selecting family BK7231T explicitly,
2) starting the read and then resetting the module (short CEN to GND briefly or power‑cycle) while ltchiptool says “linking/connecting”,
3) ensuring you are really on UART1 pins P10 (RX1) and P11 (TX1), and
4) keeping 3.3 V stable at the module during reset. (docs.libretiny.eu)

Detailed problem analysis
1) Chip family and pins
- WB3S is BK7231T. In ltchiptool CLI you must pass the family when reading:
ltchiptool flash read bk7231t stock_wb3s.bin -d COMx -v
- WB3S UART1 pins are: P10/RX1 ← FTDI TX, P11/TX1 → FTDI RX. CEN is the active‑low reset; momentarily tie to GND to reset. (docs.libretiny.eu)

2) Bootloader entry timing
- BK7231 chips don’t have a permanent “strap” boot mode. The ROM listens on UART1 only for a short window right after reset. The practical method is: click Start (Read) in ltchiptool, then quickly reset (CEN→GND for ~0.5 s, release) or power‑cycle. Repeat if needed until it links. The official WB3S page literally advises “keep shorting CEN to GND or power‑cycling until flashing starts.” (docs.libretiny.eu)

3) Why it worked on CBU but not on WB3S
- Your CBU is BK7231N; WB3S is BK7231T. Both link over UART1, but T/N have different boot ROMs and the timing tolerances can differ. If GUI auto-detect picked N before, it won’t talk to T. Explicitly choose BK7231T for WB3S. (docs.libretiny.eu)

4) Power integrity at reset
- BK7231 can draw short current spikes at boot (RF/PLL/startup). Ensure 3.3 V at the module is flat during reset. With AMS1117, use proper decoupling near the module: at least 10–22 µF electrolytic/tantalum in parallel with 100 nF ceramic at the module pins. If in doubt, try a lab supply or a known‑good 3.3 V source.

5) In‑circuit interference (if the module is still soldered on the target PCB)
- On many Tuya boards the module’s UART1 is also wired to MCUs, level translators or button/LED circuitry. That extra loading can prevent link. If you’re programming in-circuit, temporarily isolate RX1/TX1 (lift the module, lift series resistors, or cut/restore jumpers) so only the USB–UART is on those lines.

6) Windows/FTDI details
- Keep wires short (<10 cm) and use 3.3 V logic on the FTDI.
- In Device Manager → Port → Advanced: set Latency Timer = 1 ms (FTDI), and try a USB 2.0 port. Also ensure no other app has the COM port open.
- If your FTDI exposes DTR/RTS and you want automatic resets later, you can wire CEN accordingly, but manual CEN shorting works fine for first reads.

7) ltchiptool parameters that help
- Use verbose and fix the family and COM:
ltchiptool -v flash read bk7231t stock_wb3s.bin -d COMx --timeout 10
- If the link is flaky, try a post‑link baud of 460800 or 115200:
add “-b 460800” (the link itself happens at the ROM’s default; ltchiptool raises baud after it links). (docs.libretiny.eu)

8) What “No response @ 0x0” really means
- ltchiptool opened COMx but never received the ROM’s reply to its initial “link” command at offset 0x0, i.e. the boot ROM wasn’t listening yet (no reset while waiting), UART1 isn’t what you wired, family mismatch, or line contention.

Current information and trends
- WB3S board documentation (LibreTiny) confirms BK7231T and the exact UART1 pins plus the “reset while starting flash” workflow. (docs.libretiny.eu)
- ltchiptool v4.13.0 is the latest (released Feb 2, 2026). The GUI and CLI docs emphasize picking the correct family for reads and that linking happens at the chip’s default speed, after which the tool can change baud. (github.com)

Supporting explanations and details
- If you open a serial terminal at 115200 8N1 on the FTDI port and then reset WB3S, you may see a short boot banner or a burst of bytes on TX1. Any activity there confirms you’re on the right pins and the chip is alive. If you see nothing at all across multiple resets, recheck wiring and power.

Practical guidelines (action plan)
Do the following exactly once, in this order:
1) Confirm pins and family
- Module P10/RX1 ← FTDI TX, P11/TX1 → FTDI RX, common GND, 3.3 V present.
- In ltchiptool: family = bk7231t, port = your COMx. (docs.libretiny.eu)
2) Start the read, then reset
- Run: ltchiptool -v flash read bk7231t wb3s_dump.bin -d COMx -b 460800
- As soon as the log shows “connecting/linking…”, short CEN→GND for ~0.5 s and release. Repeat once or twice if it doesn’t catch. (docs.libretiny.eu)
3) Stabilize the 3.3 V rail
- Add 10–22 µF + 100 nF right at module VCC/GND; try a short, thicker pair for VCC/GND. If AMS1117 is far away, add local bulk near the module.
4) If still no link
- Try 115200 and 230400 as the post‑link baud (-b).
- Try a different USB port or a CH340/CP2102 adapter.
- If programming in‑circuit, isolate RX1/TX1 from the rest of the board temporarily.

Alternatives and fallbacks
- BK7231 GUI Flash Tool (Windows): often more forgiving with reset timing; it backs up automatically, too. Procedure is identical: wire UART1, click “Backup and flash”, then briefly reset/power-cycle when it says “getting bus.” (github.com)
- bk7231tools (CLI): supports read/write and Tuya storage parsing; useful if ltchiptool still won’t link on your setup. (github.com)
- Last resort unbrick: SPI flashing for BK7231T if the UART bootloader was erased (rare), using the BK7231 SPI flasher. Not needed for a healthy module. (github.com)

Possible disclaimers or additional notes
- Safety: never power an in‑circuit Tuya device from mains while attaching the UART tool. Use only your isolated 3.3 V lab supply/AMS1117 source during flashing.
- ADR/auto‑reboot notes: ltchiptool’s “Auto‑download‑reboot” is a feature of LibreTiny firmware already on the device; it doesn’t help with a stock Tuya image. You must still time the CEN/power‑cycle. (docs.libretiny.eu)

Brief summary
- Pick bk7231t, wire to UART1 (P10/P11), start ltchiptool read, and reset with CEN while it’s waiting. Ensure solid 3.3 V and no UART1 contention. This resolves the “No response @ 0x0” in the vast majority of WB3S cases. (docs.libretiny.eu)

Questions for the user
1) Is the WB3S still soldered on the target PCB, or on the bench by itself?
2) Do you have a wire on CEN so you can reset on demand?
3) What exact COM port and FTDI model are you using, and did you try another adapter/USB port?
4) Can you post the first ~20 lines of ltchiptool’s verbose (-v) log while you perform the reset?

If you try the “start read → short CEN → release” sequence with bk7231t selected and it still won’t link, share the log and a photo of your wiring; I’ll point you to the next most likely culprit.