logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?

divadiow 783 18
Best answers

How can Easy Flasher reliably check BK chip IDs to stop flashing when the selected Beken chip does not match the connected device?

Yes—add a chip identity check that stops flashing when the connected BK chip ID does not match the selected target, and log a warning if the chip should return an ID but does not so the user knows the wrong chip may be selected [#21878112][#21878046] The proposed approach is to move chip-ID handling into a separate `BKChipIdentity.cs` file with a dictionary of supported chips plus a few OBK-unsupported ones [#21878112] The existing “skip key check” option should be expanded to “skip chip/key check” so users can intentionally bypass the check when probing unknown or mismatched variants [#21879350][#21879872] BK7231M was treated as a special case during testing, with its key check reinstated to match BK7231N, and BK7258 still needed more work because its check behavior was not right yet [#21879350]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • Helpful post
    #1 21876721
    divadiow
    Level 38  
    Posts: 4912
    Help: 430
    Rate: 873
    <post moved from here to keep separate>

    @DeDaMrAz suggested a more robust chip ID check in EF so in the cases where mislabelled CB2S may actually be a BK7231T and not a BK7231N, Easy Flasher will flag and stop current operation before starting. This suggestion was based on real recent experience.

    So maybe something like https://github.com/openshwprojects/BK7231GUIFlashTool/pull/118/changes?w=1

    -move chipID stuff into new file Flashers\BKChipIdentity.cs
    -chipid dictionary for supported and a couple of OBK-unsupported BK chips
    -if chip should return chip ID but fails to, log warning to suggest wrong chip may be selected. eg, BK7231N selected, BK7231T device:
    Screenshot of BK7231 Easy UART Flasher showing “Interrupted by user” and read error logs.
    -if chip returns ID not matched to selected chip, log fail and stop. eg, BK7238 selected but BK7231N device:
    Screenshot of BK7231 Easy UART Flasher showing a warning that the selected chip type is wrong.

    -expand use of 'skip key check' to 'skip chip/key check'
    Screenshot of a tool window with tabs “LAN Scanner”, “UART timeouts”, and “BK7231N Decryption”.
    eg, BK7238 selected, BK7231N device, skip checked:
    Screenshot of BK7231 Easy UART Flasher showing “Reading success!” and COM6 settings

    -BK7231M behaviour remains as no key check enabled by default but does log chip ID:
    Screenshot of BK7231 Easy UART Flasher showing “Reading success!” and a flash read log.

    I do not have BK7258/BK7236.


    03/04/2026 - I do now have BK7258 - will check and post again
  • ADVERTISEMENT
  • #2 21877804
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14464
    Help: 650
    Rate: 12476
    It looks like you've added override check for BK7231M?
    Screenshot of C# code with MatchesSelected and ShouldWarnSelected methods, with red boxes around if statements
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #3 21877808
    divadiow
    Level 38  
    Posts: 4912
    Help: 430
    Rate: 873
    I'll check it all over. BK7258 behaviour isn't right for checks. Is this even something you'd want added to EF1? I know @DeDaMrAz would like something..
  • #4 21878046
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14464
    Help: 650
    Rate: 12476
    Yes I think we can add it if it works reliably and has no drawbacks.
    Helpful post? Buy me a coffee.
  • #5 21878112
    DeDaMrAz
    Level 22  
    Posts: 600
    Help: 34
    Rate: 127
    I came across some mislabeled device the other day and was confused AF of what was wrong and since @divadiow is knee deep in flasher tool I asked for that feature.

    Also from my previous life when mobile phones were still not "smart" and I created some software for them it was a general rule to first get the flash chip type/size SW/FW numbers etc, and then phone model, as that then can be used to enable available features for that model only and set up all the rest based on chip geometry etc.
    Basically it was done with one button that would check certain known addresses that would contain those strings and that way cross flashing was avoided and all sorts of things. For example Siemens was my area of interest back then and they had like 18 different models supported by one tool, similar to what we have now.

    7258 is more complicated than I first thought as it is a weird 3 core chip, tried to port OBK to it but was not successful and i gave up to focus on some more "pressing" issues but will revisit at some point.
  • ADVERTISEMENT
  • #6 21878434
    divadiow
    Level 38  
    Posts: 4912
    Help: 430
    Rate: 873
    DeDaMrAz wrote:
    7258 is more complicated than I first thought as it is a weird 3 core chip, tried to port OBK to it but was not successful and i gave up to focus on some more "pressing" issues but will revisit at some point.


    cool. existing 3.0.78 SDK or did you give the Armino one a go?
  • Helpful post
    #7 21878452
    DeDaMrAz
    Level 22  
    Posts: 600
    Help: 34
    Rate: 127
    divadiow wrote:
    cool. existing 3.0.78 SDK or did you give the Armino one a go?


    Tried both for fun and had more success with 3.0.78 but it requires more time so I had to move on from it. It i doable just time consuming and I am yet to see a device with that chip.
  • ADVERTISEMENT
  • #8 21879350
    divadiow
    Level 38  
    Posts: 4912
    Help: 430
    Rate: 873
    p.kaczmarek2 wrote:
    It looks like you've added override check for BK7231M?


    the thinking was that BK7231M should remain free and easy in case it's ever NOT a BK7231N, but I guess that's not ever going to the case? Also, one BK that doesn't do a ChipID check might be useful if a new variant ID is tried on EF. If the checks were for every chipset it would fail at the first hurdle if the device returned an ID not matched. Would you rather BK7231M had ID check to match BK7231N?

    Added after 1 [minutes]:

    divadiow wrote:
    Also, one BK that doesn't do a ChipID check might be useful if a new variant ID is tried on EF


    but that's what the skip key/ID check checkbox can be used for, so .. dunno

    Added after 59 [minutes]:

    reinstated BK7231M key check to match BK7231N - 
    7231c


    BK7231M mode with BK7238 connected
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    BK7238 mode with BK7238 connected
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    BK7231M mode with BK7231M (Uascent zero-keys BL2028N) connected
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    BK7231N mode with BK7231M (Uascent zero-keys BL2028N) connected
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    BK7231N mode with BK7231M (Uascent zero-keys BL2028N) connected + skip key/chip ID check selected
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    BK7231N mode with BK7231N (Tuya CB3S) connected
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    BK7231M mode with BK7231N (Tuya CB3S) connected + skip key/chip ID check selected
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    BK7231T mode with BK7231T (Tuya WB3S) connected
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    BK7252 mode with BK7231T (Tuya WB3S) connected
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    BK7258 mode with BK7258 connected
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    BK7231N mode with BK7258 connected
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    BK7231M mode with BK7258 connected
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    BK7231M mode with BK7258 connected + skip key/chip ID check selected
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
  • #9 21879872
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14464
    Help: 650
    Rate: 12476
    divadiow wrote:
    Also, one BK that doesn't do a ChipID check might be useful if a new variant ID is tried on EF. If the checks were for every chipset it would fail at the first hurdle if the device returned an ID not matched. Would you rather BK7231M had ID check to match BK7231N?

    Added after 1 [minutes]:

    divadiow wrote:
    Also, one BK that doesn't do a ChipID check might be useful if a new variant ID is tried on EF


    but that's what the skip key/ID check checkbox can be used for, so .. dunno


    checkbox is good enough, merge ready?
    Helpful post? Buy me a coffee.
  • #10 21879874
    divadiow
    Level 38  
    Posts: 4912
    Help: 430
    Rate: 873
    p.kaczmarek2 wrote:
    checkbox is good enough, merge ready?

    I put it into draft. Was going to tidy bom/whitespaces. Don't have if you're not bothered about that. PR just looked messy

    Added after 3 [hours] 52 [minutes]:

    OK ready
  • #11 21880175
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14464
    Help: 650
    Rate: 12476
    Very nice! What's the next on the list?
    Helpful post? Buy me a coffee.
  • #12 21880178
    divadiow
    Level 38  
    Posts: 4912
    Help: 430
    Rate: 873
    basic bootstrapping info in log box when selecting platform?
    TXW?
    RTL-B is bugging me, it doesn't release com port/button after certain failures, stop button often unresponsive
    XR refactor

    Added after 1 [minutes]:

    full erase for other platforms

    Added after 36 [seconds]:

    other ESPs

    Added after 14 [minutes]:

    template parsing unification
  • #13 21880878
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14464
    Help: 650
    Rate: 12476
    TXW, yes...

    RTL-B, if it has such bug, it's probably priority... it sounds like obvious mistake...

    XR refactor - why?

    Full erase - low priority but simple

    Other ESPs - good idea

    Template parsing - how and why?

    Also:
    https://github.com/openshwprojects/EasyGUIFlashTool
    Helpful post? Buy me a coffee.
  • #14 21881183
    divadiow
    Level 38  
    Posts: 4912
    Help: 430
    Rate: 873
    p.kaczmarek2 wrote:
    RTL-B, if it has such bug, it's probably priority... it sounds like obvious mistake...


    hmm. I think some stop/closeport/error handling needs standardising. Seems to vary quite a lot between platforms.

    I've playing with Codex and will present possibilities in new branch for analysis, testing etc

    Added after 1 [minutes]:

    lots of mixed line endings too :/ which make any diffs look noisy

    Added after 34 [minutes]:

    oh lord. it started off as an RTL-B tightening but... WIP: https://github.com/openshwprojects/BK7231GUIF...e/main...divadiow:BK7231GUIFlashTool:rtlbstop

    objective is to sort a shared contract for cross-platform behaviour:
    -how worker cleanup finishes
    -how cancellation is surfaced
    -how final read/write/erase states are shown

    centralise messaging. currently:

    BK uses 
    Write success!
    and even includes a newline in the state text in BK7231Flasher.cs.
    RTL8710B uses 
    Write complete!
    but with Color.Transparent, not a green success color, in RTLFlasher.cs.
    RTL87X0C ends on 
    Flash complete!
    in RTLZ2Flasher.cs.
    BL/ECR/RDA/WM/SPI mostly use 
    Writing done.

    XR/TR mostly use 
    Write complete
    or 
    Write done.

    ESP may finish on 
    Write complete
    , or 
    Write verified
    if MD5 verification runs, in ESPFlasher.cs.

    RTLZ2Flasher: 
    Erase complete!

    TR6260Flasher: 
    Erase complete!

    XR806/XR809/XR872: 
    Erase complete

    BL602Flasher: 
    Erase done

    SPIFlasher: 
    Erase done


    Added after 7 [hours] 13 [minutes]:

    current state of play on branch:

    -hardens cancellation and COM-port cleanup so stop/cleanup exceptions are less likely to leave the app stuck
    -centralises worker-thread finalisation in the GUI so buttons and state recover more reliably after success, failure, or cancel
    -fixes RTL8710B’s weaker cancel handling by making its blocking read/wait paths cancellation-aware and ensuring its operations close the port more reliably
    -improves BK72xx cancellation handling so stop-triggered serial I/O aborts are treated as cancellation rather than noisy fatal failures
    -standardises final top-banner outcomes for supported read/write/erase operations so they consistently end in clear complete/cancel/error states
    -preserves detailed per-platform information in the log box, including verification success where supported
    -aligns several other platform flashers with the same shared completion/cancellation/status patterns without changing their protocol logic
  • #18 21886078
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14464
    Help: 650
    Rate: 12476
    That's lot of changes.

    Some of the things are very nice:
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    But I am not sure how can we review and test it welll.

    maybe in future we should try step by step, adding small changes?

    What do you think, @insmod, any crucial mistakes in this PR?

    Added after 52 [seconds]:

    This is reduntant:
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?

    Added after 2 [minutes]:

    If you are trying to refactor it, maybe this:
    Easy Flasher: BK7231N/T/BK7238 etc chip ID check for Beken devices?
    could be in separate function, that receives exception, and checks is it cancelation...
    Helpful post? Buy me a coffee.
  • #19 21886096
    divadiow
    Level 38  
    Posts: 4912
    Help: 430
    Rate: 873
    yes, I understand. I was trying to keep the changes focussed and small-ish, rather than a bigger refactor, but it grew! Seems this can easily happen when an adjacent inconsistency or problem arises when going to make a focussed change. Suddenly it seems right to make the next change, then the next, and so on.

    I could address those points you raised, break into smaller PRs or ... just leave Easy Flasher alone? 🤣

    Added after 3 [minutes]:

    whatever the next steps, thanks for the quick feedback
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion focuses on enhancing Easy Flasher (EF) software to implement a more robust chip ID verification process for Beken devices using BK7231N, BK7231T, BK7238, and related chips. The proposed improvement involves relocating chip ID handling into a dedicated file (FlashersBKChipIdentity.cs) and maintaining a dictionary of supported and some unsupported BK chips. This approach aims to detect mislabelled devices, such as CB2S units incorrectly identified as BK7231N when they are actually BK7231T, by flagging mismatches before flashing operations commence. The system logs warnings if the chip ID is expected but not returned, suggesting a possible wrong chip selection, and halts the process if the returned chip ID does not match the selected chip. Additionally, the feature to skip key checks is expanded to skip both chip and key checks, improving flexibility during flashing. Reference is made to a related GitHub pull request that implements these changes and includes example logs and screenshots demonstrating the detection of chip ID mismatches.
Generated by the language model.
Today's popular

FAQ

TL;DR: Across 4+ BK chip paths, Easy Flasher now checks chip identity before flashing, and “checkbox is good enough” remains the escape hatch for edge cases. This helps users, modders, and repairers avoid cross-flashing mislabeled Beken modules such as CB2S, CB3S, WB3S, and BK7258 boards before write operations start. [#21879872]

Why it matters: A pre-flash chip ID check turns mislabeled modules from a destructive surprise into a visible warning, a hard stop, or a deliberate override.

Selected mode Detected reality Default result Override path
BK7231N BK7231T or BK7231M Warn or fail on ID mismatch Use skip chip/key check
BK7238 BK7231N Fail and stop before flashing Use skip chip/key check
BK7231M BK7231N or BK7258 Now checked like BK7231N Use skip chip/key check
BK7258 BK7258 Detection works, but behavior still needed review Proceed carefully

Key insight: The safest Easy Flasher workflow is simple: trust chip ID checks by default, then use the skip checkbox only when you intentionally need to test an unknown or mismatched BK72xx device. [#21879350]

Quick Facts

  • The chip-ID feature was proposed on 2026-04-03 and aimed at stopping writes before they begin when a selected BK chip does not match the detected device, including mislabeled CB2S, CB3S, and WB3S modules. [#21876721]
  • Easy Flasher was updated to move chip identity logic into a dedicated file, expand the old “skip key check” into “skip chip/key check,” and keep unsupported BK chips in the dictionary for safer diagnostics. [#21876721]
  • BK7258 was described as a 3-core chip, and experiments compared the older 3.0.78 SDK with Armino; the older SDK gave more progress, but both required significant extra time. [#21878452]
  • A historical flashing workflow cited in the thread supported 18 different models from one tool and started by reading flash type, size, and firmware identifiers first to avoid cross-flashing. [#21878112]
  • A later cleanup branch standardized completion states such as “Write success!”, “Write complete!”, “Flash complete!”, “Erase complete!”, and “Erase done” across multiple platforms so GUI status and COM-port recovery behave more consistently. [#21881183]

How can Easy Flasher use chip ID checks to stop you from flashing the wrong Beken chip like a mislabeled CB2S with BK7231T instead of BK7231N?

Easy Flasher can read the chip ID before any write starts and compare it with the mode you selected. If you pick BK7231N but the device identifies as BK7231T, the tool logs the mismatch and stops the current operation early. That directly targets mislabeled modules, including cases where a CB2S label hides a different BK72xx chip. The proposed implementation also moved chip identity handling into a dedicated file so the check stays consistent across supported Beken targets. [#21876721]

Why does Easy Flasher warn or fail when the selected platform chip doesn’t match the detected chip ID on BK7231N, BK7231T, BK7238, or BK7258 devices?

It warns or fails because the selected flasher logic must match the real silicon. In the thread, BK7238 mode connected to a BK7231N device was treated as a fail-and-stop case, while a chip that should return an ID but does not can trigger a warning. That design protects write, erase, and key-handling steps from running against the wrong target. It is a pre-flight compatibility check, not just a cosmetic message. [#21876721]

What is the 'skip chip/key check' option in Easy Flasher, and when should you use it for BK72xx devices?

The “skip chip/key check” is a user override that bypasses pre-flash identity and key validation, allowing advanced testing on mismatched or newly observed BK72xx variants. Use it only when you intentionally want to proceed despite a warning or a failed match.
  1. Select the closest target mode.
  2. Confirm the mismatch or failed ID read.
  3. Enable skip chip/key check only for deliberate testing.
The thread explicitly treats that checkbox as the right escape hatch for unusual cases. [#21879350]

How do you tell the difference between BK7231N, BK7231T, and BK7231M in Easy Flasher when the module label may be wrong?

Use Easy Flasher’s chip ID result, not the module label, as the primary signal. The thread shows direct tests for BK7231N with a Tuya CB3S, BK7231T with a Tuya WB3S, and BK7231M with a Uascent zero-keys BL2028N. When the selected mode and returned ID align, the operation proceeds normally. When they do not align, the tool now flags the mismatch or requires the skip checkbox. That makes BK7231N, BK7231T, and BK7231M distinguishable even when labels are misleading. [#21879350]

What happens in Easy Flasher if a chip should return a chip ID but the ID read fails?

Easy Flasher logs a warning and suggests that the wrong chip may be selected. The original proposal gives a concrete case: if BK7231N is selected but the connected device is actually BK7231T, the expected ID path can fail and the tool should warn before continuing. That is different from a confirmed mismatch, where the design is to fail and stop. The failure-to-read case is treated as diagnostic evidence, not silent success. [#21876721]

Why was BK7231M initially treated differently for key and chip ID checks, and why was that behavior changed to match BK7231N?

BK7231M was initially left more permissive so one Beken mode stayed “free and easy” for experiments and unknown variant IDs. The idea was that a looser path might help when Easy Flasher encountered a new BK chip that strict checks would reject immediately. That changed after discussion because the dedicated skip chip/key check checkbox already covered that need. BK7231M was then reinstated to use the same key-check behavior as BK7231N, identified in the thread as 7231c. [#21879350]

What is a chip ID check in the context of Beken flashing tools, and why does it matter before writing firmware?

A chip ID check is a pre-flash identity read that asks the target Beken chip to report who it is, then compares that answer with the selected platform. It matters because writing firmware with the wrong flasher path can target the wrong geometry, key flow, or protocol assumptions. The thread’s historical analogy is clear: one older phone tool supported 18 models but first read chip type, size, and firmware data to prevent cross-flashing. Easy Flasher is applying the same defensive idea to BK72xx devices. [#21878112]

What is Armino for BK7258 development, and how does it differ from the older 3.0.78 SDK?

“Armino” is a BK7258 development SDK path that provides an alternative software stack for Beken work, while the older 3.0.78 SDK is an earlier vendor toolkit with different porting effort, behavior, and maturity. In this thread, both were tried “for fun,” but they did not behave equally. The important practical difference reported here is not feature detail; it is that 3.0.78 gave more success, while Armino was also tested and remained part of the evaluation path. [#21878452]

Between the Beken 3.0.78 SDK and Armino, which is better for experimenting with BK7258 and OBK porting?

The older 3.0.78 SDK looked better for experiments in this thread. The reported result was “more success with 3.0.78,” although it still required more time and the work was paused. Armino was also tested, but the thread does not claim better progress from it. So the practical recommendation from this discussion is simple: start with 3.0.78 for BK7258 experiments, then expect a time-consuming porting process either way. [#21878452]

How should you proceed when Easy Flasher detects BK7231M while BK7231N mode is selected, especially on zero-key modules like the Uascent BL2028N?

Stop and switch to the matching mode unless you have a deliberate reason to override. The thread includes a direct test with a Uascent zero-keys BL2028N identified as BK7231M, plus a separate run where BK7231N mode was selected against that same BK7231M hardware. The safe path is:
  1. Read the detected chip ID.
  2. Re-select BK7231M mode.
  3. Use skip only for intentional testing.
That avoids treating a real BK7231M as a BK7231N just because the first mode choice was wrong. [#21879350]

Why is BK7258 described as a more complicated three-core chip, and what makes OpenBeken porting harder on it?

BK7258 is described as harder because it is a “weird” 3-core chip, not a straightforward extension of the simpler BK72xx targets already handled well. The thread says an OpenBeken port was attempted, then paused because the work was more time-consuming than expected and other issues took priority. Even after later hardware access, BK7258 behavior still needed checking because its identity and check flow were not behaving like the simpler cases. Complexity here means more engineering time and more unknowns. [#21878112]

How can Easy Flasher standardize stop, cancel, COM-port cleanup, and final read/write/erase messages across BK, RTL8710B, RTL87X0C, XR, ESP, and other platforms?

It can centralize worker-thread finalization in the GUI and make platform flashers report a shared set of end states. The branch described in the thread standardizes how cleanup finishes, how cancellation is surfaced, and how read, write, and erase results appear after success, failure, or cancel. It also preserves detailed platform-specific log messages, including verification success where supported. That reduces message drift such as “Write success!”, “Write complete!”, “Flash complete!”, “Erase done,” and other inconsistent endings across many flashers. [#21881183]

What causes Easy Flasher to leave the COM port stuck or the stop button unresponsive after RTL-B failures, and how can that be fixed?

The issue comes from inconsistent stop, close-port, and error-handling paths, especially around RTL-B blocking waits and serial cleanup. The thread identifies cases where the COM port was not released after failures and the stop button could become unresponsive. The proposed fix was concrete: make blocking read and wait paths cancellation-aware, harden cancellation, and ensure operations close the port more reliably. Centralized worker cleanup then restores buttons and state after success, failure, or cancel. [#21881183]

How do cleaner busy COM-port error messages and centralized worker cleanup improve the user experience in Easy Flasher?

They make failures readable and recovery predictable. The thread shows that a busy COM-port open attempt looked messy, then reports a cleaner UX after standardizing messages and removing the misleading “there was no result to save” notice when a port failed to open during flash read. Centralized worker cleanup also helps buttons and state recover reliably instead of leaving the app stuck after an exception or cancel. Users get one clear failure cause, then a usable GUI again. [#21883499]

Why would XR flashers benefit from being merged into one implementation or moved to an XRBaseFlasher-style base class?

They would benefit because XR support appears to share enough repeated behavior to justify a common base. The thread explicitly says the XR flashers should either be merged or have most code moved into something like XRBaseFlasher, and a first refactor branch was started. A shared base would reduce duplicate logic, align cancellation and status handling, and make future fixes easier to apply once instead of across several XR-specific implementations. That is a maintainability gain, not just a style change. [#21881921]
Generated by the language model.
ADVERTISEMENT