BK7231N Thermostat Not Booting After openBK7231N 1.18.157 Firmware Flashing

Hello,

I have a thermostat device, which is using bk7231N chip:


It uses Encryption key: 00000000 00000000 00000000 00000000

I download firmware, and skip key check.
But system does not find any OOB, and actually device does not boot after openBK7231N 1.18.157 install. Restoring RF partition does not help. Lost device.

Hey, can you show a photo of your device?

Probably this can help: How to flash BK7231M/BL2028N non-Tuya devices with 000000 keys?

>>21641627 >>21641627

Hello,

I already tried this instruction, same result. First I tried with 'M', then I tried with 'N' skipping key check
https://www.aliexpress.com/item/1005006020556081.html

Ed

This is a curious case.

I flashed your backup to a CB3S yesterday and it booted. CB33 was from Tuya device with standard Tuya keys.

Do you get any log out on boot from TX at all?

Maybe it's a battery powered device and TuyaMCU turns off the power?

It's 220v thermostat, no battery. what tools to use to see a logs?
Also, Config can't be extracted from this binary.

Here is guide for extracting dpIDs for TuyaMCU devices: https://www.elektroda.com/rtvforum/topic4021129.html

>>21642128 binary, which I upload it's an original binary, I downloaded as backup. this one boot to me also. I can't boot OpenBK, and can't extract gpi config

bl00dy wrote:

what tools to use to see a logs?

PuTTY, Realterm etc

What are these pads labelled as?




also, have you tried overwriting bootloader in N/M modes to see if it boots then?

There are no pins/config to extract if that's TuyaMCU. For TuyaMCU, you should rather do: https://www.elektroda.com/rtvforum/topic4021129.html

This is factory boot log as far as it will go on dev board



I'm curious about how standard the TuyaMCU is though because it will not talk to Tuya Module Debugging Assistant as I would expect with a standard TuyaMCU device.

It'd be good if you could capture the full factory firmware boot log from real device with it able to talk to MCU.

Well, then maybe you're able to capture what is actually send from UART by this particular firmware? UART1 - the TuyaMCU/programming one, not debug log.

good point. will do.

here's a little bit more printed from TXD1/P11

>>21643751
Hello, No, I did not try to rewrite bootloader, as it's written, not recommended for N/M devices. but I can try.
pinouts are in the picture.

divadiow wrote:

here's a little bit more printed from TXD1/P11

that seems to be the extent of it



maybe it's waiting for something from MCU first before sending anything?

Which baud is it? Maybe it's using alternate baud. This looks random for me?

p.kaczmarek2 wrote:

This looks random for me?

that hex apparently = the ascii seen in previous post. that was 115200



at 9600 baud it looks like

Wait, that's indeed ASCII! So you captured from wrong port - it should be from UART port, and not from log.

Added after 1 [minutes]:

Wait, but you said...

divadiow wrote:

here's a little bit more printed from TXD1/P11

I am confused now. TX2 is log output and TX1 is TuyaMCU comm...

p.kaczmarek2 wrote:

Wait, but you said...

yes

TX1/P11:



TX2/P0 is main boot log in previous post

it does appear to be listening on RX1/P10. If you listen on TX1 and send random TuyaMDA commands to RX1 it will respond with:

I connect to original firmware, but only power bk chip:
[01-01 00:00:00 TUYA I][module_main.c:935] --------------------module_main start--------------------

[01-01 00:00:00 TUYA I][tal_thread.c:184] thread_create name:module_main,stackDepth:3072,totalstackDepth:22528,priority:5
[01-01 00:00:00 TUYA I][tal_thread.c:184] thread_create name:log_service,stackDepth:1536,totalstackDepth:24064,priority:3
calibration_main over
calibrate low value:[6d9]
calibrate high value:[dae]
temp in flash is:350
xtal in flash is:95
[FUNC]func_init_extended OVER
Version:
app_init finished
[01-01 00:00:03 TUYA I][module_main.c:224] [uart] wait mcu response retry = 1
[01-01 00:00:06 TUYA I][module_main.c:224] [uart] wait mcu response retry = 2
[01-01 00:00:09 TUYA E][module_main.c:222] [uart] can't receive mcu response, ignore

not sure, how I can read logs, and power connect to see full logs.

Is it even using UART? Maybe it's SPI or I2C?

Can you try to power the devicely in a safe manner (not from mains, to avoid making short and an explosion), from, I don't know, maybe 5V could be injected somewhere in the board, just to the input of 3.3V LDO, if that's present, and try to capture the communication?

I rewrite bootloader and successfully install OpenBK

Added after 43 [minutes]:

How to detect on which pins tuya RX/TX, and what speed? I have this file extracted

Well, just as I said in my previous message - you probably need to capture original communication and analyze it. Currently it doesn't look like a typical TuyaMCU device.

You can also try to start TuyaMCU driver in OBK but I am not sure if it will work... this device may be using other protocol

I just install ESPHome, and try to debug UART1 (p10/11) and UART2 (P1/0) with different baud rates. but unfortunately MCU chip is not respond. by the pins, I see MCU TX/TX connected to UART2

I'm glad you got OpenBK to boot. Was that with with BK7231N QIO or BK7231M?

In order to fully work out the protocol the MCU uses I'm afraid it is probably the case that the factory firmware needs to re-flashed to device and the communications in both directions be sniffed out.

>>21644810 I install BK7231N with bootloader rewrite.
But now I can't find any possibilities to read MCU. On board MCU TX is connected to UART2 RX, and MCU RX is connected to PIN UART2 TX. I try to have different speed, changing RX/TX, no success, even I try to send MCU activations
- uart.write: { id: mcu_uart, data: [0x55,0xAA,0x00,0x03,0x00,0x01,0x03,0x07] }
- delay: 100ms
- uart.write: { id: mcu_uart, data: [0x55,0xAA,0x00,0x01,0x00,0x00,0x01] }
- delay: 100ms
- uart.write: { id: mcu_uart, data: [0x55,0xAA,0x00,0x08,0x00,0x00,0x08] }

But no success

This makes no sense, and we don't provide support for esphome. You're also trying things blindly, no suprise it's not working.

I think we have already established that this isn't TuyaMCU protocol and you need to make packets capture, then we can write you a driver for it in OBK.

I am not sure, how I can sniff packets.

Not sure if this help. i can connect chip to 3.3V and possible connect my Rx and Tx to MCU RX/TX pins, is this works?

Ed

As I said - you can sniff packets if you power both MCU and WiFi module. You need to check how MCU is powered. Also, is there AMS1117-3.3V on board? Or how is the device powered?

What are the markings here?

Can you make a clear photo? Maybe one of the lines is GND and second is 3.3V or 5V... and then you could safely power it, without connecting to mains. Then we could help you with packets capture and write a driver for it for OBK?