logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

OpenBeken on Tuya Water Leak Sensor with BK7238 (T1 U HL): Pin Pull-Up Issue?

smith3 393 4
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #1 21819811
    smith3
    Level 2  
    I hope you all excuse me since I'm a bit of a beginner here.

    I have a small water leak sensor from AliExpress that I would like to re-flash with OpenBeken. It is branded as a Tuya device. Inside there is a T1 U HL chip which seems to correspond to a BK7238. I have a UART attached and am running BK7231Flasher.exe using mono under Linux. Communication seems to work at 921,600 baud without any glitches.

    I copied the stock firmware but the Flasher app could not detect any Tuya configuration information. I installed OpenBK7238_QIU_1.18.248.bin. Just poking around the circuit I came to these conclusions:

    pin 1 P14: 72 mV, goes to 0 V when device button is pushed
    pin 2 P16: LED
    pin 5 ADC/P20: maybe this is battery voltage related (measures 2.5 V)
    pin 19 P21: This is 0 V and pulls to "high" when the water sensor is shorted.

    I can't get any wifi communication going at all (yet). Nor have I had any luck with serial debug communication. So all of these changes I have tried, I tried with that "change OBK settings for flash write" button "write only OBK".

    The thing is, with stock firmware P14 (pin 1) is "high" and pulled to 0 V when the device button is pushed. I tried adding Btn_ScriptOnly on channel 0 for P14, but it's still not pulled high (measures 72 mV and is pulled low from that low level by the button).

    I figure it cannot work if the device thinks the button is pushed. So how do I set this pin to be pulled up internally?

    If I can even start to get it working I will post pictures, at this stage I just have to see if there is any chance of even getting OpenBeken running at all first.

    Is OpenBeken even running on the device you think? I can reflash it with stock firmware and it behaves like stock firmware again, so it's not broken.
    From Display to Complete System: How the Solution Team Creates Value at Unisystem [ad]
  • ADVERTISEMENT
  • #2 21820678
    smith3
    Level 2  
    >>21819811 A quick update. I am still not sure if OpenBeken is running at all. I measured some of the microcontroller pin voltages when the stock firmware was running. It appears P24 drives some kind of circuit with a transistor or FET that pulls P14 up. (P14 is the pin the button is connected to). It also has some connection to the ADC. P16 clearly controls the LED (voltages correspond to LED blinking with stock firmware)

    However, I tried setting P24 and P16 "manually" by entering the below into that "Short Startup Command" box in the BK7231Flasher.exe GUI application ("change OBK settings for flash write" dialog, and then "write only OBK config":

    Code: text Expand Select all Copy to clipboard
    GpioSet 24 1 
GpioSet 16 1 


    This configuration "takes" (I can read it back) but it appears OpenBeken is not running... P24 and P16 remain low. There is also no serial activity or of course access point visible.

    What's a bit mystical is that when I short the CEN pin with minicom open (and BK7231Flasher.exe not running) I still get this string:

    Code: text Expand Select all Copy to clipboard
    
BK7238_1.0.15                                                                             
REG:cpsr        spsr        r13         r14                                               
SVC:0x000000D3              0x00401C1C  0x000033A0                                        
IRQ:0x000000D2  0x00000010  0x00401E0C  0xF7AFEF9B                                        
FIR:0x000000D1  0x00000010  0x00401FFC  0xAB766FA1                                        
SYS:0x000000DF              0x0040192C  0x00000158                                        
ST:0x00000000                                                                             
[I/FAL] Fal(V0.4.0)success                                                                
[I/OTA] RT-Thread OTA package(V0.2.8-beken-1133282d-20220604) initialize success.
                                                                                          
                                                                                          
go os_addr(0x10000)..........


    But maybe this is not evidence of OpenBeken actually running, more just what firmware image is presently loaded?

    I wonder a bit what tree I could bark up next. What could I have done wrong flashing this firmware image?
  • ADVERTISEMENT
  • #3 21824060
    afaik4711
    Level 3  
    Hey,
    I am also a beginner to OBK, but had similar problems as you. I thought my CB3S was a BK7238 when the chip was actually a BK7231. The flasher did a backup and write successfully, but after that, nothing happened.
    To resolve my issue, I restored the backup using the BK7238 settings and then starting over with BK7231 settings. After a reboot (RX/TX disconnected), the device powered up. I hope it helps
  • ADVERTISEMENT
  • #5 21824070
    smith3
    Level 2  
    I actually also got mine running now. I figured I would get a sort of good config and then open a completely new thread about it with proper pictures, etc., and referencing this thread.

    In my case I suspect it was that the battery voltage was a bit too low after flashing. I left it sitting for a day, connected it to a "solid 3.3 V" with serial disconnected, and, all of a sudden, it did boot.

    Added after 6 [hours] 12 [minutes]:

    I have what must be a newbie problem. I am attempting to do something like this in a script thread:

    Code: text Expand Select all Copy to clipboard
    // Channel 1 controls off/on state of siren

mainLoop:
setChannel 10 0
delay_s 1

beepLoop:
if $CH1==0 then "goto mainLoop"

setChannel 10 50
delay_ms 250
setChannel 10 0
delay_ms 250

goto beepLoop


    Channel 10 is a PWM channel driving a little piezo speaker. If I set it to 50 it works. The problem with the above cose is that the beeping block above never gets executed, it's as if this "if" statement does not correctly evaluate the state of channel 1. (I can see "channel 1 = 1.00" on the main interface when I short the water sensor pins.) It's set as a digital input now just for testing, I know the beeping logic works because if I comment out the "if" statement it beeps forever.

    I guess will get into any deep sleep issues after I figure out how to properly write an 'if' statement 😭
Reply | New topic
Report a violation of the law
Today's popular
ADVERTISEMENT