I have several devices that were originally taken for tuya. However, unstable internet and dislike for homeassistant led me to mqtt. In general, there are two devices: a socket and a leak sensor. The first on SM-028_V1.3 and the second on CB3S. The problem is the same:
However, after the firmware, both modules do not work. Send in serial only dots ".........." are constantly displayed and nothing happens. No new wifi appears and there are no new devices in my wifi network either. Previous firmware updates of devices were carried out without problems, but here I do not understand what the problem is. Please tell me. p.s. in the best traditions of my craftsmanship, I did not make a single backup AI: Can you describe exactly how you connected the devices for UART flashing (which pins you used, what you used for power, and what voltage levels)? ch340/cp2102
Yes, not quite correct information given. On module SM-028_V1.3 - BL602L20. Second module under the screen. it is version N not M, as indicated on the tuya website and on this forum. Didn't know about UART2, will check now. in the CB3S module, the log cyclically drops out:
how are you powering these modules? If from USB-TTL 3V header then that may be the issue, especially on BL602. Are you powering them with external 3.3v PSU?
BL602 UART output is at 2000000 baud and from the same port as flashing.
After the last firmware update, the logs of which are given above, BL602 stopped writing anything to the serial at all. At 200000 there is also silence. I tried to power it with UART-TTL and from the built-in relay power supply. Just like Beken, I tried to power it with batteries and a UART-TTL adapter.
It will not work if you power it directly from USB to UART converter. It can't provide enough current, unless you have one with AMS1117-3.3V on the board. Can you show a photo of your setup?
Can i try to start over? i'm learning and observing, but i don't understand. At the moment i have the following situation:
Several modules on the BK7231N chip (these are CBU, CBU-NL, CB3S and SM-028) are flashed on OpenBeken and all do not work. These are the door sensor, temperature sensor, relay, switch.
The result is the same:
1. On the firmware port there are only dots "......"
2. On the second port i see that the modules are in bootloop. The bootloop log is approximately the same:
3. After listening about the correct power supply of the modules, I tried to power them from batteries, from UART-module, from separate 3.3V power supply, from a USB-3.3V converter = with any power supply all the modules are in bootloop.
4. Finally, i had enough brains to read the dump before flashing (it was a temperature sensor). However, after uploading the backup back to the module, it does not come back to life and does not write anything to the terminal. The firmware is again on OpenBeken = bootloop.
Log reading backup:
5. Related question: "BK7231 Easy UART Flasher" downloads the QIO version firmware, don't i need the UA version to flash via UART? If anything, i tried both QIO and UA firmware - no difference = bootloop.
In the end, i want to understand what i'm doing wrong and why i can't perform what seems to be a standard operation. This is despite the fact that i have several modules that have been successfully flashed to OpenBeken and have been working in their place for a long time.
I really need some tips!
Happy to try your original backup if you need to confirm it works. Just post here or send to me.
xopkep wrote:
Related question: "BK7231 Easy UART Flasher" downloads the QIO version firmware, don't i need the UA version to flash via UART? If anything, i tried both QIO and UA firmware - no difference = bootloop.
QIO includes the bootloader and can be flashed from 0x0, UA is just the user area/app data to be flashed from 0x11000 (in the case of Beken N/T)
BK7231 Easy UART Flasher already has GUI option called "Overwrite bootloader". If enabled, it will overwrite bootloader with the one from Qio. If disabled, it will write only UserArea from QIO, so flashing QIO with this option from our flasher is the same as flashing UA. Exactly the same, I think.
thanks for the explanation about UA/QIO
i'll upload the original dump later, in about 10 hours. readResult...-51-49.bin (2 MB)You must be logged in to download this attachment. this is backup temp/hum sensor with wifi and cht8310
readResult...-51-49.txt (13.28 kB)You must be logged in to download this attachment. and it log reading
i also thought that the power supply was to blame. however, initially (before the first flashing, on the original fw) the power supply was sufficient. after returning to the original firmware, is it no longer sufficient? hmm....
in addition, i tried to power it from a stabilized adjustable laboratory power supply, with sufficient power reserve, and the situation did not change with any "broken" module - still the same bootloop.
✨ Devices based on BK7231N and BL602 chips, including SM-028_V1.3 (BL602L20) and CB3S modules, exhibit firmware flashing issues resulting in bootloops and continuous serial output of dots without Wi-Fi activation. Firmware flashing attempts using BekenWriterV1.60, BK7231 Easy UART Flasher, and python uartprogram report success, but devices fail to boot properly. The SM-028_V1.3 module is confirmed to use BL602L20, not BK7231N, and BL602 UART logs operate at 2,000,000 baud on the same port used for flashing. Power supply concerns were raised, as USB-to-UART converters often cannot provide sufficient current for stable operation; however, powering from batteries, UART adapters, and dedicated 3.3V supplies still results in bootloops. Backup firmware dumps restored to devices do not resolve the issue. Clarifications on flashing procedures note that BK7231 Easy UART Flasher’s "Overwrite bootloader" option controls whether the bootloader is replaced or only the user area is flashed. The problem persists despite correct flashing methods and power supply variations, suggesting possible firmware compatibility or hardware identification mismatches.
TL;DR: OpenBeken boot loops with serial dots? Logs show 6,600+ boot failures; “On Beken, UART1 is used for flashing, and UART2 outputs log.” For BK7231N/BL602 tinkerers stuck after flashing. Check power, chip ID, and QIO/UA mapping. [Elektroda, p.kaczmarek2, post #21545722]
Why it matters: This helps you unbrick BK7231N/BL602 devices, restore logs, and get Wi‑Fi back without guesswork.
How do I fix a BK7231N device stuck on serial dots after flashing OpenBeken?
Switch your serial monitor to UART2 (TX2) at 115200 to read OpenBeken logs. UART1 is only for flashing. Use the logs to identify boot issues instead of watching dots on the flashing port. How‑To: 1) Move RX to TX2. 2) Set 115200 8N1. 3) Reset and capture logs. [Elektroda, p.kaczmarek2, post #21545722]
Is the SM-028_V1.3 board really a BK7231N?
No. SM-028_V1.3 is a BL602/BL602L20 board. Flashing BK7231 firmware on it will not boot. Use BL602-compatible firmware and tooling for that module family. This chip mix-up is a common source of boot failures. [Elektroda, divadiow, post #21545758]
Where do BK7231N logs appear after flashing?
BK7231 uses UART1 for flashing only. Runtime logs come out on UART2 (TX2) at 115200 baud. Move your serial RX to TX2 and reset to see boot messages. “UART 2 outputs log.” [Elektroda, p.kaczmarek2, post #21545722]
What baud rate should I use to see BL602 output?
Set your terminal to 2,000,000 baud on the same UART used for flashing. BL602 prints logs on that port at this high speed. Using lower speeds looks like silence. This simple change often reveals the boot log immediately. [Elektroda, divadiow, post #21546026]
Could weak 3.3 V power cause boot loops or serial dots?
Yes. Insufficient current from a USB‑UART 3.3 V pin can prevent stable boot. Use a dedicated 3.3 V supply or an adapter with an AMS1117‑3.3 regulator. “It will not work if you power it directly from USB to UART converter.” [Elektroda, p.kaczmarek2, post #21547563]
Should I flash QIO or UA for BK7231N over UART, and to which address?
Use QIO to include bootloader and flash from 0x0 when rebuilding a device. Use UA to write only the user area at 0x11000 on BK7231N/T. Matching image type to address avoids boot loops and safe mode entries. [Elektroda, divadiow, post #21573352]
What does the BK7231 Easy UART Flasher “Overwrite bootloader” option do?
When enabled, it writes the bootloader from the QIO image. When disabled, it writes only the user area from QIO, effectively acting like a UA flash. Toggle it depending on whether you need to refresh the bootloader. [Elektroda, p.kaczmarek2, post #21573362]
My log shows “Boot Count 6633” and “safe mode activated.” What does that indicate?
That message means repeated failed boots culminating in safe mode. It confirms the device is cycling without completing startup. Use UART2 logs to pinpoint where it resets, then review power quality and image type. The “6633” count is a strong warning signal. [Elektroda, xopkep, post #21545769]
I restored my Tuya backup, but the device still won’t boot. What’s next?
Your 2 MB dump showed Tuya config extracted and no OBK config, which confirms an original Tuya image. If it still fails, recheck you’re reading BK7231 logs on UART2 and your 3.3 V supply stability. Then retry the correct QIO/UA mapping. [Elektroda, xopkep, post #21573035]
Is CB3S a BK7231N or BK7231M in this context?
In this thread, CB3S is BK7231N. Verifying the exact variant prevents flashing the wrong binary. Using N firmware on an M module, or vice versa, can cause persistent boot failure symptoms. [Elektroda, xopkep, post #21545769]
I get no serial output from BL602—am I at the wrong baud?
Likely, yes. BL602 logs at 2,000,000 baud on the flashing UART. If you read at 115200, it appears completely silent. Set 2M baud and reset to capture the boot log. This edge case often masquerades as a dead device. [Elektroda, divadiow, post #21546026]
Can someone validate my original dump to rule out image corruption?
Yes. A contributor offered to test uploaded backups: “Happy to try your original backup if you need to confirm it works.” Share your dump for independent validation before reflashing again. Community checks can save time. [Elektroda, divadiow, post #21573352]
What flash memory ID did the failing BK7231N sensor report?
The backup log shows MID 0x1560EB (TH25Q16HB) and a full 2 MB read. Use this to confirm your memory profile and image size before writing. Correct identification avoids addressing mistakes. [Elektroda, xopkep, post #21573035]
