Flashing documentation suggestions

[mvdklip]

Thank you for this great firmware. I just flashed a BHT-002-GBLW sold as a "MJZM 16A-002" on AliExpress.

I must say this was one of the hardest devices I ever flashed. First tried the tuya-convert route which (ofcourse) didn't work because of more recent factory-installed firmware. Then I started soldering a separate 3.3V power supply and a PL2303 USB to TTL UART to the pins documented in Flashing.md. This is where the real trouble started because whatever I tried I could only get garbage from the serial port. Tried several terminal emulators, different baud rates, a Windows laptop, a Linux laptop. Resoldered everything. Garbage garbage garbage. Tried esptool.py anyway but couldn't connect as well.

After doing a lot of searching and reading I found three mentionworthy points:

1. It is very hard to connect to an ESP which has another MCU talking to it at the same time. It is best to disable the Sonix MCU inside the thermostat during flashing. This can be done by cutting it's power, pulling it's reset pin low or by completely desoldering the TYWE3S board from the thermostat board. I tried the reset pin but that failed for me so in the end I completely desoldered the TYWE3S. Please note that the tracks on the thermostat board damage very easily. I damaged the GND connection but could easily restore that using a piece of wire. I would recommend connecting the RST pin to GND instead. The reason that failed for me is probably the other two points below.

2. I connected the GND of my PL2303 to the GND of the power supply because I read somewhere this was neccessary for the PL2303 to function properly. I didn't think of this at all before because I was not using the (5V) power supply of the PL2303.

3. I had to use a baud rate of 74880 for receiving anything else than garbage on the serial port. It took me a while to find this magic number.

Maybe something about these points can be added to the documentation?

[mvdklip]

Tasmota documents the "connected MCU" issue:

To boot the TYWE3S in flashing mode, GPIO0 needs to be connected to GND while powering up. It can be left grounded for the entire process. Flashing a TYWE3S connected to a MCU is a bit trickier than one without MCU. This is due the same Rx Tx pins used by MCU and serial programmer for flashing. The TYWE3S cannot be booted to flash mode with MCU sending data over the same pins. To be able to do that, we need to disable MCU from sending data over Rx and Tx pins. There are few ways to do it:

1. Disconnect TYWE3S module from the rest of board. (Naah, too much work) 2. Just break the Rx track from MCU to TYWE3S, flash and then reconnect. (Messy work, we want cleaner approach) 3. Just keep MCU disabled while flashing TYWE3S without any soldering / cutting. (We like that)

The easiest is to keep MCU disabled is by identifying the NRST/RST (Reset) pin of the MCU from its datasheet and connect it to GND for the entire flashing process. This will keep MCU disabled while you flash TYWE3S. If there are some contacts or test points in switches that connect to the MCU, you might be lucky to find contacts for RST that you can easily solder onto.

https://tasmota.github.io/docs/TuyaMCU-Devices/

[paulius2k]

Hello, I had the same(?) issue.

esptool.py couldn't connect to my BHT-002 GBW. I got this:

C:\Users\xx>esptool.py -p COM4 -b 74880 read_flash 0x00000 0x100000 originalFirmware1M.bin
esptool.py v3.0
Serial port COM4
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to Espressif device: Timed out waiting for packet header

Tasmotizer couldn't connect either.

The solution that worked for me was NOT TO CONNECT GPIO15 to programmer-GND. i.e. the striked-out part of the initial instruction by fashberg did not work in my case:

Black: ESP-GND ~~and ESP-GPIO15~~ connected to Programmer-GND

After disconnecting GPIO15 from GND it worked as a charm.

PS: the baud rate of 460800 worked fine for me as well.

[mvdklip]

@paulius2k what kind of UART hardware did you use? Some people claim that CP2102 based hardware is able to overshout the ESP to MCU communication in some way.

PS: the 'magic' baud rate of 74880 was only neccessary to be able to view the output of the serial port in a serial terminal. I am used to taking things step by step so I first wanted to get usable output from the serial port before trying to flash it over that same port. AFAIK esptool.py can be run using any baud rate because it actually sets the ESP to the desired baud rate.

[paulius2k]

@mvdklip - I am using a DSD TECH SH-U09C5 USB to TTL adapter with a FTDI FT232 chip.

[mvdklip]

@paulius2k okay so not a CP2102 based device. I don't know why you managed to flash it by disconnecting GPIO15, but I suspect it has something to do with the basic issue of the Sonix MCU talking to the ESP while trying to flash it. Maybe (just guessing here) the idea of connecting GPIO15 to GND was to disable the MCU in the first place? And maybe this doesn't work for all devices? The thermostat board does have a connection to GPIO15, so it must be used for something...

[mvdklip]

Just now found that @rufik was facing the same issues as me and had to desolder the TYWE3S completely in the end:

https://github.com/fashberg/WThermostatBeca/issues/100#issuecomment-791336469

So I would still suggest to document the 74880 baud rate and suggest to look at the boot messages and MCU traffic before trying to flash and I would recommend to mention the fact that some people have issues flashing the TYWE3S in place. Some solutions for this like pulling the reset pin of the MCU to low should work but somehow don't work.

[rufik]

Yes, I agree - it should me mentioned clearly in docs. I even cut RX and TX paths but still failed. I had no time investigate it further, desoldering way only (and fastest) way for me.

[badger707]

I've read that different UART boards might give different results, FT232 is one of recommended ones.... TYWE3S is dead simple to flash in any device without desoldering. You just need to connect GPIO0 to GND as shown here

TYWE3S must be put in "flash" mode by connecting GPIO0 to GND, not GPIO15, that was written somewhere in tasmota docs, works every time without desoldering. First, you'd check if UART is able to speak with it, from esptools docs: esptool.py flash_id

If all goes well and you're getting response, powercycle your UART -- disconnect from PC USB and connect it back , this will restart connected TYWE3S to it. GPIO0 must still be connected to GND. I've read somewhere that you must powercycle after each command sent to it. Next, fire up Tasmotizer (if on Win), make backup and flash new firmware of your choice. Thats all it takes.

Agree, sometimes you must desolder TYWE3S it to access the pins, but thats rare.

Edit: here is TYWE3S info from Tasmota https://tasmota.github.io/docs/devices/TYWE3S/

[rufik]

I'm sorry but in that case is not 100% true. I've tried FT232, CH340 and CP2102 boards - no difference. Not able to speak with ESP module (checked using esptool flash_id cmd like you mentioned, as well as other esptool cmds). And I'm not a newbie, I've managed to flash about 20 ESP-based devices and dev boards with different kind of firmware (tasmota, espeasy, esphome, etc).

This TYWE3S module is somehow "locked" when sits down into BHT-002. How, why? I don't know, I had no spare time to investigate it. Maybe I should buy another one from Aliexpress (as spare one) and investigate it...someday :)

[badger707]

I have 3 BHT-002, branded under MOES name. One of them was ok for OTA flash (old firmware), the other 2 had newer firmware so had to wire it to FT232 to flash using steps from prior post.

Yes, your situations seems like edge case, it could be (just guessing) that your seller asked OEM manufacturer (BECA?) for custom PCB design to "lock" the chip from flashing... It sounds highly unlikely, but you'd never know what shenanigans they're doing & why...

I can post my device PCB pictures, let me know if needed.

[tsrubar]

BHT-002 just came today, first tried resolder TYWE3S for flashed ESP12S, but it didnt even boot properly. Then I tried to flash TYWE3S since it was desoldered already and it went without problems. Resoldered ESP12S for TYWE3S and BHT-002 was working perfectly with it. Since i need to buy another 10 pieces (zone heating), tried to flash it again directly on PCB. Tried every possible combination of wiring, but no go. I dont want to desolder every chip out of pcb from all 10 devices so still finding way to do it easier. Starting to think that easiest way is to cut rx/tx trace on pcb and after flash just repair it. I damaged display a little because of too much heat from my hot air rework station, so probably this will remain as a testing piece Edit: cuting even both of traces didnt help. It must be something different

[rufik]

I've already tried with cutting RX&TX traces on PCB - no go :( I would go with investigation that way:

• desoldier TYWE3S module
• reconnect it to PCB using wires (possibly single goldpin connectors), so you're in starting point - flashing not working,
• disconnect RX&TX wires from PCB, then try flashing,
• disconnect next wire/pin then try flashing,
• disconnect next wire/pin then try flashing,
• ...until flashing is fine :)

So finally you'd be able to state which pin (or combination of pins) of TYWE3S is source of flashing problems & gain the glory here :D

[tsrubar]

Will try this with another piece. Desoldering is pain as pcb gets damaged too easy. Since bht-002 works very nice with home assistant and wthermostatbeca, im going to stick to this model and buy rest of them. Will do these tests once next will arrive

[rufik]

I was successful using simple soldering iron, only few pins are used. Start with left side - pry gently, very gently, using flat screwdriver (for example) and desolder pin by pin. Tin sucker could help as well. Good luck 🤞

[tsrubar]

9 more BHT-002 just came few days ago, also i ordered another programmer and with this one flashing works without desoldering. So it is definitelly matter of power drained by rest of thermostat apart from TYWE3S and quality of programmer itself. Link to new programmer

[mvdklip]

Thanks for the update. Looks like it could be a power drain issue indeed. I have assumed (from reading online resources) that it was the MCU trying to talk to the ESP which was causing all this "garbage" on the UART but now that I think of it this doesn't make sense actually:

• When the MCU sends data to the ESP it does this on the RX pin of the ESP seen from the perspective of the ESP.
• When the UART receives data on its RX pin this can only come from the connected TX pin of the ESP so not from the MCU.

So that means that seeing this garbage must have been the ESP trying to talk to the MCU and not the other way around. This also explains why pulling the RST pin of the MCU didn't work, because that didn't stop the ESP talking.

[rufik]

AFAIK esp put into programming mode stops running your code, so no "talking" with MCU. Am I wrong? Power drain/leak could be the cause...maybe...but I was using 5V/1A power supply connected and no-go as well...

[mvdklip]

Programming mode stops running code indeed. That's why (in hindsight) I realize that my ESP cannot have been in programming mode while I saw incoming binary protocol data. Previously I just reached the wrong conclusion that it must be the MCU putting out this data. Now I know this cannot be because the UART RX pin is not connected (directly or indirectly) to the MCU TX pin.

The power drain is likely to happen in the flasher circuit, not in the (separate) circuit powering the ESP. How this exactly leads to the ESP not entering programming is still a mystery to me, but at least I'm a bit wiser. I still have a somewhat damaged BHT lying around. If I find the time I might experiment with trying to flash it. Don't hold your breath though.

[gavlexx]

I succeeded somehow to flash BHT002 with CH340, but it happens only with 1 from 5 devices. Cannot understand what differs these new devices from old I bought only half a year earlier. Marks and PNs are identical... Both times I succeeded to read, erase and then flash new firmware - was touch the ground pin of ESP with GPIO0 cable and Reset PIN cable simultaneously. But this trick cannot give stable result - this didn't help me to flash no more devices...

[witchcraftsman]

I've managed to flash my Moes BHT-002-GBLW with cheapo CH340G setting it to 5V instead of 3.3, I was about to quit it as desoldering of 4x devices is way off my initial intentions My issue was device failing to even read_flash completely and getting stuck at 10-20% Other stuff related: macbook m1, esptool.py v3.2 installed via brew

EDIT: I would also recommend doing the reading several times and checking with md5 afterwards.

[fashberg]

Hey

last year i've checked to wiring between MCU und ESP, see: https://github.com/fashberg/WThermostatBeca/blob/master/docs/Diagnose%20Can%20we%20add%20WiFi%20to%20Non-Wifi%20Thermostat%20bac-002.pdf

So the MCU has 5 Volt TTL and ESP has 3 Volt and it's converted. During flashing i'm connecting only 3,3, Volt to ESP. MCU is powered with 5 Volt on a different lane (Vcc-5v), so it should not be powered.

I've checked now with Oscilloscope and yes: i cannot see any voltage on MCU if i only power ESP and also there are no signals coming from MCU.

So probably power issue of TTL adapter.

Folke