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

<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:

-if chip returns ID not matched to selected chip, log fail and stop. eg, BK7238 selected but BK7231N device:


-expand use of 'skip key check' to 'skip chip/key check'

eg, BK7238 selected, BK7231N device, skip checked:


-BK7231M behaviour remains as no key check enabled by default but does log chip ID:


I do not have BK7258/BK7236.

---

03/04/2026 - I do now have BK7258 - will check and post again

It looks like you've added override check for BK7231M?

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

Yes I think we can add it if it works reliably and has no drawbacks.

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.

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?

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.

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

BK7238 mode with BK7238 connected

BK7231M mode with BK7231M (Uascent zero-keys BL2028N) connected

BK7231N mode with BK7231M (Uascent zero-keys BL2028N) connected

BK7231N mode with BK7231M (Uascent zero-keys BL2028N) connected + skip key/chip ID check selected

BK7231N mode with BK7231N (Tuya CB3S) connected

BK7231M mode with BK7231N (Tuya CB3S) connected + skip key/chip ID check selected

BK7231T mode with BK7231T (Tuya WB3S) connected

BK7252 mode with BK7231T (Tuya WB3S) connected

BK7258 mode with BK7258 connected

BK7231N mode with BK7258 connected

BK7231M mode with BK7258 connected

BK7231M mode with BK7258 connected + skip key/chip ID check selected

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?

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

Very nice! What's the next on the list?

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

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

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

p.kaczmarek2 wrote:

XR refactor - why?

insmod wrote:

XRs really need to be either merged together into one, or majority of the code to be moved to some base class, like XRBaseFlasher.

I kinda started: https://github.com/divadiow/BK7231GUIFlashTool/tree/xr-base-refactor

divadiow wrote:

current state of play on branch:

also, busy COM port open attempt looks messy



standardised messages, cleaner UX and removed 'there was no result to save' message if com port failed to open on flash read



https://github.com/openshwprojects/BK7231GUIF...mmit/c2e7b13244ec1beb8dc3e3f77f96ca1721ede17d