[Solved] Flash openbeken on TreatLife Smart Plug BK7231T/WB2S with DSD TECH SH-U09C2

Hi all, I'm going to apologize in advance because I'm a novice at best and am not strong in python or programming. I'm able to follow people's directions and have had great luck flashing openbeken and Tasmota to many devices, as well as successfully desoldering and installing new modules where previous non-compatible modules exited.

I'm trying to flash openbeken to multiple TreatLife Smart Plugs (US variant). A lot more detail about this device can be found on the FCC Listing, specifically the internal photos.

I've flashed twelve already, but the old ones have WB3S modules in them, and these new ones have WB2S.



I've soldered connections directly to the 3V, GND, TX, and RX on the WB2S module and am using a DSD TECH SH-U09C2 to connect between my laptop (Windows 11) and the module. I was always able to flash them with UART using the command:


Because the WB3S and WB2S are very similar I tried flashing them the same way, however it would fail with an error stating "Unprotect Failed." I removed the "--unprotect" command. This would successfully flash, however the openbeken WiFi AP never became available, and when reconnecting the serial adapter, the RXD LED would flash rapidly without stopping. I could reflash again by shorting GND to CEN again to gain bus, but always ending in the same result.

I then tried flashing again using the following command:

This would flash, but return "Read CRC Failed." The openbeken AP was again not available, however on attempting to reflash, shorting GND to CEN does not work to get bus. I came across a thread here that said to leave off the "--startaddr 0x0" command for BK7321T modules, maybe that's my problem? Thus far, nothing has worked on any device flashed with that last command.

Have I bricked the WB2S modules that I've tried to flash? Are there any recovery options? I've been scouring this forum and the internet for a while, but I'm at a loss.

It looks like you're flashing incorrectly. BK7231T does not allow flashing at address 0x0. You are trying to flash it as BK7231N. You are risking corruption of your device.

Unprotecting is for N only.

Futhermore, the QIO binary is the binary with the bootloader. You should never use it for T platform (unless you are using our flasher, which handles it internally). The legacy way of flashing T platform is to flash UA binary, just after the bootloader.

Please either use our new flasher that fixes this issue internally:
https://github.com/openshwprojects/BK7231GUIFlashTool
Or use bkWriter 1.60 to flash the UA binary after the bootloader.

You can check our channel for WB3S/WB2S flashing tutorials:
https://www.youtube.com/@elektrodacom
Old flashing method for T:

New flashing method for T:

Thank you for the crazy fast reply! I'm thinking I've borked these modules. I had tried bkwriter before work no luck so I stuck to the UART method. Thank you also for the explanation on differences in handling the two modules, I've just learned a ton!

I'll try the new flasher, but I'm leaving for work travel and won't get a chance to do this for a while.

Are there any recovery methods that I could/should try with the incorrectly flashed units? Or should I write them off as a lesson in the school of hard knocks?

What does the TX2 debug log output say?

You can recover it in SPI mode (if pins are available):
BK7231 programming via SPI in flash memory mode - Python and Banana Pi

So I wanted to make sure this wasn't just another open-ended forum conversation.
Bottom line: I bricked these devices by trying to flash the wrong firmware. While they are likely repairable using the recovery SPI mode, it requires disassembling the plastic body of the plug which is plastic welded together, and I do not have the tools at home to restore that. Permanently making the plug body unusable to repair the module would defeat the purpose of attempting any repair as the process would permanently render the device useless.
I'm probably going to dispose of these, which really is sad because I like the challenge of repairing the unrepairable, and this is a lot of money going to waste. I may break them apart, remove the WB2S to repair and install in future devices. Expensive lesson, but I did learn my lesson.

If they have WB2S inside then indeed recovery via SPI may be hard. Not all of the required GPIOs are exposed on this chip. I've done only WB3S recovery so far.

You can still replace WB2S with a matching ESP module.

There wasn't a fix for this problem. Ultimately I flashed the wrong firmware and bricked the devices. While there are ways to unbrick the modules on these, it would require disassembly of the plastic bodies that are plastic welded together. It would permanently alter them rendering them unusable or unsafe.

Maybe someday I can 3D print new bodies for these, but I purchased working replacements so these are just going to sit in a box for now.