logo elektroda
logo elektroda
X
logo elektroda

Beken BK7231/BK7252 SPI flashing and recovery - new flasher tool and protocol specs

p.kaczmarek2 11430 310

TL;DR

  • BK7231GUIFlashTool v98+ adds CH341-based SPI flashing and recovery for Beken BK7231/BK7252 chips, including bricked devices with overwritten bootloaders.
  • The tool uses CH341 DLL C# bindings to toggle CEN via D2, reset the chip, send 0xD2, then flash Beken chips like generic SPI memory.
  • Connections use P20, P21, P22, and P23 for SCK, CSN, SI, and SO, with CEN wired to D2 and the CH341 jumper set to I2C mode.
  • A sample read identifies JEDEC ID FF-EF-40-16 and a 4096 KB flash, and the same tool can Read, Write, Verify, and Erase firmware.
  • If CH341 is not detected or CEN toggle fails, check driver configuration, jumper position, SPI wiring, and power before trying Beken SPI mode again.
Generated by the language model.
ADVERTISEMENT
📢 Listen (AI):
  • #61 21716501
    insmod
    Level 31  
    >>21716364
    Ok, it's pretty much finished already.

    I'm playing with ECR6600. If stub is already uploaded - i got read code finished. Can't get it to upload stub by itself yet.
  • ADVERTISEMENT
  • #62 21716508
    p.kaczmarek2
    Moderator Smart Home
    I'll try to check this out briefly and merge within a hour. Then I am planning to add a support for remote flashing via any OBK device with TCP to UART driver. COM port will be wrapped into our class , with a base class as well, so I can create my "virtual TCP" com. For reset, Tasmota API commands will be used.

    I didn't do full testing but it seems to work more than it does not, so I hope that it will be manageable.

    The only piece missing is baud rate management, but I guess I can send a command for that as well. I'm not sure about the timing, tough.
    Helpful post? Buy me a coffee.
  • #64 21716583
    divadiow
    Level 38  
    insmod wrote:
    Improved BL602 erase logging

    interesting response

    BK7231 Easy UART Flasher interface in memory erasing process

    Code: Text
    Log in, to see the code


    Added after 10 [minutes]:

    ffs 👿. lol. that's the end of that 1mb module now. tried old fake Prolific TTL that must been labelled wrong (I think I remember it killing something before - BINNED NOW) and now she's pulling an unhealthy load and burning hot. good excuse to order another CozyLife DS-1211AN 👿

    Added after 5 [minutes]:

    yup. RX/TX measuring 4.7v, 5v=5v and even 3.3v = 3.7v. <sigh> moving on.

    Added after 1 [hours] 21 [minutes]:

    >>21716563

    im not having much luck today it seems. ECR6600 seems to read and write with success but never boots for me.

    Screenshot of BK7231 Easy UART Flasher showing Writing done message

    Booting OK with AIO RDTool flashing. erases in between. Here's the comparison of EF write vs RDTool write (confirmed blank in between each write) - both dumps taken with RDTool.
    Comparison of two binary files in a hex editor with highlighted differences

    but my setup can't be that much different to yours? the usual WG236 in ESP adaptor, flashing through on-board CH9102, other USB-TTL rigged up for log out from IO13/TX2

    Development board with SkyLab GPS module connected via jumper wires and USB.
  • ADVERTISEMENT
  • #65 21716665
    p.kaczmarek2
    Moderator Smart Home
    I've did futher tests of UART flash over the TCP. It seems that we can use higher baud rates, but a retry mechanism for page read is needed.
    Screenshot showing data transmission errors and hexadecimal memory readout
    Where did you get ECR6600 protocol specs? Is it also XModem?
    We need a supported features matrix...
    Helpful post? Buy me a coffee.
  • #66 21717005
    insmod
    Level 31  
    >>21716583
    Fixed write
    I forgot to replace startSector with flashOffset (from aio binary), and so everything was being written at 0x0.

    >>21716665
    Not xmodem, custom one.
    Some things i got from stub source (older one, i wasn't able to get write working with it, even though rdtool works fine with it).
    Things like stub upload and syncing i got by sniffing.
    eswin_ecr6600_1.0.0.zip\eswin_ecr6600_1.0.0_temp\eswin_ecr6600_os\uboot\include\uboot_cmd.h
    //REQ frame
    // ,-------+------+-------------+-------+----------,
    // | MAGIC | TYPE |  DATA_LEN   | DATA   |   CRC8   |
    // |   1   |   1  |     2      |   N   |     1    | <- size (bytes)
    // '-------+------+-------------+-------+----------'
    
    //ACK frame
    // ,-------+------+-------------+-------+----------+----------,
    // | MAGIC | TYPE |  DATA_LEN   | DATA   |  status  |   CRC8   |
    // |   1   |   1  |     2      |   N   |    1      |    1     | <- size (bytes)
    // '-------+------+-------------+-------+----------+----------'
    /** magic */
    #define MAGIC                   0xA5 // start of a frame
    #define ACK_MAGIC                0x5A 
       
    /** massage type */
    #define STATE_ERR                  0xFF
    #define STATE_SYN                  0x00
    #define STATE_RAM_DOWNLOAD         0x01
    #define STATE_FLASH_DOWNLOAD       0x02
    #define STATE_FLASH_UPLOAD         0x03
    #define STATE_FLASH_ERASE          0x04
    #define STATE_FLASH_CHIPERASE      0x05
    #define STATE_RUN               0x06
    #define STATE_BOUND               0x07
    #define STATE_EFUSE               0x08
    #define STATE_MAX               0x08
       
    /** status */
    #define STATUS_SUCCESS            0x00
    #define STATUS_ERROR            0x01
    #define STATUS_ADDR_ERROR         0x02
    #define STATUS_TYPE_ERROR         0x03
    #define STATUS_LEN_ERROR         0x04
    #define STATUS_CRC_ERROR         0x05
    
    
    /** RESPONSE */
    #define RESPONSE_FAIL            0xFF
    #define RESPONSE_OK               0x00
    #define RESPONSE_SYNC_BOOTROM      0x01
    #define RESPONSE_SYNC_SBL         0x02
    
    /** ACK message define */
    #define ACK_OK  0x00
    #define ACK_ERR 0x01
    
    /** message response status */
    #define MSG_OK 0x00
    #define MSG_ERR -1
    
    
    /** sync */
    #define SYNC_REQUEST_VALUE         0x73796E63   /* sync */ 
    #define SYNC_REQUEST_SIZE         0x04
    #define SYNC_REQUEST_TIMEOUT      120  // 2 min
    
    
    /** all size */
    #define HEAD_SIZE               4
    #define CFG_SIZE               8
    #define ACK_SIZE               6
    #define CMD_DATA_MAX_LEN          (4 + 1 + 1024*64 + 2) //max command data length 64K
    #define RESPONSE_SIZE            0x01
    #define LOAD_MAX_SIZE_BIG         0x10000
    ...
    ...
    
  • Helpful post
    #67 21717026
    divadiow
    Level 38  
    yep. OK now. OpenECR boots

    Screenshot of BK7231 Easy UART Flasher after successful ECR6600 firmware flash

    Added after 4 [minutes]:

    generally-speaking, the ECR6600 flashing/reset window of opportunity is a pain. it's not too bad though
  • #68 21717035
    p.kaczmarek2
    Moderator Smart Home
    Yes! That's a really quick development pace!

    @divadiow would you be able to prepare "OBK self replication" setup? Like that:
    Development board with connected module via jumper wires on a wooden table
    It is almost ready - I am adding retry mechanisms.
    Sector erase failure in console output with C# code below
    Helpful post? Buy me a coffee.
  • #69 21717043
    divadiow
    Level 38  
    can try. about to leave home until tomorrow. will take a few things with me.
  • #70 21717045
    insmod
    Level 31  
    Improved syncing, now it will attempt to sync 500 times before giving up.
    RST to GND worked, don't know if power toggle would work.
  • #71 21717071
    p.kaczmarek2
    Moderator Smart Home
    This retry works so good that I am starting to wonder, why we don't actually have a retry in Beken sector erase/read/write code? It could help with some errors, maybe...
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #72 21717076
    insmod
    Level 31  
    >>21717071
    I remember i asked the same question recently.
    And that's why i implemented read retry on ECR.
    I tried to implement write retry, but stub is crashing (?) if incorrect packet is sent. Requires a reset because of it.
  • #73 21717114
    p.kaczmarek2
    Moderator Smart Home
    Hopefully I'll be able to play around with it more soon.

    Currently, I'm doing mine experiment in a separate C# project. It's almost ready. It will cover remote Beken read, erase and write, along with unprotect. All you need is a target device with CEN on channel 1 and TCP to UART driver.

    Once tested, I will try to add this feature seamlessly to Easy Flasher, so basically, as I said, abstraction layer for COM port, and some kind of wrapper/call for CEN toggle.

    I'm curious how well will it work with other chips.
    Helpful post? Buy me a coffee.
  • #74 21717541
    divadiow
    Level 38  
    insmod wrote:
    Improved syncing, now it will attempt to sync 500 times before giving up.

    that's better. left it a while then flicked RST low

    BK7231 Easy UART Flasher program showing successful firmware upload to ECR6600

    Added after 11 [minutes]:

    insmod wrote:
    Supports full chip erase.

    are you getting it confirm finish erase? I took backup after and the chip is blank, I just wasn't sure initially if it completed ('read done' status in image is from previous operation)

    BK7231 Easy UART Flasher interface with Read done message
  • #75 21717557
    insmod
    Level 31  
    >>21717541
    There is no text confirmation, but if buttons are enabled - then it's finished.
  • #76 21717558
    divadiow
    Level 38  
    insmod wrote:
    but if buttons are enabled - then it's finished

    good point

    Added after 14 [minutes]:

    p.kaczmarek2 wrote:
    why we don't actually have a retry in Beken sector erase/read/write code?

    Realtek Z2 would benefit from this too. I struggle to get a complete read often still, even with prime conditions - short new cables, BW15

    ESP32 module connected to USB-UART converter with jumper wires on a wooden surface

    BK7231 Easy UART Flasher interface with memory reading in progress

    Added after 9 [minutes]:

    BK7231 Easy UART Flasher interface showing connection error message during read
    I'll try other USB-TTL
  • #77 21717738
    p.kaczmarek2
    Moderator Smart Home
    I have worked a bit more on WiFi flasher. I've added a commandline, but I also have bad news.
    Commandline:
    
    OBK WiFi Downloader.
    
    positional arguments:
      filename              specify file_crc.bin
    
    optional arguments:
      -h, --help            show this help message and exit
      -d DEVICE, --device DEVICE
                            Target device, default 192.168.0.1:8888
      -s STARTADDR, --startaddr STARTADDR
                            burn flash address, defaults to 0x11000
      -l LENGTH, --length LENGTH
                            length to read, defaults to 0x1000
      -b BAUDRATE, --baudrate BAUDRATE
                            burn uart baudrate, defaults to 921600
      -u, --unprotect       unprotect flash first, used by BK7231N
      -r, --read            read flash
      -w, --write           write flash
      -t, --test            test flash (generate pattern, write, read, verify)
      -v, --verify           verify flash
      
         
        -w -s 0 -u OpenBK7231N_QIO_1.18.193.bin
         
         
            Short test:
            -u -t -s 0 -l 0x2000
            Long test:
        -u -t -s 0 -l 0x100000
    

    The bad news is that it somehow started having issues with getting bus. I am short on time, so I didn't do excessive testing, so I am a bit confused on what happened - is it the latency issue? Latency has changed on my WiFi? Or was it due to the flash content change of target Beken, maybe it was in a state where it was constantly rebooting so CEN wasn't really used?
    At least it's still working, it just needs like half a minute to get bus.

    It is possible that I will have just need to make a tiny utility for getting bus on OBK itself (not via remote commands). It seems it's hard to get precise timing by sending pin toggle via HTTP and UART packet via TCP to UART.

    Or maybe... if uartSendHex still works with TCP to UART, then maybe I can backlog hex send and CEN toggle for better timing, hmmm

    I think I will release it tomorrow in a separate topic.
    Helpful post? Buy me a coffee.
  • #79 21718069
    p.kaczmarek2
    Moderator Smart Home
    Hmm, if you do uartInit 115200, and then uartSendASCII xyz, do they see each other? I mean, with my fix from there:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1829
    Helpful post? Buy me a coffee.
  • #80 21718575
    insmod
    Level 31  
    W800 flasher: https://github.com/openshwprojects/BK7231GUIFlashTool/pull/74
    Backup restore is only possible if it's a full image, with secboot header at 0x2000.
    If not, then program's behaviour is undefined.
    Considering how it handles writes, i didn't even try to add config write. Read is working fine though, even if config is a 2016 bytes version.

    Full xmodem implementation included. I don't remember where i got it though, just found it in my downloads.
  • #81 21718629
    divadiow
    Level 38  
    nice. I have flashed OBK OK to W800.

    base64 of that stub looks identical to w800_fls_erase.img pulled from Upgrade Tools https://www.elektroda.com/rtvforum/topic4120455.html#21542722

    I took a couple of backups of real devices previously with the Upgrade Tools inspired read scripts and was never sure if they were any good.
    https://github.com/openshwprojects/FlashDumps/tree/main/IoT/W800

    Attempts to write them back (CozyLife_Breaker_RMW002_TW-803_w800_flash_read_crc_flush_double.py.bin and HLK-B36_w800_flash_read_crc_flush_double.py.bin)
    Screenshot of BK7231 Easy UART Flasher showing Write error! during firmware flashing

    I'll fiddle. I have another untouched CozyLife with TW-803 so it'll be interesting to do an EF read of that to see how the backups compare.

    HLK-W801-KIT_(uni_app.fls)_HLK-CB103-V2.0.0.fls and YourCee_Tuya_w800_light_5_rgbcw_v2_1.0.8_release.fls do write and boot.
  • #82 21718630
    insmod
    Level 31  
    >>21718629
    Do not change backups extension to fls

    Added after 2 [minutes]:

    And rename them to start with "readResult_"
  • #83 21718634
    divadiow
    Level 38  
    woohoo! they boot. that pleases me a lot knowing they are OK. cheers

    Screenshot of BK7231 Easy UART Flasher tool showing Writing done message

    Added after 6 [minutes]:

    curious about the flash ID read. Do you know why full ID isn't reported? Not that it's that important I guess?
    Application interface with programming logs and PID: 0x85x15 highlighted

    Added after 1 [minutes]:

    and what's your take on the gain toggling?
  • #84 21718639
    insmod
    Level 31  
    >>21718634
    Gain doesn't matter.
    And on W600 flash id command outputs either 1 or 2 bytes, i'm not sure which, because i get 1C, and C can be just a part xmodem crc spam.
    Anyway, last 2 bytes are enough to get flash size. And W600 doesn't support flash read.
  • #86 21718648
    insmod
    Level 31  
    >>21718645
    If it's even possible to upload something to ram in rom mode.
    Then all the other commands must be implemented. Manually, since there is no code for any rom function.
  • #87 21718658
    divadiow
    Level 38  
    OK sure.

    trying W600. seems OK.
    BK7231 Easy UART Flasher interface showing successful W600 firmware flash
    I see it picked up previous config on device (startdriver tuyamcu)

    Added after 5 [minutes]:

    Thought I'd give the W600 HC-25_AT.bin JLink backup a go

    Code: Text
    Log in, to see the code

    that's with file named as readResult_HC-25_AT.bin
  • #88 21718668
    insmod
    Level 31  
    >>21718658
    I didn't even try to implement W600 backup flashing, since uart read is not possible.
    Only fls for W600 i'm afraid.
  • ADVERTISEMENT
  • #90 21718682
    insmod
    Level 31  
    No, and they are only for Z, not Z2.
    For Z2 i tried to check hash every sector, but that way it is much slower on 2000000 baud than 115200 without it.
📢 Listen (AI):

Topic summary

✨ BK7231GUIFlashTool version 98 and later introduces a new SPI flashing method for Beken BK7231/BK7252 devices using only a CH341 SPI programmer. This method enables recovery of bricked devices with overwritten bootloaders and functions as a general-purpose SPI flasher supporting various memory chips. The approach builds on previous SPI programming techniques using Python and Banana Pi, adapting them for CH341 hardware and C# implementation. Required hardware includes a CH341 programmer and soldering tools for wire attachment. Recent user feedback on version 98 highlights issues such as the tool requiring a COM port selection in SPI mode, lack of CH341A detection warnings, and missing ch341dll.dll errors. The developer has addressed the COM port requirement and plans to add the missing DLL, requesting further debugging via Visual Studio to handle CH341 initialization exceptions.
Generated by the language model.

FAQ

TL;DR: New BK7231GUIFlashTool v98+ adds SPI flashing for Beken chips; sample 4,096 KB flash detected. “Only a CH341 SPI programmer is required.” Use CH341A D2 to toggle CEN, send 0xD2, then read/write like generic SPI. [Elektroda, p.kaczmarek2, post #21711721]

Why it matters: It lets you recover bricked BK7231/BK7252 devices without a working bootloader, using low‑cost tools.

Who this is for: DIYers, repair techs, and firmware engineers asking how to unbrick or mass‑flash Beken SoCs via SPI with a CH341A and the latest tool.

Quick Facts

What exactly is the new Beken SPI flashing method and what do I need?

The tool drives CH341A as an SPI master, resets BK via CEN on D2, sends 0xD2 to enter BK’s SPI-memory mode, then treats the chip like a standard SPI flash. You need a CH341A (jumper at I2C), 3.3 V power, and wiring for P20–P23 (SCK/CSN/SI/SO) plus CEN. Select “Beken SPI” in BK7231GUIFlashTool v98+. “Only a CH341 SPI programmer is required.” [Elektroda, p.kaczmarek2, post #21711721]

How do I wire CH341A to BK7231/BK7252 for SPI mode?

Connect CH341A SCK→P20, CS0→P21, MOSI→P22 (SI), MISO→P23 (SO), and D2→CEN. Keep MOSI→SI and MISO→SO mapping. Provide GND and target power. Some boards have pads labeled CE/TCK/TMS/TDI/TDO that map to CEN/SCK/CSN/SI/SO respectively. [Elektroda, p.kaczmarek2, post #21711721]

How do I reliably enter BK SPI mode? (3‑step)

  1. Use CH341 D2 to pull CEN low then high to reset the BK chip. 2. Stream 0xD2 bytes repeatedly over SPI. 3. Issue 0x9F and confirm a valid JEDEC response; then proceed to Read/Write/Erase. [Elektroda, p.kaczmarek2, post #21711721]

I get “Failed to open CH341 device” or “Failed to toggle CEN.” What should I check?

Confirm CH341A is jumpered to I2C, recognized by Windows, and the D2 wire is soldered to CEN. Re‑seat USB, power the target, and verify SPI lines. The tool logs these errors when CH341 isn’t detected or CEN can’t be driven; fix wiring or driver, then retry. [Elektroda, p.kaczmarek2, post #21711721]

The app says “missing ch341dll.dll” or quits in SPI mode—how do I fix that?

Place CH341DLL.DLL alongside the GitHub build, or build from source in Visual Studio. Earlier builds could exit if CH341A wasn’t present; recent fixes improved handling, but adding the DLL resolved missing‑library errors during testing. [Elektroda, divadiow, post #21712310]

Do I need to select a COM port for SPI flashing?

No. As of v99, SPI mode does not require a COM port. This was confirmed after fixes; previous v98 prompts were removed. Ensure CH341A is connected; SPI operations run without a serial port. [Elektroda, divadiow, post #21712310]

What does the Verify button do?

Verify compares flash contents against the firmware file currently selected in the tool. Use it after Write or Erase to confirm success. “Verify verifies against selected firmware.” [Elektroda, p.kaczmarek2, post #21712551]

Can this recover a bricked BK7252 camera?

Yes. After wiring CEN and SPI lines, use Beken SPI mode to read/erase/write. The author provides a BK7252 camera recovery example using this exact method with CH341A and the new flasher. [Elektroda, p.kaczmarek2, post #21711721]

Can I use CH341 Programmer or NeoProgrammer once SPI mode is active?

Yes. After the 0xD2 hand‑off, the BK behaves like a generic SPI flash. You can then operate with common SPI flash tools (CH341 Programmer or NeoProgrammer) if you prefer. [Elektroda, p.kaczmarek2, post #21711721]

Linux support: what baud rates are stable under mono?

Mono 6.12 worked for testers. They reported stable operation at 921,600 baud; 1,500,000 worked on Windows, but they lowered to 921,600 on Linux. LAN Scanner and release downloader also worked. [Elektroda, insmod, post #21712663]

The tool shows a 4,096 KB device. Is that normal for these chips?

Yes. A sample JEDEC ID FF‑EF‑40‑16 decoded to 4,096 KB and printed by the tool. That confirms JEDEC read and size decoding in SPI mode. Actual sizes vary by module; always check the tool’s detected flash size. [Elektroda, p.kaczmarek2, post #21711721]

How do I just switch a BK device into SPI mode without reading or writing?

Use the new “Detect” button. It performs a zero‑length custom operation to toggle CEN and send the 0xD2 sync, placing the chip in SPI mode for use with other SPI tools. [Elektroda, p.kaczmarek2, post #21731041]

I flashed many times and now erase fails. What should I try?

Expand Unprotect logic before erase, similar to AsProgrammer. A contributor noted needing stronger Unprotect after many BK7252 cycles. Add an Unprotect/Status-Register release step, then retry the erase/write. [Elektroda, p.kaczmarek2, post #21714737]

What is OpenBeken (OBK) in this context?

OpenBeken is an open‑source firmware used across supported Wi‑Fi MCUs in this ecosystem. The author uses OBK devices for testing and demos, including camera boards and remote flashing concepts. [Elektroda, p.kaczmarek2, post #21714427]

Can I flash a BK device over Wi‑Fi/TCP instead of USB?

Yes, a Wi‑Fi flasher demo proxies UART over TCP and controls CEN via an OBK device. It’s a separate utility that mirrors the BK UART routines, useful when PC‑to‑target wiring is hard. [Elektroda, p.kaczmarek2, post #21720013]

Any known edge cases or failure symptoms I should expect?

If CH341DLL is missing, some GitHub builds previously exited. On mono/Linux, 1,500,000 baud may fail while 921,600 works. Also, after heavy cycling, protection bits may block erase until Unprotect expands. Address each symptom as noted, then retry. [Elektroda, divadiow, post #21712310]
Generated by the language model.
ADVERTISEMENT