logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

[BK7231N ] Teardown of TH08 LCD Calendar/clock/temperature/humidity, 3xAAA battery, backlight

morgan_flint 36339 249
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #241 21625858
    divadiow
    Level 37  
    still only those IDs

    Code: JSON
    Log in, to see the code
  • ADVERTISEMENT
  • #242 21626813
    bogdanelhh
    Level 3  
    It seems that after recharging the batteries stopped working and I had to reflash it. Is there something I can do to prevent this from happening ?
  • #243 21693614
    sebgarske
    Level 6  
    >>21626813 I'm facing the same issue on all 4 of them. It seems to be an issue with the wifi module. Logging is kind of hard to obtain since I have to desolder the pins again
  • ADVERTISEMENT
  • #244 21694711
    sebgarske
    Level 6  
    I was able to collect some logs via TX2. The MCU RX/TX and Pin 8 are disconnected:

    Code: text Expand Select all Copy to clipboard
    V:BK7231N_1.0.1
REG:cpsr     spsr     r13      r14
SVC:000000D3          00401C1C 000033AC
IRQ:000000d2 00000010 00401e0c eee356f7
FIR:000000d1 00000010 00401ffc f9c5abad
SYS:000000df          0040192c 00000158
ST:00000000
J 0x10000
bk_misc_init_start_type 0 0
prvHeapInit-start addr:0x4144f0, size:113424
[Flash]id:0xeb6015
sctrl_sta_ps_init
cset:0 0 0 0
OpenBK7231N, version 1.18.176
Entering initLog()...
Commands registered!
initLog() done!
Info:MAIN:Main_Init_Before_Delay
undefined instruction
Current regs:
r00:0xdd3000e2
r01:0x00000000
r02:0x005dd352
r03:0x00000052
r04:0x005dd300
r05:0xffbf767f
r06:0x003ff1ce
r07:0xdd300000
r08:0x08080808
r09:0x09090909
r10:0x10101010

fp :0x11111111
ip :0xffe38350
sp :0x00406070
lr :0x0080006e
pc :0x0080006e
SPSR:0x800000ff
CPSR:0x800000db

separate regs:
SYS:cpsr r8-r14
0x800000df
 0x08080808
0x09090909
0x10101010
0x11111111
0xffe38350
0x00415618
0x003ff1b7
IRQ:cpsr spsr r8-r14
0x800000d2
0x6000001f
0x08080808
 0x09090909
 0x10101010
0x11111111
0xffe38350
0x004078a8
0x003ffd70

FIR:cpsr spsr r8-r14
0x800000d1
0x00000010
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x004068b8
0xf9c5abad

ABT:cpsr spsr r8-r14
0x800000d7
0x00000010
0x08080808
0x09090909
0x10101010
0x11111111
0xffe38350
0x004060b8
0x9980fef0

UND:cpsr spsr r8-r14
0x800000db
0x800000ff
0x08080808
0x09090909
0x10101010
0x11111111
0xffe38350
0x00406068
0x0080006e

SVC:cpsr spsr r8-r14
0x800000d3
0x200000df
0x08080808
0x09090909
0x10101010
0x11111111
0xffe38350
0x00408078
0x0008b360

shutdown...
  • ADVERTISEMENT
  • #245 21695699
    fjcns
    Level 6  
    To connect the wires for serial communication between the CBU and the programmer, connect the CBU's RX to the programmer's TX, which is also connected to the MCU's TX. The MCU will want to communicate when powered, interfering with serial communication. The CBU's TX connects to the programmer's RX, which is also the MCU's RX.

    From what I understand about the thermostat, the MCU only updates on startup and when there is a change in temperature or humidity to save battery power.

    When working at the bench with a light over the board, a soldering iron/soldering station nearby, and soldering wires to the board, increases the temperature on the board, even drafts can make the MCU want to communicate more often, thus interfering with serial communication.

    After soldering the wires, with the thermostat connected and the CBU powered directly with 3V so that the MCU doesn't cut off its power, let the board stabilize its temperature.

    This way, the MCU performs the initial communication and stops interfering with the serial communication.

    In my case, it wasn't necessary to desolder the MCU pins.
  • #246 21696663
    morgan_flint
    Level 14  
    fjcns wrote:
    In my case, it wasn't necessary to desolder the MCU pins.

    In some cases, I've also had success without interrupting the connection between WiFi module and MCU, but I also managed to kill an MCU's TX pin. I think it's advisable to interrupt at least the connection between MCU's TX and WiFi module's RX to avoid the programmer and the MCU "fighting" each other to send different levels, if the MCU decides to wake up and send info while you're programming
  • ADVERTISEMENT
  • #247 21696685
    sebgarske
    Level 6  
    >>21695699 I know that and already managed to flash 4 of them. My problem is rather that after some amount of time when the batteries are empty and I replace them the CBU crashes on startup. You can obtain the logs via TX2/RX2. To rule out the MCU as a cause I disconnected it. It seems something is off in OpenBeken. Most concerning is this: "undefined instruction" right before the crash.
  • #248 21745721
    nogard0
    Level 1  
    >>21696685
    I had exactly the same issue.
    The first device I encountered this with got bricked before I managed to debug it and figure out what was actually going on.

    A few months later I ordered another one, flashed it successfully, and everything worked perfectly — until the batteries ran out. I found it about 5 days later (the screen was still working fine, showing 2 out of 3 bars, but as soon as it tried to sync and power up the MCU, the battery indicator dropped to 1 bar).

    Of course, it didn’t boot after replacing the batteries. I’m quite sure the corruption happens after many failed boot attempts when the battery is too low. The MCU has exactly 10 seconds to start communication with the TuyaMCU, otherwise it is forcibly restarted by it.

    I reflashed it, and when it still didn’t start, I connected TX2/RX2 — it turned out the device boots only up to the point where it tries to read the Boot Count from flash:

    Spoiler:
    Code: text Expand Select all Copy to clipboard
    
.....
[Flash]id:0xeb6015
sctrl_sta_ps_init
cset:0 0 0 0
OpenBK7231N, version 1.18.206
Entering initLog()...
Commands registered!
initLog() done!
Info:MAIN:Main_Init_Before_Delay
<hangs here>


    So my current theory is that repeated brownouts while accessing the flash cause permanent corruption.

    In the end, I recompiled the firmware with
    Code: text Expand Select all Copy to clipboard
    #define DISABLE_FLASH_VARS_VARS

    and as soon as I flashed that, it started working normally again.

    Now it doesn’t store any runtime state or count restarts (so it has no protection if Wi-Fi fails to connect), but for this particular device that’s completely fine — and it should also prevent the same issue when the batteries run out next time.

    Here’s my fork of the latest version, rebuilt with DISABLE_FLASH_VARS_VARS:
    https://github.com/nogard0/OpenBK7231T_App/releases/tag/1.18.207.1

    And here’s my current autoexec.bat:
    Spoiler:
    Code: text Expand Select all Copy to clipboard
    clearIO
PowerSave 1
startDriver NTP
// ntp_setServer pool.ntp.org
ntp_setServer 192.168.40.1

// EEST time zone
alias winter_time ntp_timeZoneOfs 2
alias summer_time ntp_timeZoneOfs 3

winter_time

// summertime
alias check1 if $month>3 then summer_time
alias check2 if $month==3&&31-$mday+$day<=6&&$day>0 then summer_time
alias check3 if $month==3&&31-$mday+$day<=6&&$day=0&&$hour>=2 then summer_time

// wintertime
alias check4 if $month>10 then winter_time
alias check5 if $month==10&&31-$mday+$day<=6&&$day>0 then winter_time
alias check6 if $month==10&&31-$mday+$day<=6&&$day=0&&$hour>=3 then winter_time

alias set_time backlog check1;check2;check3;check4;check5;check6

startDriver TuyaMCU
startDriver tmSensor

setChannelType 1 temperature_div10
linkTuyaMCUOutputToChannel 1 val 1

setChannelType 2 Humidity
linkTuyaMCUOutputToChannel 2 val 2

setChannelType 3 ReadOnlyLowMidHigh
setChannelLabel 3 "Batt_state"
linkTuyaMCUOutputToChannel 3 val 3
 
waitfor NTPState 1
set_time
  • #249 21752721
    flecom
    Level 1  
    I've got one of these with a BK7238, flashed it with openbk and made an autoexec that looks like this:

    Code: text Expand Select all Copy to clipboard
    clearIO
PowerSave 1
startDriver NTP
ntp_setServer 192.168.1.1

// EDT-EST time zone
alias winter_time ntp_timeZoneOfs -5
alias summer_time ntp_timeZoneOfs -4

winter_time

// summertime
alias check1 if $month>3 then summer_time
alias check2 if $month==3&&31-$mday+$day<=6&&$day>0 then summer_time
alias check3 if $month==3&&31-$mday+$day<=6&&$day=0&&$hour>=2 then summer_time

// wintertime
alias check4 if $month>10 then winter_time
alias check5 if $month==10&&31-$mday+$day<=6&&$day>0 then winter_time
alias check6 if $month==10&&31-$mday+$day<=6&&$day=0&&$hour>=3 then winter_time

alias set_time backlog check1;check2;check3;check4;check5;check6

startDriver TuyaMCU
delay_s 2
uartSendHex 55AA001000070101090400010026
startDriver tmSensor

setChannelType 1 temperature_div10
linkTuyaMCUOutputToChannel 1 val 1

setChannelType 2 Humidity
linkTuyaMCUOutputToChannel 2 val 2

setChannelType 3 ReadOnlyLowMidHigh
setChannelLabel 3 "Batt_state"
linkTuyaMCUOutputToChannel 3 val 3
 
waitfor NTPState 1
set_time

// now wait for MQTT
waitFor MQTTState 1
// now wait for channel 1 to become non zero
// if channel 1 is still 0, loop, wait 0.1s and check again
again:
delay_s 0.1
if $CH1==0 then goto again
publish DATA {"ROOM":"1","TEMPERATURE":$CH1,"HUMIDITY":$CH2}



    but all the data in the web ui is 0s... and the log all I see tons of this:

    Code: text Expand Select all Copy to clipboard
    Info:TuyaMCU:Consumed 20 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Info:TuyaMCU:Consumed 20 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Info:TuyaMCU:Consumed 40 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Info:TuyaMCU:Consumed 20 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Info:TuyaMCU:Consumed 20 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Info:TuyaMCU:Consumed 20 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Info:TuyaMCU:Consumed 20 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Info:TuyaMCU:Consumed 20 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Info:TuyaMCU:Consumed 40 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Info:TuyaMCU:Consumed 20 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Info:TuyaMCU:Consumed 20 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Info:TuyaMCU:Consumed 20 unwanted non-header byte in Tuya MCU buffer
Info:TuyaMCU:Skipped data (part) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


    i verified the connections between the tuyamcu and the wifi module are ok, any hints?
  • #250 21762087
    p.kaczmarek2
    Moderator Smart Home  
    Don't do this:
    Code: text Expand Select all Copy to clipboard
    
if $CH1==0 then goto again

    It looks like an attempt to avoid data publish before measurement, but it could be easier maybe, if you measure often, just save the previous measurement in flash (Set channel startup value) to -1 so the value is remembered.

    Code: text Expand Select all Copy to clipboard
    uartSendHex 55AA001000070101090400010026

    This was never required with tmSnsor I think
    Helpful post? Buy me a coffee.
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

The discussion centers on the teardown, firmware modification, and protocol analysis of the TH08 LCD calendar/clock/temperature/humidity sensor powered by 3xAAA batteries with backlight, based on the BK7231N chip. The device is identified as a newer version of the TH06 model, featuring a TuyaMCU module communicating via a low-power Tuya serial protocol (version 00). Users successfully flashed OpenBK firmware without desoldering, enabling temperature, humidity, and battery monitoring with MQTT integration and NTP time synchronization. Key challenges included understanding the MCU-module communication, especially time synchronization commands and power management to optimize battery life. The MCU sends commands such as ObtainDPCache and ObtainLocalTime, with the WiFi module responding accordingly. Firmware updates improved battery consumption by ensuring the WiFi module powers down promptly after data transmission. The device’s RTC (U8) communicates with the MCU (U3) over a serial or I2C-like interface, with ongoing efforts to decode this traffic. Users experimented with modifying battery power sources, including LiPo and USB power mods with step-down regulators, confirming device operation at voltages between 3.3V and 4.5V. The Tuya app lacks options to adjust sensor reporting intervals, and attempts to change polling times via Tuya protocol commands were unsuccessful, likely due to firmware limitations. Serial sniffing and analysis tools like TuyaMCU Analyzer and SniffUART were used to decode dpIDs, confirming dpID 1 as temperature, dpID 2 as humidity, dpID 3 as battery state, and dpID 9 as Celsius/Fahrenheit setting. Firmware versions and MCU versions were compared, revealing some early versions had display update issues. The community contributed to improving OpenBK firmware to handle specific Tuya commands, including proper responses to WiFi signal strength queries, enhancing power management. MQTT integration with Home Assistant was refined, including battery level display improvements using LowMidHigh channel types. OTA updates and configuration changes require keeping the WiFi module powered, achievable via long button presses or hardware modifications. Attempts to use Tuya-cloudcutter for remote flashing were unsuccessful due to lack of matching profiles. Some users reported issues with sensor readings showing zero after flashing, possibly due to hardware revisions or firmware mismatches. Overall, the device is well-supported by OpenBK firmware with active community development focusing on power optimization, protocol decoding, and integration with home automation platforms.
Summary generated by the language model.
Today's popular
ADVERTISEMENT