logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

No AP anymore flashing OpenBeken on an SM-SO301-U power strip with CB3S (BK7231N) chip

tlpelektroda 3738 34
Best answers

Why does my CB3S/BK7231N power strip keep dropping into OpenBeken safe mode and then stop showing its AP after flashing?

Your OpenBeken AP problem is most likely caused by unstable power or a hardware/RF issue, not by the 0x11000 QIO flash offset. Use a stable external 3.3 V supply instead of relying on the USB-TTL adapter, keep the mains unplugged while flashing or logging, and read the boot log from TX2 at 115200 baud; if you want to reset everything, reflash the factory backup starting at 0x0 and then flash the QIO OpenBeken image with the default 0x11000 start/skip settings. [#21240989] [#21242916] [#21242960] [#21243031] If the device only sees your AP when it is right next to the router and otherwise finds only a couple of networks, the CB3S antenna or nearby solder/clearance is suspect; inspect for scratches, solder whiskers, or metal arcing near the PCB antenna and compare against another CB3S strip. [#21244364] [#21245595]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #31 21244362
    tlpelektroda
    Level 2  
    Posts: 18
    Rate: 1
    Yes, all my older power strips were flashed with and running Tasmota, including the one that started dying recently, which is what prompted me to order new ones that I found all now have the CB3S chip. Of the 4 Tasmota strips -- 3 are still running currently and in different rooms -- I've never had any problem with them receiving and transmitting to and from the router AP signal. Nor with any of the numerous other little IOT devices I have running in various rooms, all communicating happily with the same 2.4GHz network AP as this device I've first found the first signal problem with.

    In fact, I pulled up the config pages on the existing running Tasmota strips to look at their GPIO mappings, as a guide maybe to how I might map the CB3S pins in these strips if I can get one working. The Tasmota strips are all fine and responsive, and one is right next to where I was testing the now-working OBK power strip, which couldn't see the AP at all. The OBK strip is definitely the odd man out.

    So this would seem to all lead back to the antenna, or something about the receptivity, on this device, wouldn't it? Is the antenna in the CB3S just an otherwise lifeless piece of metal, or does it have some sort of gain or amplifier or some kind of carrier current connected to it, something that might be causing it not to either receive or transmit at full strength, something that might be programmable or settable even maybe? I obviously don't know much about antennas and RF transmission/reception.

    hartzell wrote:
    >>21244297 Is your older power strip flashed with Tasmota? If so, you could bring it near the AP and see what the signal strength is, then move it away a bit and check, and a bit further, and ...

    Not sure what it'll tell us, but it might be informative.
  • ADVERTISEMENT
  • #32 21244364
    divadiow
    Level 38  
    Posts: 4839
    Help: 420
    Rate: 852
    The pin assignments are extractable from the factory fw using Easy Flasher
    Screenshot of Easy Flasher software for extracting configuration from Tuya devices.

    Regarding RF - how is the physical state of the CB3S? Are there any scratches across the aerial at the top of the module that may mean most of it is severed?

    CB3S module with visible label and markings.

    Are there any minute solder whiskers between any of the contacts around the module? Have you inspected the module with a macro lens or magnifying glass for signs of damage?

    You could start the process again with one of your other new CB3S power strips...
  • ADVERTISEMENT
  • #33 21245589
    tlpelektroda
    Level 2  
    Posts: 18
    Rate: 1
    This is so awesome @divadiow, thanks for pointing it out! May I ask did this particular pin assignment layout you reproduce here come from the fw binary I sent you? Since I don't have Easy Flasher (unless I swallow hard and set this up on Window$ somehow, or install mono on my various linux boxen and try to run it etc), do you happen to know how this could be manually extracted from the fw binary? I guess I could start with a hex editor, if it's obvious and laid out contiguously in the binary, by searching for it. Or I guess I could just look at the code for EF and just replicate that. But super cool to know it can be found in the binary, thank you!
    divadiow wrote:
    The pin assignments are extractable from the factory fw using Easy Flasher
    Screenshot of Easy Flasher software for extracting configuration from Tuya devices.


    Regarding the antenna, I took a magnifying glass to it and didn't see anything obvious, although you can only see it on the front side of the CB3S PCB on this device, like in your picture, not from the back/underside, so it's hard to tell. It's possible that I damaged part of it from my solder of the top left CEN pin that's right at the base of it, but I didn't see anything obvious there too, except a bit of the excess metal from the solder joint kind of arcs over it a little. I wonder if the metal interference from the solder could cause it. I looked at Tuya's data sheet for the CB3S and discovered some potentially interesting info to people who know more about this than I (which isn't a high bar).  Like for example, that the "CB3S uses the PCB antenna with a gain of 1.3 dBi." And that they recommend keeping it clear of any metal parts within 15mm of it -- which is definitely violated by the upper pins on the chip itself -- and that no metal parts should be under an imaginary dome of circular arc of diameter 3cm etc.. As for that dome area being clear, as they say here in NYC, fuhgeddaboudit!
    So I think for now, unless you know some way I can verify and/or configure whether this chip's antenna is running with a gain of 1.3dBi or otherwise meeting its self-declared "Wi-Fi receiving performance" specs, I think I'll turn to the other strips I have to see if I can compare/duplicate/eliminate this phenomenon.
    divadiow wrote:

    Regarding RF - how is the physical state of the CB3S? Are there any scratches across the aerial at the top of the module that may mean most of it is severed?

    CB3S module with visible label and markings.

    Are there any minute solder whiskers between any of the contacts around the module? Have you inspected the module with a macro lens or magnifying glass for signs of damage?

    You could start the process again with one of your other new CB3S power strips...
  • ADVERTISEMENT
  • #34 21245595
    divadiow
    Level 38  
    Posts: 4839
    Help: 420
    Rate: 852
    tlpelektroda wrote:
    May I ask did this particular pin assignment layout you reproduce here come from the fw binary I sent you?

    yes, it did.
    tlpelektroda wrote:
    do you happen to know how this could be manually extracted from the fw binary?

    I guess it's all possible, but not sure how this could be tackled immediately. The code that does it would be buried in here somewhere I guess; https://github.com/search?q=repo%3Aopenshwprojects%2FBK7231GUIFlashTool+extract&type=code

    tlpelektroda wrote:
    except the excess metal from the solder joint kind of arcs over it a little

    goes near or actually arcs, making contact with the RF shield?
    tlpelektroda wrote:
    I wonder if the metal interference from the solder could cause it

    can't say I've noticed module clearance issues to have this effect on a conversion to OpenBeken, and presumably it *should* work.

    I guess the ultimate thing would be to remove the CB3S and play with it out of the device, see if the symptoms are the same.

    Added after 2 [minutes]:

    config for eventual import into working device:

    Code: JSON
    Log in, to see the code
  • #35 21245601
    tlpelektroda
    Level 2  
    Posts: 18
    Rate: 1
    thanks for the link on this!
    divadiow wrote:
    The code that does it would be buried in here somewhere I guess; https://github.com/search?q=repo:openshwprojects/BK7231GUIFlashTool extract&type=code


    it kind of 'arcs near'. The solder kind of wicked up when it was hot I guess and kind of bends up from the pin such that the wire bends forward over a little in the direction of the PCB antenna
    divadiow wrote:

    goes near or actually arcs, making contact with the RF shield?


    yes, but that would be overly ambitious for my skill level -- I looked at some postings where people remove the CB3S chip and swap in an ESP chip. I have enough trouble making a solder joint on a single pin not messy, never mind 22 pins simultaneously set in a PCB... but good idea for my aspirations someday lol
    divadiow wrote:
    I guess the ultimate thing would be to remove the CB3S and play with it out of the device, see if the symptoms are the same.


    Added after 3 [minutes]:

    ah thank you! I saw something in Elektroda posts on how you load/import/export configs like this, into OpenBeken, though I wasn't sure if you do this through Easy Flasher, or rather, I assume, through the OpenBeken web interface on the CB3S chip. On the web interface do you just upload this JSON file straight? Thanks again for the pro tips!
    divadiow wrote:
    config for eventual import into working device:

    Code: JSON
    ...
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion revolves around the challenges faced while flashing OpenBeken firmware onto the SM-SO301-U power strip, which utilizes the CB3S (BK7231N) chip. The user successfully accessed the OpenBeken web interface but encountered persistent issues with the device not appearing on the local LAN despite multiple attempts to configure Wi-Fi settings. Various troubleshooting steps were suggested, including capturing UART logs, ensuring proper power supply, and using a jig for flashing. Users shared experiences with different flashing methods, including using ltchiptool and Easy Flasher, and discussed the importance of using stable power sources during the flashing process. The conversation also touched on the potential need for a factory reset and the possibility of hardware issues affecting the device's performance.
Generated by the language model.
Today's popular

FAQ

TL;DR: If your CB3S power strip shows only 2 nearby networks and "full reboot failed," the flash may be fine but power or RF may not be. This FAQ helps OpenBeken users on SM-SO301-U diagnose safe mode, missing AP, wrong UART pin use, and weak Wi-Fi after flashing with ltchiptool on Linux. [#21244297]

Why it matters: This thread shows that boot-loop symptoms can look like bad firmware, yet the real fault may be low 3.3V power, wrong logging pin, or physical RF damage near the CB3S antenna.

Option Start offset Skip offset Write length Best use
OpenBeken QIO via ltchiptool/Easy Flasher 0x11000 0x11000 0x121000 or auto-detected ~1.1 MiB Normal OBK flashing on BK7231N
Factory firmware restore 0x0 0x0 All data / full 2 MiB Clean recovery and sanity check
UG/CCtr firmware Not the same as QIO Not the same as QIO Varies Avoid mixing blindly with QIO workflows

Key insight: The decisive clue was RF behavior, not flashing logs: the strip only worked when placed right next to the router and saw just two 2.4 GHz networks, strongly pointing to antenna or module-side reception damage rather than a simple offset mistake. [#21244297]

Quick Facts

  • The UART boot log must be read from TX2, not TX1, at 115200 baud on a CB3S module; using TX1 produced only garbage characters in this case. [#21242916]
  • The user’s successful OpenBeken flashes auto-detected start offset 0x11000, skip 68 KiB, and write length about 1.1 MiB for OpenBK7231N_QIO_1.17.730.bin. [#21242887]
  • The factory backup was restored as a full 2 MiB write from 0x0, then OpenBeken was flashed again with QIO defaults, which is the thread’s clean-reset workflow. [#21243152]
  • USB-TTL power alone can be unstable on CB3S; one expert warning was that adapter 3.3V often causes brownouts and repeated reboot behavior during setup. [#21240989]
  • The failure threshold was unusually severe: the strip would connect only when placed about right next to the router, then disappear again at roughly 5–10 feet and still showed only 2 visible networks instead of 20–30. [#21244297]

Why does an SM-SO301-U power strip with a CB3S (BK7231N) running OpenBeken show "safe mode (AP mode) because full reboot failed" and refuse to join my Wi-Fi?

It enters safe mode because OpenBeken detects repeated failed boots, and the refusal to join Wi-Fi can come from power instability or RF failure rather than a bad flash alone. In this thread, the red message appeared after 6 or more failed reboots, and the final root cause looked RF-related because the device saw only 2 networks and worked only beside the router. That pattern points away from DHCP or static-IP settings and toward brownouts, weak reception, or physical damage near the module antenna. [#21244297]

How do I correctly flash OpenBeken onto a CB3S/BK7231N module with ltchiptool on Linux, including the right start offset, skip offset, and write length for QIO firmware?

Use the QIO binary and let ltchiptool use the normal QIO defaults. 1. Connect to the BK7231N and flash the OpenBK7231N_QIO image. 2. Confirm ltchiptool reports start offset 0x11000. 3. Keep the auto-detected skip offset and write length, which in this case were 0x11000 skipped and about 1.1 MiB written. That matches the thread’s working configuration after factory restore and matches what Easy Flasher also expects for QIO images. [#21243031]

What is TX2 on the CB3S module, and how is it different from TX1 when capturing UART boot logs?

TX2 is the CB3S serial transmit pad used for readable boot logs, while TX1 is not the correct pad for this diagnostic task. The thread showed that using TX1 produced garbage characters, but the expert explicitly said CB3S logs should be captured from TX2 at 115200 baud. "TX2" is a UART output pin that sends boot and runtime serial data, and on this module it is the correct diagnostic output while TX1 is not. [#21242916]

How can I capture and read UART boot logs from a CB3S (BK7231N) at 115200 baud to diagnose OpenBeken boot loops or missing AP issues?

Connect your USB-TTL adapter RX to the CB3S TX2 pad and open a serial terminal at 115200 baud. 1. Keep the device fully unplugged from mains during logging. 2. Power the module from a safe 3.3V source or test it assembled on mains only with nothing else attached. 3. Watch the boot sequence for resets, crashes, or repeated transitions into safe mode. Putty, Realterm, or another plain serial monitor is enough; Easy Flasher itself does not include a terminal. [#21242916]

What is the difference between OpenBK7231N QIO firmware and UG/CCtr firmware, and how can flashing the wrong type affect later boots?

QIO firmware includes a bootloader-aware layout, while UG/CCtr uses a different flashing model, so mixing them can corrupt expectations about offsets and boot state. The expert said QIO images are flashed with the 0x11000 scheme, but also agreed that earlier experiments with UG/CCtr could have overwritten something important. In this case, the recommended fix was to wipe the device back to factory from 0x0 and then reflash OpenBeken QIO normally. [#21242960]

When restoring a BK7231N device to factory firmware, how do I perform a full flash from 0x0 so I can rule out a bad OpenBeken flash?

Do a full-chip restore starting at address 0x0 with no skipped data. Set start address to 0x0, skip offset to 0x0, and clear write-length limits so the entire backup is written. In the thread, the factory image wrote as a full 2 MiB flash, which reset the slate before reflashing OpenBeken. This is the cleanest way to rule out leftover UG/QIO layout conflicts or partial writes. [#21242916]

What does the auto-detected 0x11000 start offset in ltchiptool mean when flashing OpenBeken QIO binaries to a BK7231N?

It means ltchiptool is skipping the bootloader area because the QIO image already includes that structure. The expert explained that 0x11000 is the programming start point on the chip, while the same amount is skipped from the beginning of the input file. In short, it is normal for QIO firmware and was explicitly said not to be the reason the AP failed to appear. [#21242916]

How do Easy Flasher and ltchiptool compare for flashing OpenBeken on BK7231N devices like the CB3S?

They reach the same QIO result, but Easy Flasher exposes more helper features while ltchiptool works well from Linux command line. In this thread, ltchiptool successfully flashed QIO images using auto-detected values, and Easy Flasher was recommended for simpler factory restore and for extracting pin assignments from the factory firmware. Easy Flasher does not include a serial console, so you still need Putty, Realterm, or similar for UART logs. [#21245595]

Could a weak 3.3V supply from a USB-TTL adapter cause brownouts, reboot loops, or missing AP behavior on a CB3S module during OpenBeken setup?

Yes, a weak USB-TTL 3.3V rail can cause brownouts and repeated resets on a CB3S. The expert said this is “usually the case” and advised that many USB-TTL adapters cannot provide enough current for stable Wi-Fi operation. That can produce symptoms such as incomplete boots, disappearing AP mode, or failure to join the LAN even after credentials are saved. The thread then tested mains-powered operation to separate power issues from firmware and RF issues. [#21240989]

What is CEN on the CB3S module, and how is the CEN-to-GND reset step used during BK7231N flashing?

CEN is the CB3S reset or enable-related pin used to trigger the chip into the right state during flashing. The user reported that ltchiptool often prompts for the moment when CEN should be briefly shorted to GND, after which flashing begins. "CEN" is a control pin that resets or re-enables the BK7231N, and briefly pulling it to ground helps the flasher detect and start programming the module. The thread used the corner CEN pad successfully. [#21239720]

How should I safely power an SM-SO301-U or other mains power strip while flashing or logging a CB3S module, and when should mains power never be used?

Never use mains while flashing or while a USB-TTL adapter is connected for logging. The expert gave a 100% clear rule: keep the strip unplugged from mains for flashing and UART work. To test whether the onboard LDO provides more stable 3.3V, reassemble the strip and power it exactly as a finished product, with nothing connected to the CB3S. That isolates power-supply problems without mixing low-voltage tools and live mains hardware. [#21241061]

Why would a CB3S running either factory Tuya firmware or OpenBeken only detect one or two nearby Wi-Fi networks and fail unless it is placed right next to the router?

That behavior strongly indicates very weak RF reception or transmission on that specific module. In the thread, both factory Tuya firmware and OpenBeken failed at normal range, the strip saw only 2 nearby 2.4 GHz networks instead of about 20–30, and it connected only when placed right next to the router. Because the same pattern appeared across both firmwares, the evidence points to hardware or antenna-side loss rather than OpenBeken network settings. [#21244297]

What hardware damage or RF issues on a CB3S module can cause very poor Wi-Fi range after soldering, such as antenna scratches, solder whiskers, or metal near the PCB antenna?

Physical damage near the PCB antenna can severely reduce Wi-Fi range. The expert specifically asked about scratches across the aerial, minute solder whiskers between contacts, and metal or solder arcing near the top antenna area. The user also found Tuya guidance mentioning a PCB antenna gain of 1.3 dBi and recommending about 15 mm clearance from metal. On this strip, a solder joint near the top-left CEN area was considered a plausible cause of RF degradation. [#21245589]

How can I extract the GPIO and relay pin assignments from a factory BK7231N/Tuya firmware backup for use in OpenBeken on an SM-SO301-U power strip?

Use Easy Flasher to extract the configuration from the factory backup, then import the resulting mapping into OpenBeken. In this case, the extracted data showed a 5-channel layout with relay pins on GPIO 8, 6, 24, 26, and 14, plus status LED and button assignments. The expert confirmed that the screenshot and JSON came directly from the posted factory firmware backup, so the backup itself was valid and useful for template recovery. [#21245595]

Where can I find or make a pogo-pin jig for flashing a CB3S, and will a TYWE3S 3D-printed jig work with this module?

Yes, a TYWE3S pogo-pin jig can work because the thread reports the same edge spacing on the CB3S module. One user successfully used a 3D-printed TYWE3S jig and shared a public model from Thingiverse, while also noting that small drill bits were needed to clean the printed holes before inserting the pins. If you do not own a printer, the thread suggests online print services or a local makerspace as practical alternatives. [#21240277]
Generated by the language model.
ADVERTISEMENT