logo elektroda
logo elektroda
X
logo elektroda

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

morgan_flint 32955 246
ADVERTISEMENT
📢 Listen (AI):
  • #241 21625858
    divadiow
    Level 35  
    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 ?
  • ADVERTISEMENT
  • #243 21693614
    sebgarske
    Level 5  
    >>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 5  
    I was able to collect some logs via TX2. The MCU RX/TX and Pin 8 are disconnected:

    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...
  • #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 5  
    >>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.
📢 Listen (AI):

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.
ADVERTISEMENT