logo elektroda
logo elektroda
X
logo elektroda
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

Fiddling with my first Matter device - 10A 1CH switch [CB3S / BL2028N (BK7231N)]

divadiow 8874 93
ADVERTISEMENT
📢 Listen (AI):
  • #31 21137432
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    Ah, I see. Nope. I haven't actually deployed that many smart devices for real use 😂. It's more about exploring and understanding electronics and everything OpenBeken of course
  • ADVERTISEMENT
  • #32 21138630
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    a small step forward

    Screenshot of system logs showing network settings and SSID.

    more promising SSID after changing the RF partition address to match where it is in the uHome firmware. Also updated OTA to 0x143000.

    Source code fragment with memory partition configuration for Beken BK7231 device.

    Still no AP broadcasting and no mac address showing in boot log. Was hoping net info on these was at 0x1FC000 but that's not worked. flashing a Tuya net info partition to Tuya and uHome addresses used in PR builds has made no diff.

    https://github.com/divadiow/OpenBK7231N/commit/ce8def14c48f8f4eaafbeb7da80d93ef9d2040c8
    https://github.com/divadiow/OpenBK7231N/commit/aac9ed278a2cc15ef6f3652f71d8a0a92dc56c47
  • #33 21140234
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14637
    Help: 655
    Rate: 12649
    The MAC address still shows as 0?

    Maybe it would be possible to check the BK7231N SDK we use to see how MAC is created and maybe, just for testing, hardcode there a non-zero MAC to see if it helps AP to get up?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #35 21231617
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    No progress has been made, but I did get a "Tuya" Matter RGBCCT bulb that turned out to be another Uascent/RT-Threads device. UAM022-V1.0 (CB2L) module. Coeff key read-out disallowed, as it is with the others. Same bootloader/log

    Screenshot of the BK7231 Easy UART Flasher tool showing Reading success! status.

    UAM022-V1.0 module in a smart RGBCCT bulb

    Code: Text
    Log in, to see the code

    same 0x143000 OTA address where rbls can be flashed directly for flashing to OBK on reboot

    Screenshot of a hex editor showing memory data with hex values visible. Screenshot showing hexadecimal and ASCII data from device memory.
    Attachments:
    • readResult_BK7231N_QIO_2024-18-9-21-51-21.bin (2 MB) You must be logged in to download this attachment.
    • rom.bin (16 KB) You must be logged in to download this attachment.
    • efuse.bin (32 Bytes) You must be logged in to download this attachment.
    • x1_0_dump_20240918_213429_0x0_0x200000.bin (2 MB) You must be logged in to download this attachment.
  • #36 21425126
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    interesting to note that a factory firmware upgrade of the original 10A 1CH mini Matter switch module also gives the ota_erase_dl_rbl errors after successful OTA

    Matter1CH switch module with voltage and load markings.

    Code: Text
    Log in, to see the code


    uHome app pairing, device info and OTA offer

    App screen showing connected smart device information. Smart home app interface showing UA-SmartPlug device in the Living room. Device upgrade screen showing new software version. A screenshot displaying device information on a smartphone.

    Code: Text
    Log in, to see the code
  • #38 21465033
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    I have corrected previous posts regarding the coeff on the Uascent devices. The correct coeff is 4862379A 8612784B 85C5E258 75754528

    and when OBK is built with this in build.sh the UART binary flashed from 0x11000 will boot as expected.
    https://github.com/openshwprojects/OpenBK7231...mits/043d7adcaf2b4f6ace1999000f1ad1a8d3b675b2

    now we just need a standard Tuya partition layout bootloader that works so OBK doesn't need any further customisation regarding RF/OTA addresses
  • #39 21465048
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14637
    Help: 655
    Rate: 12649
    That's a great finding. What do you mean by standard bootloader? Do you mean that we need to.... recompile (?) or, should I say, encrypt the standard Tuya bootloader with the key you've given?
    Helpful post? Buy me a coffee.
  • #40 21465051
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    p.kaczmarek2 wrote:
    That's a great finding. What do you mean by standard bootloader? Do you mean that we need to.... recompile (?) or, should I say, encrypt the standard Tuya bootloader with the key you've given?

    exactly that, so OBK size and everything else is constant.

    I'm thinking conversion from Uascent would be full erase, write QIO from 0x0, write standard RF at Tuya address = working standard OBK device
  • #41 21465073
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14637
    Help: 655
    Rate: 12649
    Well, if we consider this code fragment:
    
    
    if [ "$BUILD_MODE" = "zerokeys" ]; then
       echo "Using zero keys mode - for those non-Tuya devices"
       ./${ENCRYPT} ${APP_BIN_NAME}_${APP_VERSION}.bin 00000000 00000000 00000000 00000000 10000
       #python mpytools.py bk7231n_bootloader_zero_keys.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
       python mpytools.py bk7231n_bootloader_enc.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
    else
       echo "Using usual Tuya path"
       ./${ENCRYPT} ${APP_BIN_NAME}_${APP_VERSION}.bin 510fb093 a3cbeadc 5993a17e c7adeb03 10000
       python mpytools.py bk7231n_bootloader_enc.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
    fi
    

    it seems that Tuya already had encrypted bootloader.

    However... if this one is encrypted:
    https://github.com/openshwprojects/OpenBK7231..._os/tools/generate/bk7231n_bootloader_enc.bin
    Then that would be without encryption?
    https://github.com/openshwprojects/OpenBK7231...231n_os/tools/generate/bk7231n_bootloader.bin

    Added after 1 [hours] 8 [minutes]:

    Check this out, this generates encrypted bootloader for given key:
    
    
    cp ${APP_BIN_NAME}_${APP_VERSION}.bin ${APP_BIN_NAME}_${APP_VERSION}_zeroKeys.bin
    cp bk7231n_bootloader.bin bk7231n_bootloader_test.bin
    
    
    if [ "$BUILD_MODE" = "zerokeys" ]; then
       echo "Using zero keys mode - for those non-Tuya devices"
       ./${ENCRYPT} ${APP_BIN_NAME}_${APP_VERSION}.bin 00000000 00000000 00000000 00000000 10000
       #python mpytools.py bk7231n_bootloader_zero_keys.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
       python mpytools.py bk7231n_bootloader_enc.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
    else
       echo "Using usual Tuya path"
       ./${ENCRYPT} ${APP_BIN_NAME}_${APP_VERSION}.bin 510fb093 a3cbeadc 5993a17e c7adeb03 10000
       ./${ENCRYPT} bk7231n_bootloader_test.bin 510fb093 a3cbeadc 5993a17e c7adeb03 0
       python mpytools.py bk7231n_bootloader_enc.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
    fi
    
    ./${BEKEN_PACK} config.json
    

    Screenshot of a Windows folder with a list of files related to the OpenBK7231N project.
    Wanna get it for 4862379A 8612784B 85C5E258 75754528 ?

    Added after 1 [minutes]:

    Let me try:
    
    
    cp ${APP_BIN_NAME}_${APP_VERSION}.bin ${APP_BIN_NAME}_${APP_VERSION}_zeroKeys.bin
    cp bk7231n_bootloader.bin bk7231n_bootloader_test.bin
    cp bk7231n_bootloader.bin bk7231n_bootloader_dvd.bin
    
    
    if [ "$BUILD_MODE" = "zerokeys" ]; then
    	echo "Using zero keys mode - for those non-Tuya devices"
    	./${ENCRYPT} ${APP_BIN_NAME}_${APP_VERSION}.bin 00000000 00000000 00000000 00000000 10000
    	#python mpytools.py bk7231n_bootloader_zero_keys.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
    	python mpytools.py bk7231n_bootloader_enc.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
    else
    	echo "Using usual Tuya path"
    	./${ENCRYPT} ${APP_BIN_NAME}_${APP_VERSION}.bin 510fb093 a3cbeadc 5993a17e c7adeb03 10000
    	./${ENCRYPT} bk7231n_bootloader_test.bin 510fb093 a3cbeadc 5993a17e c7adeb03 0
    	./${ENCRYPT} bk7231n_bootloader_dvd.bin 4862379A 8612784B 85C5E258 75754528 0
    	python mpytools.py bk7231n_bootloader_enc.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
    fi
    
    Helpful post? Buy me a coffee.
  • #42 21465151
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    hmm.
    trying with
    Code: Text
    Log in, to see the code


    generated file does not boot.

    Added after 18 [minutes]:

    I have been wondering about the crc and the BL file size differences. I remember seeing an example batch file in BEKEN_ENCRYPT_V5.0.0.7_20231008 that had -crc switch

    also that it always seems like BL has CRC

    Hexadecimal code snippet with textual annotations.

    I've given that a go, as below, and look! BK7231N_1.0.1 for the first time ever booting on Uascent (that I've seen)

    Screenshot of a folder with BIN files and a Notepad++ entry.

    Added after 18 [minutes]:

    and now. full erase. flash new BL with crc to 0x0, UART PR with new key to 0x11000 and restore RF partition in EF:
    OpenBK7231N control panel with device information.
    OBK with a mac and matching hostname

    curiously OTA doesn't work at the moment, but maybe these manual steps is missing some crucial bits. otafix for example.

    Added after 3 [minutes]:

    https://dl.bekencorp.com/p/tools/flash/BEKEN_...oc1hO4HySgYsrSScvJJiF0IwFs0rSMLOAb5iv43WF8=:0
    Attachments:
    • BEKEN_ENCRYPT_V5.0.0.7_20231008.zip (13.52 MB) You must be logged in to download this attachment.
  • #43 21465364
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14637
    Help: 655
    Rate: 12649
    I'd suggest doing different experiment, just to be sure.

    In my previous post, I've found that we have unecrypted bootloader and we can encrypt it ourselves.
    This line creates encrypted bootloader with given key:
    
       ./${ENCRYPT} bk7231n_bootloader_test.bin 510fb093 a3cbeadc 5993a17e c7adeb03 0
    

    Now, we can check if our DIY encrypted bootloader (bk7231n_bootloader_test_enc.bin) is the same as bk7231n_bootloader_enc.bin , which was supplied by tuya. This will tell us if we do exactly 1:1 as them.
    At first glance, they are the same.
    However...
    I've used online binary compare.
    Binary file comparison using ExamDiff Pro with differences highlighted in colors.
    This is still not perfect.
    Changes as shown by AI:
    
    00000100+8
    -> 42 4B 37 32 33 31 00 00  BK7231..  
    -> 63 4C 80 4E 12 3E B7 7C  cL.N.>.|
    0000E95C+212
    -> 30 31 50 45 62 6F 6F 74 6C 6F 61 64 65 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 62 65 6B 65 6E 5F 6F 6E 63 68 69 70 5F 63 72 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 30 31 50 45 61 70 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 62 65 6B 65 6E 5F 6F 6E 63 68 69 70 5F 63 72 63 00 00 00 00 00 00 00 00 00 00 01 00 00 87 10 00 00 00 00 00 30 31 50 45 64 6F 77 6E 6C 6F 61 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 62 65 6B 65 6E 5F 6F 6E 63 68 69 70 00 00 00 00 00 00 00 00 00 00 00 00 00 A0 12 00 00 60 0A 00 00 00 00 00 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  01PEbootloader..............beken_onchip_crc....................01PEapp.....................beken_onchip_crc....................01PEdownload................beken_onchip.................`.......................... 
    -> B1 2E 3F 98 E3 08 00 A9 ED 00 0E B9 E4 05 6F DD 81 7F 6F DD 81 47 6F DD 81 4F 6F DD E3 32 04 B8 EF 00 00 B3 E2 CF 07 AD DE CC 1C BE 81 B7 6E DD 81 BF 6E DD 81 87 6E DD 81 8F 6F DD 81 97 6E DD B1 AE 3E 98 E0 97 1E DD 81 EF 6E DD 81 F7 6E DD 81 FF 6E DD 81 C7 6E DD 81 CF 6E DD E3 B2 05 B8 EF 80 01 B3 E2 4F 07 AD DE 4C 1C BE 81 37 6E DD 81 3F 6E DD 81 07 6F DD 81 88 7E DD 81 17 6E DD B1 2E 3E 98 E5 08 19 B3 ED 00 0F B9 81 77 6E DD 81 7F 6E DD 81 47 6E DD 81 4F 6E DD E3 32 05 B8 EF 00 01 B3 E2 CF 00 AD 81 AF 69 DD 81 B7 69 DD 81 BF 69 DD 81 27 7B DD 81 EF 63 DD 81 97 69 DD 7E 60 96 22 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ..?...........o...o..Go..Oo..2................n...n...n...o...n...>.......n...n...n...n...n..........O...L...7n..?n...o...~...n...>..........wn...n..Gn..On..2............i...i...i..'{...c...i.~`."................
    


    Questions to consider:
    - why our own bk7231n_bootloader_test_enc.bin is still different from Tuya bk7231n_bootloader_enc.bin ?
    - does our bk7231n_bootloader_test_enc.bin runs on the same device where bk7231n_bootloader_enc.bin would run?
    - how to get exactly the same result as Tuya?
    Maybe it's indeed this CRC switch.

    @divadiow if you use your method to encrypt Tuya bootloader with the Tuya key, do you get the same 1:1 file as the bootloader Tuya has given us already encrypted?

    Added after 3 [minutes]:

    Is otafix anywhere used in the code?
    https://github.com/search?q=repo%3Aopenshwprojects%2FOpenBK7231N%20otafix&type=code
    Helpful post? Buy me a coffee.
  • #44 21465371
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    p.kaczmarek2 wrote:
    Is otafix anywhere used in the code?

    oh. must be what I saw and thought it was being invoked. just looks like a variable for it, but not used?
  • ADVERTISEMENT
  • #45 21465374
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14637
    Help: 655
    Rate: 12649
    Maybe Github search has failed me
    Helpful post? Buy me a coffee.
  • #46 21465375
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    p.kaczmarek2 wrote:
    @divadiow if you use your method to encrypt Tuya bootloader with the Tuya key, do you get the same 1:1 file as the bootloader Tuya has given us already encrypted?

    will check and report back

    Added after 1 [minutes]:

    otafix is used on T but not N? What does it even fix?

    build.sh script code for the OpenBK7231T and OpenBK7231N projects.
  • #47 21465505
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14637
    Help: 655
    Rate: 12649
    I've tried to add "-crc" switch to encrypt from OpenBK7231N repo:
    
    	./${ENCRYPT} bk7231n_bootloader_test.bin 510fb093 a3cbeadc 5993a17e c7adeb03 0 -crc
    

    but no matter what I do, argument is not recognized?

    It seems like we need to get that new encrypt you've found into our repo, and then we could integrate an OBK build (without OTA working yet) for Uascent ?
    Helpful post? Buy me a coffee.
  • #48 21465517
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    >>21465505

    that sounds like a plan. I also don't understand why the existing N BL works now on Tuya-key chips - surely that needs crc? also, does BK7231M QIO definitely boot if flashed from 0x0 even. I'll check that too (on appropriate 0000 efuse module).

    Added after 6 [hours] 50 [minutes]:

    OK. here's some stuff for reference as I work through trying things

    Here are the two bins created from
    Code: Text
    Log in, to see the code
    against this https://github.com/openshwprojects/OpenBK7231...231n_os/tools/generate/bk7231n_bootloader.bin
    bk7231n_bootloader_crc.bin
    bk7231n_bootloader_enc.bin


    Code: Text
    Log in, to see the code


    not too sure what keyword skip is for and why.

    the readme:

    Code: Text
    Log in, to see the code
    Attachments:
    • bk7231n_bootloader.zip (114.9 KB) You must be logged in to download this attachment.
  • #49 21466094
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    -un-skip argument used

    Code: Text
    Log in, to see the code
    Attachments:
    • bk7231n_bootloader-unskipswitch.zip (114.9 KB) You must be logged in to download this attachment.
  • #50 21466096
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    -nocrc -un-skip used - produces a single _enc file
    Code: Text
    Log in, to see the code
    Attachments:
    • bk7231n_bootloader_enc.zip (55.3 KB) You must be logged in to download this attachment.
  • #51 21466119
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    OK, so Uascent module doesn't boot with non-crc BL and -un-skip argument also means no boot. So this = working BL on Uascent:
    Code: Text
    Log in, to see the code


    Added after 4 [minutes]:

    it's like it's encrypting too much. 01pe partition should be in plain-text surely

    Comparison of two binary files in a hexadecimal editor.

    Added after 28 [minutes]:

    Interesting, I've changed ALL keys in the build.sh into the Uascent one, so N and M QIO should both boot, neither do.
    https://github.com/openshwprojects/OpenBK7231...mits/d2c2eda407d011406ef3158e0c91244e79383871

    Added after 1 [minutes]:

    both QIOs contain 01PE as one would expect

    Added after 12 [minutes]:

    the M QIO general release does not boot on 4mb SparkleIOT BK-N
  • #52 21466321
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14637
    Help: 655
    Rate: 12649
    divadiow wrote:

    Interesting, I've changed ALL keys in the build.sh into the Uascent one, so N and M QIO should both boot, neither do.
    https://github.com/openshwprojects/OpenBK7231...mits/d2c2eda407d011406ef3158e0c91244e79383871

    It won't boot, I think we established earlier that we need to use the newer version of encryption tool along with CRC Switch in order to get the correct bootloader like you did.

    So we need to first copy the new tool you've found to our OpenBK7231N SDK, then integrate it into make script, and then it should work....
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #54 21466425
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14637
    Help: 655
    Rate: 12649
    Yes... and then use it in our script.

    Probably here:
    
    
    
    echo "Will do extra step - for zero keys/dogness"
    cp ${APP_BIN_NAME}_${APP_VERSION}_zeroKeys.bin ${APP_BIN_NAME}_${APP_VERSION}.bin
    echo "Will do zero keys encrypt"
    ./${ENCRYPT} ${APP_BIN_NAME}_${APP_VERSION}.bin 00000000 00000000 00000000 00000000 10000
    echo "Will do zero mpytools.py"
    python mpytools.py bk7231n_bootloader_enc.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
    echo "Will do zero BEKEN_PACK"
    ./${BEKEN_PACK} config.json
    echo "Will do zero qio"
    cp all_1.00.bin ${APP_BIN_NAME}_QIO_${APP_VERSION}.bin
    cp ${APP_BIN_NAME}_QIO_${APP_VERSION}.bin ../../${APP_PATH}/$APP_BIN_NAME/output/$APP_VERSION/OpenBK7231M_QIO_${APP_VERSION}.bin
    cp ${APP_BIN_NAME}_UA_${APP_VERSION}.bin ../../${APP_PATH}/$APP_BIN_NAME/output/$APP_VERSION/OpenBK7231M_UA_${APP_VERSION}.bin
    


    Add the same code but for uascent..
    I can try maybe, but you can try as well, I'll see how far we can get :D
    Helpful post? Buy me a coffee.
  • #56 21466442
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14637
    Help: 655
    Rate: 12649
    I'm trying this at the moment:
    Source code snippet in GitHub editor with highlighted changes.

    Added after 6 [minutes]:

    Not tested:
    https://github.com/openshwprojects/OpenBK7231...mmit/960cc10ddcfca021de7372469b5cb4a09b1d593b

    Added after 32 [minutes]:

    Does it boot?
    Attachments:
    • OpenBK7231N_UASCENT_QIO_1.0.0.zip (883.81 KB) You must be logged in to download this attachment.
    Helpful post? Buy me a coffee.
  • #57 21466505
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14637
    Help: 655
    Rate: 12649
    Current approach:
    
    # 
    # 	UASCENT steps (4862379A 8612784B 85C5E258 75754528)
    # 
    # Copy blank bootloader just to have it  with "uascent" in name
    # cp [sourceFile] [destinationFile]
    cp bk7231n_bootloader.bin bk7231n_bootloader_uascent.bin
    # Call encrypt like Divadiow did
    # ENCRYPT_NEW is cmake_encrypt_crc.exe
    # this shall generate bk7231n_bootloader_uascent_enc.bin for bk7231n_bootloader_uascent.bin
    ./${ENCRYPT_NEW} -enc bk7231n_bootloader_uascent.bin 4862379A 8612784B 85C5E258 75754528 -crc
    # Copy blank-start App with zero keys bin
    # cp [sourceFile] [destinationFile]
    cp ${APP_BIN_NAME}_${APP_VERSION}_zeroKeys.bin ${APP_BIN_NAME}_${APP_VERSION}.bin
    # Apply keys to the App
    echo "Will do UASCENT encrypt"
    # This will generate ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
    ./${ENCRYPT} ${APP_BIN_NAME}_${APP_VERSION}.bin 4862379A 8612784B 85C5E258 75754528 10000
    # Use mpytools.py to generate config.json for encrypted bootloader and encrypted app	
    echo "Will do UASCENT mpytools.py to generate config.json"
    # python mpytools.py [BootloaderFile] [AppFile]
    python mpytools.py bk7231n_bootloader_uascent_enc.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
    # Use Beken Pack on created config.json to combine bootloader and app together into all_1.00.bin
    echo "Will do UASCENT BEKEN_PACK"
    ./${BEKEN_PACK} config.json
    echo "Will do UASCENT qio"
    cp all_1.00.bin ${APP_BIN_NAME}_QIO_${APP_VERSION}.bin
    cp ${APP_BIN_NAME}_QIO_${APP_VERSION}.bin ../../${APP_PATH}/$APP_BIN_NAME/output/$APP_VERSION/OpenBK7231N_UASCENT_QIO_${APP_VERSION}.bin
    cp ${APP_BIN_NAME}_UA_${APP_VERSION}.bin ../../${APP_PATH}/$APP_BIN_NAME/output/$APP_VERSION/OpenBK7231N_UASCENT_UA_${APP_VERSION}.bin
    	
    Helpful post? Buy me a coffee.
  • #58 21466523
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    awesome. yes it does boot!

    here is second boot with RF written to standard Tuya in place

    Code: Text
    Log in, to see the code


    Added after 2 [minutes]:

    sadly no OTA to n rbl. OTA log

    Code: Text
    Log in, to see the code
  • #59 21466529
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14637
    Help: 655
    Rate: 12649
    So you're saying that both bootloader and application are running? Or just bootloader is correct?
    Helpful post? Buy me a coffee.
  • #60 21466530
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    p.kaczmarek2 wrote:
    So you're saying that both bootloader and application are running? Or just bootloader is correct?


    both running

    Added after 4 [minutes]:

    curious about the 01PE stuff missing though.

    a couple of comparisons
    Comparison of two binary files in hexadecimal format.
    Developer view with two Hex Editor windows displaying raw binary data.
📢 Listen (AI):

Topic summary

✨ The discussion centers on reverse engineering and firmware modification of a 10A 1CH Matter smart switch featuring a CB3S module with a BL2028N chip, initially thought to be BK7231N but later identified as BK7231M. Attempts to flash OpenBeken (OBK) firmware failed to produce a working access point or UART output, likely due to encryption key differences and firmware partition layout issues. The device uses uHome (Uascent) firmware rather than Tuya, with a unique coefficient key (4862379A 8612784B 85C5E258 75754528) that must be applied during encryption for successful booting. A newer encryption tool supporting CRC is required to generate a bootloader compatible with the device, as older tools produce non-booting images. Flashing the bootloader with correct keys and CRC enabled allows OBK to boot, but OTA functionality remains non-functional, possibly due to encrypted partition sections (e.g., 01PE) that differ from standard Tuya layouts. The community is working on integrating the new encryption method into OpenBK7231N build scripts to support these devices. Additional observations include the presence of ESP32-C3 based Matter devices with secure boot preventing flashing, and exploration of alternative modules (WB2S/CB2S, ESP32-C2) as replacements. Firmware dumps and boot logs have been collected and shared for further analysis. The challenges highlight the complexity of adapting open-source firmware to newer Matter devices with proprietary encryption and partition schemes.
Generated by the language model.

FAQ

TL;DR: For makers converting first-generation Uascent Matter switches, the reliable path is a 2MB dump-based workflow using custom encryption handling; as one expert put it, "both running" once the bootloader and app were rebuilt with the Uascent coeff key. This FAQ explains why stock OBK builds fail, how to recover AP/MAC, and which partitions matter on CB3S/BL2028N hardware. [#21466530]

Why it matters: These devices look like ordinary BK7231N hardware, but their non-Tuya bootloader, efuse keying, and partition layout break standard OpenBeken flashing assumptions.

Option Boots on Uascent BL2028N OTA status Typical use
Classic Tuya BK7231N QIO No N/A Standard Tuya-key BK7231N devices
Zero-keys / BK7231M-style build No on Uascent N/A Devices using zero-key or M-specific paths
ENCRYPT_NEW_DOESBOOT_NOOTA UASCENT QIO Yes No Early proof-of-concept boot on Uascent Matter hardware
Uascent-specific rebuilt bootloader + encrypted app Yes Yes in later testing Proper conversion path for Uascent devices

Key insight: The main blocker is not the BL2028N radio itself. The blocker is the Uascent efuse coeff key plus a matching bootloader and partition scheme; once those match, OpenBeken can boot and later OTA can work too. [#21753785]

Quick Facts

  • The original 10A 1CH Matter mini switch used a CB3S module, but shield removal showed a BL2028N chip, not a plain BK7231N marking match. [#20940846]
  • On these Uascent RT-Thread Matter devices, the observed OTA partition for manual RBL placement was 0x143000 during stock-bootloader experiments. [#21106354]
  • A standard OBK OTA session on converted hardware wrote from about 0x12A000 to 0x1A3400, then rebooted into the new app when the boot path was correct. [#21466523]
  • The recovered Uascent coeff key was 4862379A 8612784B 85C5E258 75754528; reading efuse often returned all zeros even when that key was actually active. [#21465033]
  • A different Matter relay examined later used an ESP32-C3, 4MB flash map, secure boot verification, and 0 plaintext flashes left, blocking normal Tasmota-style reflashing. [#20965795]

How do I flash OpenBeken onto a Uascent uHome Matter switch with a CB3S/BL2028N module and custom efuse encryption keys?

Use a dump-first, key-aware workflow. 1. Read the full backup and use Easy Flasher’s BK7231N Decryption tab to find keys and add default BK7231N partitions. 2. Encrypt a matching bootloader and flash it at 0x0. 3. Encrypt the OpenBeken app partition and burn it at 0x11000, then restore RF from backup if possible. A later working method packaged a full 2MB image so first boot unpacked an OTA RBL and entered fresh OBK. [#21850205]

Why does a BL2028N-based UAM028 Matter device fail to create an AP after flashing standard OpenBK7231N or BK7231M builds?

It fails because the device does not use the standard Tuya encryption and partition assumptions. Standard builds could boot partially, but logs showed mac=00:00:00:00:00:00 and no AP broadcast even after RF restore attempts. The thread tied this to Uascent-specific coeff keys, non-Tuya bootloader behavior, and different RF or OTA layout expectations. Until the bootloader and app were rebuilt for the correct key path, the device did not expose the expected OpenBK7231N access point. [#21115403]

What is the coeff key on BK7231N/BL2028N devices, and why does it matter when converting Uascent Matter hardware to OpenBeken?

The coeff key is the efuse-backed encryption key that the bootloader uses to validate or encrypt firmware on this hardware. "Coeff key" is an efuse-stored encryption parameter that binds firmware images to a device family, preventing ordinary Tuya-key or zero-key binaries from booting when the chip expects a different key set. For the Uascent devices in this thread, the working key was 4862379A 8612784B 85C5E258 75754528. Without that key, standard OBK builds booted poorly or not at all. [#21465033]

What does the 0x143000 OTA partition mean on these Uascent RT-Thread Matter devices, and how is it used during flashing?

It is the stock bootloader’s download area for OTA-style application updates. In early tests, flashing an unencrypted BK-N RBL directly to 0x143000 triggered the Uascent BK7231n_1.0.13 bootloader to inspect that partition on reboot. When the bootloader accepted the payload, logs showed the OTA start marker and then jumped into the app area at 0x10000. That is why direct RBL placement worked even before a fully standard OBK conversion existed. [#21106354]

Which steps are needed in Easy Flasher to restore stock firmware from a backup on a BK7231N or BL2028N module?

Use Easy Flasher’s restore mode and make the backup file recognizable. 1. Enable "allow backup restore". 2. Ensure the filename starts with readResult_BK7231N_QIO.. so it appears in the restore list. 3. Select the backup and flash it back to the device. That method successfully restored factory firmware after failed OBK tests on BL2028N hardware. [#20968329]

How can I tell whether a CB3S module is really BK7231N, BK7231M, or a BL2028N variant when the markings and behavior do not match?

Do not trust the module label alone; confirm by chip inspection and boot behavior. The CB3S module first looked like a normal BK7231N, but removing the shield revealed BL2028N on the die. Even then, boot signatures such as 0x00401C1C suggested an M-flavor or different keying path, which explained why ordinary N images failed. The safest identification method is: inspect the silicon, capture boot logs, and compare behavior after flashing known N or M test images. [#20940912]

What's the difference between classic Tuya BK7231N firmware, zero-keys BK7231M builds, and Uascent-specific QIO builds in OpenBeken?

They target three different encryption assumptions. Classic Tuya BK7231N builds use the normal Tuya key path and standard partition layout. Zero-keys or BK7231M-oriented builds target devices whose efuse path behaves like the all-zero or M-family workflow. Uascent-specific QIO builds use the recovered Uascent coeff key 4862379A 8612784B 85C5E258 75754528 and a matching bootloader build path. That is why a Uascent device could reject release binaries yet boot a Uascent-specific QIO image. [#21725546]

Why does the newer Beken cmake_encrypt_crc.exe tool with CRC produce a bootable Uascent bootloader when the older encrypt.exe does not?

Because the Uascent bootloader path needed the newer encryption flow plus CRC packaging. A direct test showed that encrypting bk7231n_bootloader.bin with cmake_encrypt_crc.exe -enc ... -crc finally booted BK7231N_1.0.1 on Uascent hardware, while the older no-CRC result did not. Later testing also showed that using -un-skip broke booting on Uascent. In short, the newer tool produced a bootloader format that the Uascent device would actually execute. [#21466119]

How do I recover Wi-Fi, MAC address, and AP broadcasting on an OpenBeken-flashed Uascent device when RF restore does not help?

Fix the bootloader and key path first, then revisit RF. In the failing state, OBK booted with SSID OpenBK7231N_8C000000 but logged mac=00:00:00:00:00:00 and still did not broadcast. After a corrected Uascent bootloader and app were used, the low-level log showed a real MAC like 38:1f:8d:d8:14:d7, and the AP path initialized normally. RF restore alone did not solve the issue when the core bootloader and partition assumptions were still wrong. [#21466523]

What is an RBL file in the BK7231/OpenBeken ecosystem, and how is it different from flashing a full 2MB QIO dump?

An RBL is the OTA-style application package, not a whole-flash image. "RBL" is an RT-Thread OTA firmware container that carries an app payload for the bootloader’s download partition, rather than a complete flash layout with bootloader, RF, and data regions. In this thread, users flashed RBL files to 0x143000 or 0x12A000 for OTA processing, while a 2MB QIO dump replaced the complete flash from 0x0. Use RBL for bootloader-managed updates and QIO for full-device recovery or conversion. [#21727545]

When OTA starts but the device reboots or bricks afterward, what should I check in the bootloader, partition table, and 01PE data?

Check whether the bootloader can still parse the partition metadata after encryption. The thread linked failed OTA to bootloaders where the 01PE partition area became scrambled by the newer encryption flow. One working theory was that the app could boot, but OTA failed because the download or app partition header became unreadable after repacking. Also verify that the bootloader’s partition table points to the expected download area, such as 0x12A000 or 0x143000, for that specific build path. [#21725675]

How does BKFIL compare with Easy Flasher and BK Writer for dumping, restoring, and custom-writing BK7231N/BL2028N firmware?

BKFIL was the most useful for staged custom writes, Easy Flasher was best for guided restore and decryption, and BK Writer was one tool among several in the workflow. The thread used BKFIL to queue multiple files, wipe from 0x0, and place bootloader plus OTA pieces exactly. Easy Flasher handled backup restore, RF restore attempts, and later key discovery in the decryption tab. BK Writer 1.7.5 appeared in the toolchain, but the successful Uascent conversion relied more on BKFIL and Easy Flasher. [#21115403]

What can I do with an ESP32-C3 Matter relay switch that has secure boot and flash encryption enabled, when Tasmota or custom firmware won't flash?

Treat it as a hardware-mod case, not a normal serial-flash target. The boot log showed secure boot v2, flash encryption enabled, 0 plaintext flashes left, and a 4MB layout on the ESP32-C3 module, so custom firmware flashing was effectively blocked. In the thread, the practical options were to leave it stock, transplant a different module, or replace the radio board with something pin-compatible like a WB2S, CB2S, or another small module. [#20965795]

Where should I submit GPIO mappings or a template for a new Matter switch so it appears in the OpenBeken device directory?

Submit a pull request that edits the OpenBeken webapp device template list. The thread’s direct guidance was to add the new switch mapping to devices.json in the OpenBeken webapp repository. That is the file used for the device directory entry, so a clean GPIO map and tested template belong there rather than only in a forum attachment. [#21850205]

Why does the ENCRYPT_NEW_DOESBOOT_NOOTA UASCENT QIO image boot on some BL2028 Matter devices while current OpenBeken release binaries and UA files do not?

Because that image was built with the Uascent-specific encryption path that matched the device’s efuse coeff, while normal release binaries used the wrong assumptions. A user with a Matter 4CH BL2028 device reported that release 1.18.264 binaries, UA files, BK7231N T2/T34, T4, and BK7231M options all failed to bring up AP or Wi-Fi. The only image that booted was ENCRYPT_NEW_DOESBOOT_NOOTA_OpenBK7231N_UASCENT_QIO..., which fits the thread’s earlier finding that Uascent hardware needed a custom bootloader and encryption flow. [#21849983]
Generated by the language model.
ADVERTISEMENT