logo elektroda
logo elektroda
X
logo elektroda

Taobao Tuya BK7252UQN68 Bare A9 Cam PCB (SC-10024 v1.0.0) - UART/SPI Flash Backup - OpenBK7252

divadiow 3180 76
ADVERTISEMENT
  • #61 21706892
    insmod
    Level 30  
    >>21706885
    Yes, and it's that way on every beken, whether encrypted or not.
    Every 32 bytes of data is followed by 2 bytes of crc

    You can create a script that would remove those bytes to get readable strings, if required.
  • ADVERTISEMENT
  • Helpful post
    #62 21706923
    p.kaczmarek2
    Moderator Smart Home
    That's a ... a very common occurence of CRC, isn't it? I was under impression that mere bits are needed to check the validity of very large buffers, and here they use 16 bits per 32 bytes...

    I think I can read, erase and write memory now - also with full chip erase (and with status register checks):
    Terminal window showing flash memory read/write via SPI interface
    Nothing really new here, the same I did there: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_spi_flash.c
    I will pack this into some C# class and prepare either a standalone tool or a EF update.. or both, not sure.

    Added after 16 [minutes]:

    I ordered one camera from local supplies, but I have a feeling it will be XR again.
    Mini Wi-Fi camera with smartphone app showing live footage
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #64 21707462
    p.kaczmarek2
    Moderator Smart Home
    @divadiow this Beken SPI is basically generic SPI + Beken RESET. As you probably know... since you've used NeoProgrammer.
    This brings the question - can we use EF as generic SPI flasher? I think we can! Do you have BIOS chips to try?

    My next camera is with delivery courier.
    Helpful post? Buy me a coffee.
  • #65 21707472
    divadiow
    Level 37  
    p.kaczmarek2 wrote:
    Do you have BIOS chips to try?


    Taobao Tuya BK7252UQN68 Bare A9 Cam PCB (SC-10024 v1.0.0) - UART/SPI Flash Backup - OpenBK7252
    plus all the usual loose chips and actual devices...
  • #66 21707477
    p.kaczmarek2
    Moderator Smart Home
    What kind of board is it? I haven't seen it yet. I only do this that way:
    https://www.elektroda.pl/rtvforum/topic3993012.html
    Helpful post? Buy me a coffee.
  • #68 21707518
    p.kaczmarek2
    Moderator Smart Home
    Ok I think I've found them. I was not aware that there is this kind of breakout, but it makes sense in a hindsight.
    W25Q32 flash memory module with SPI interface on blue PCB board
    Helpful post? Buy me a coffee.
  • #69 21707521
    divadiow
    Level 37  
    ok, sure. yes. Ali Express, the cave of wonders
  • ADVERTISEMENT
  • #70 21738867
    divadiow
    Level 37  
    >>21705726

    still curious about this. did you pursue anything else with it?

    I want to play more but time (and speed/skill level) is, as always, the limiter.

    I started to look at XF16 JPEG build but lost momentum for now.

    The Xradio documentation looks quite good for SDK/Jpeg dev
  • #71 21761349
    divadiow
    Level 37  
    insmod wrote:
    https://github.com/NonPIayerCharacter/OpenBK7231T_App/actions/runs/18136281276 if interested
    BK7252N and BK7252 log is on UART1


    Code: Text
    Log in, to see the code


    thought I'd give this a go. not found where IOs set are used yet though in cam build.

    This is a new 18-pin cam doorbell BK7252UQN48, not Tuya, unencr.

    J1 camera module pinout diagram with DVP signal labels and P0–P39 mappings
  • #72 21773315
    easton
    Level 1  
    >>21706031
    Based on the boot logs (SDK 3.0.33), the BK7252UQN48 appears to be the older BK7252 core (BLE 4.2), not the newer BK7252N (BLE 5.2). It looks like 'U' just denotes the QFN48 package for the original silicon.

    This naming matches the pattern seen in the BK72XX_SDK_User_Manual-3.0.3.pdf (attached) for the BK7231, where 'U' was the older BLE 4.2 core and 'N' was the upgrade to BLE 5.1.

    The pin mapping for BK7252UQN48 matches the BK7252N datasheet QFN48 (attached), so you can use that to trace the UART pins.
  • ADVERTISEMENT
  • Helpful post
    #73 21773580
    divadiow
    Level 37  
    well, regarding a QFN48 U and N pin comparison, here is my independent work-in-progress tracing of IOs on BK7252UQN48 alongside the BK7252N QFN48 from the datasheet. I'd not married the two until now.

    Pin mapping comparison of BK7252N and BK7252UQN48 in QFN48 package

    not sure what to make of the GNDDIG label now though. I'm sure it had continuity with GND. I'll recheck.



    EDIT: Updated image correcting GNDDIG label for VDDRAM
  • #74 21773619
    p.kaczmarek2
    Moderator Smart Home
    Helpful post? Buy me a coffee.
  • #75 21773623
    divadiow
    Level 37  
    Well that was my assumption based on BK7252U QFN68 label, which is known, and the fact that it had continuity with ground. The thing now is that, if it is indeed GNDDIG, then that differs from the BK7252N datasheet, and so the BK7252N pin diagram can't be totally relied on for understanding BK7252U QFN48. I hope that makes sense!
  • #76 21773630
    p.kaczmarek2
    Moderator Smart Home
    Well, putting VDD in place of GND is a serious change. Even the PIC microcontrollers, which I used to program during school days, try to keep their VDD/GND footprint compatible between MCU variations. And here we have a straight up power to ground swap...
    EDIT: IMAGE REMOVED TO AVOID CONFUSION
    Helpful post? Buy me a coffee.
  • #77 21773645
    divadiow
    Level 37  
    Yep ok. Will confirm with continuity and voltage measurement later today

    Added after 7 [hours] 7 [minutes]:

    yikes. it carries a voltage. 3.62v. original image updated. annoying because I usually triple-check to avoid exactly this.

Topic summary

A bare A9-type PCB (SC-10024 v1.0.0) featuring the BK7252UQN68 chip was purchased from Taobao without camera, battery, or casing. The board includes an 18-pin camera connector, two buttons, and two LEDs (red and two-tone blue/green). Attempts to obtain an SDK from the seller were unsuccessful. Efforts to locate Tuya firmware download URLs programmatically also failed. Flashing combined OpenBK7252 firmware files enabled OTA functionality on first boot, confirming OTA support despite requiring SPI flash programming. Logs indicate successful OTA initialization and app partition erase/write operations. Some malloc failures were observed, possibly due to differences in memory allocation methods between OTA and default A9 bootloader environments. Further testing or suggestions for additional experiments were requested.
Summary generated by the language model.
ADVERTISEMENT