Tuya DIY Smart Switch T1-CHL AU5101XA Flashing Issues with OpenBK7238_QIO_1.18.247 Firmware

I have 6 new generic Tuya DIY smart Switches with a

T1-CHL AU5101XA chip and some unmarked pads on the bottom that I traced out and identified 3.3 V, GND, Tx, Rx, CEN.

I am presuming that this is compatible with OpenBK7238_QIO_1.18.247 firmware (I tried several other ones in the repository).

I've made some progress



Of course, there are no signs of life after this flash. No access point. No LED.

I eventually was able to get some signs of life for two of the units by overwriting the bootloader, writing OBK settings for the WiFi network and then finding it on DHCP. The relay responds in the web GUI. The RF section, according to the web app, is all FF FF. The MAC addresses of those two switches were identical. Using the web app, OTA flash seems to work using the overwritten bootloader. GUI MAC change does not; AP access point does not work. "Restore the RF part" from the UART flasher writes a few lines before the rest which, for the most part, are all FF FF FF according to the web app, but the GUI now shows a new random MAC which then appears on the network properly. Didn't get to test MQTT.

It seems that the offsets may be an issue or I'm completely wrong as to which firmware to use. Any insight on how to set up the flasher for the new offsets would be appreciated. Attaching the read file from a stock device.

So the sequence that at least gets me a GUI on the network was to: flash the firmware, overwrite the bootloader, then flash OBK separately with WiFi credentials, then restore RF part, apparently not completely to the right place. Once I do this, I get a GUI only on the network and am unable to restore from backup.

use your backup to restore original RF to correct location for BK7238. I think ideally Easy Flasher would strongly encourage a backup and restore of RF to correct location or OBK move expected location to match Tuya's, because this will keep coming up

https://www.elektroda.com/rtvforum/topic4106397.html#21764525

I opened a second batch of switches with the same chip name, but these perform differently when flashing.

Now the sequence: 1) "Backup and flash new" with OpenBK7238 v247 - "Automatically configure OBK on flash write", "Allow Backup restore", and don't overwrite bootloader. 2) Before doing that, "Change OBK settings for flash write" with the correct GPIO data - as automatic GPIO seems not to work. 3) Restore RF part. Works.

All the stuff that didn't work on my last two units of hardware works well with this new batch.
Tested: OTA update with .rbl file, access point, change MAC with GUI, MQTT. Wi‑Fi SSID changes.



Thanks for your reply.

Looking at the forum, it is difficult to keep a database on these generic TUYA switches with the same packaging, same case, no labels on the circuit board, and no model numbers.

This one works with different pin settings compared to many of the templates.

"pins": {
"6": "TglChanOnTgl;1",
"15": "Btn_Tgl_All;1",
"17": "LED;1",
"26": "Rel;1"
}

It appears to respond to a PowerSave 1 command properly, based on the log.

The JSON below can be seen decrypted from your dump. Easy Flasher doesn't extract enough currently to map pins from it and even then it doesn't know about your pin6, which I guess is either

or



do you have any more pictures of your device so one can be added to the device list in a new template?

>>21815937 I'm getting a third batch from this vendor tomorrow. If they behave the same way and look the same on the inside, I'll upload the internal pics. The vendor and product on Amazon are attached.

ah OK. super-common casing

https://github.com/OpenBekenIOT/webapp/commit/d35f8845aa4f6611d4e955f6d71a94cc12e09ba9

>>21815998
While I am waiting for the new device package to test out, I made a Node-RED subflow that seems useful specifically for Open Beken flashed devices.

The usage is a custom node that only requires a topic and a pop-up selection of an MQTT server known to flow. It takes an input from a Dashboard 2.0 switch node and feeds back to the input of the switch node to update its state. There is a status display below the custom node that displays online, offline, on, and off states.

Example flow usage picture and design of the subflow node. JSON of the subflow node.

Testing and comments would be appreciated.

>>21816566
The new batch just came in and appears to be the same from this vendor.
Pics:

Updated the subflow to be more bulletproof and packaged it as a module that can be imported via Node-RED palette manager.

I got a similar device that uses T1-CHL AU5102XA and I cannot flash it, it always fails to recognize the chip even when I power it from my benchtop PSU or shorting CEN to ground. What is baffling me is the fact that all pins seem to be the same, I verified this by continuity testing the testing pads on the PCB against the chip pad descriptions in the T1 datasheet. I also tried different chip types in EasyUartFlasher to no avail. Any thoughts/ideas?

got any pics of your device and wiring?

First of all, I'm really sorry for such a late reply. Now, as you can see from the pictures, it is literally the same thing except that 2 in the chip marking T1-CHL AU5102XA.
Everything else, I think, is the same.
.

it does appear to be the same device




these strands here, are they fluff or actual solder/wire? are they causing a short?

They are fluff from the cotton bud I used to clear flux off the chip, in order for the markings to be readable.

I decided to give it another go again today, and I tried any utilities like BKfil, BKwriter, etc. I could find. I even downloaded EZFlasher build 220, as OP had success with it. All to no avail. I think I wasted enough time with this, moving on.

I'm curious to see the lengths of your wires, how you're powering the device, your rig as a whole.

No worries if you've drawn a line under it all though and don't want to go back to it.

Even some USB to UART converters may be not reliable, it may be worth trying with another one.

divadiow wrote:

I'm curious to see the lengths of your wires, how you're powering the device, your rig as a whole.

I removed the previous somewhat bigger whires and soldered a single strand 7 cm wire to each pad. It was not a matter of long wires/intereference or anything hardware related. I even tried using the CEN pad as a Rx and Tx to no avail. I also tried different settings like changing the serial port parity from the adapter's port settings but nothing worked. I ended up burning the chip because somehow I turned the knob to 18 V. Such a shame, not for the 2.5 € I bought the thing for, but for not getting a bin file.

p.kaczmarek2 wrote:

Even some USB to UART converters may be not reliable, it may be worth trying with another one.

I have no reason to disagree with this as a principle since signal integrity is a bitch, but I've used it for flashing many devices, even soldered on bios chips in laptops, and I have nothing but good things to say about this thing.

Working on the same board, also having a tough time getting my USB UART programmer to dump the firmware. I've used this programmer many times, so I know it's good.

I know it's getting power, as I can see the SmartHome WiFi network show up. Running

python uartprogram firmware.bin -d /dev/ttyUSB0 -r

fails to get the bus despite shorting CEN to ground. Edit: Also no luck with the Easy UART flasher on a Windows VM. I have the same T1-CHL AU5102XA chip.

Printed a pogo pin adapter for it as well: https://www.printables.com/model/1741438-tuya-diy-smart-switch-pogo-pin-adapter

out of interest what chips are your USB-TTL adaptors using? eg CH340G

>>21913407

It's the CH340G, the Amazon ESP-01: ESP Prog V1.0 USB to ESP8266 CH340C ESP-01 ESP-01S 4MB Module Prog WiFi Programmer Downloader with Reset Auto-Download Circuit.

OK.

I assume the labelling in the pic in post #1 is correct, but have you verified each pad traces to the expected pin on the T1-CHL?

Hmm, I rung out the test pads with my multimeter and neither of the Tx ad Rx pads according to the image in the first post seem conected to the T1 chip at all. Cen, Gnd and Vcc all seem correct but no UART pins. Looked at the board through my microscope and those two pads are connected to TX1 (pin 29) and RX1 (pin 28). I have no idea why I'm not seeing a connection. Getting contact to the chip package itself is going to be hard.

OK Progress! I got connected to the bus. Looks like my pogo pins weren't making good contact with the pads. I soldered wires on and things got better. However, now easy flasher is failing to set the baud rate? I tried 115200 and 921600. Both failed.

Looks like the fastest it wants to go is 19200. Oh well, it's reading the chip at least!

Edit: Got OBK on and working. Connected to a real power supply got faster data speeds.