logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda
3D printer for home or business?
3D printer for home or business? Here are the perfect 3D printers to start with »
ADVERTISEMENT

Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware

divadiow 1842 26
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • Helpful post
    #1 21586747
    divadiow
    Level 38  
    There are a few posts around that reference the C-Chip CC8000/BK7231U chip and that it can be found on the Hi-Link HLK-B30 development board, but experiments with it appear mixed in with several other threads, so here's a thread dedicated to the HLK-B30 and now with OpenBK7231U.

    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware
    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware

    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware

    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware

    PinPin NameTypeDescriptions
    1CENIChip enabled, highly effective
    2P26_PWM5I/OP26,PWM5
    3P24_PWM4I/OP24,PWM4
    4P23_TDO_F_S0I/OP23,ADC3
    5P22_TDI_F_SII/OES0, enter at command mode / restore factorysettings, please pull up if not used, same as P28
    6P21_TMS_F_CSI/OP21
    7P20_TCK_F_SCI/OP20
    8VBATP3.3V power supply
    9P28I/OEnter at command mode / restore factory settings, please pull up if not in use, same as P22
    10P16I/OP16
    11P17I/OP17
    12P14I/OP14
    13P15I/OP15
    14P6_PWM0I/OP6,PWM0
    15GNDPGND
    16P7_PWM1I/OP7,PWM1
    17P8_PWM2I/OWiFi indicator light
    18P9_PWM3I/OP9,PWM3
    19P1_URAT2_RXDI/OP1,UART2
    20P0_UART2_TXDI/OP0,UART2
    21P10_UART1_RXDI/OP10,UART1, For upgrading, command settingand transparent transmission
    22P11_UART1_TXDI/OP11,UART1, For upgrading, command setting and transparent transmission


    Pin mapping for SPI flashing with CH341A/Python method - needed if writing bootloader from 0x0. BK7231U is like BK7231T - no rom. Note that on v2.1 of the board D16 is incorrectly labelled as "ESO". In v3.0 (pictured above) D16 is labelled correctly.

    HLK-B30CH341A
    RSTD2
    D17SCK
    ESO/D16 (between D17 and D15)CS0
    ESO (between GND and D1)MOSI
    D15MISO
    GNDGND


    2mb EN25QH16 flash detected in NeoProgrammer when in SPI mode
    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware


    OpenBK7231U_QIO_1680_merge_55ebe0a12aba.bin from https://github.com/openshwprojects/OpenBK7231T_App/pull/1680 flashed in its entirety from 0

    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware

    Code: Text
    Log in, to see the code


    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware

    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware
    Attachments:
    • HLK-B30-©¦½¦µ¦¥-Á+¸-Ú_V1.04.pdf (2.17 MB) You must be logged in to download this attachment.
    • hlk-b30.pdf (1.72 MB) You must be logged in to download this attachment.
  • ADVERTISEMENT
  • #2 21586752
    divadiow
    Level 38  
    OTA test success. this was with quick GUI page
    Code: Text
    Log in, to see the code

    web app OTA filtering for .img not .rbl currently

    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware

    Added after 7 [hours] 42 [minutes]:

    akosschneemaier wrote:
    hey @divadiow , Yes I was able to backup the fimrware. I already uploaded it to github: https://github.com/libretiny-eu/ltchiptool/issues/28#issuecomment-2054045065

    I am still wating for my HLK-B30 to arrive so I can try flashing it.


    @akosschneemaier this fw should work on your AiDot Leedarson module bulb if you still have it
  • Helpful post
    #3 21586895
    insmod
    Level 31  
    To make sure that MAC and calibration data is correct TLV must be moved from 0x1FE000 to 0x1E0000 on BK7231U.
  • #5 21588692
    jmkrzyszt
    Level 9  
    Hi, I can see BK7231U images officially included in 1.18.125. Is it safe to flash the BK7231U image with uartprogram to a CC8000 device?
  • ADVERTISEMENT
  • #6 21588807
    divadiow
    Level 38  
    >>21588692

    what is your device, module etc?
  • #7 21589157
    jmkrzyszt
    Level 9  
    >>21588807
    That's a Winees WS010078261 RGBW bulb, with this module: >>21025914 (the one made by Leedarson).
  • #8 21589202
    divadiow
    Level 38  
    could give it a go? Maybe start by taking a full backup from 0x0 and I test your bootloader with the BK7231U release, make sure it boots and see if OTA works?

    insmod wrote:
    To make sure that MAC and calibration data is correct TLV must be moved from 0x1FE000 to 0x1E0000 on BK7231U.

    also, not sure if this would be an issue for a full freeing from cloud for your device.

    Added after 1 [minutes]:

    that assumes you'll only be able to flash over UART though so cannot replace bootloader. Do you have CH341A?
  • #9 21589360
    jmkrzyszt
    Level 9  
    >>21589202 I'm attaching backups of factory firmware taken already before, one with uartprogram (.img), another one with bk7231tool (.bin). Does any of them contain the bootloader you'd like to examine?

    I don't have a CH341A, I've been flashing with an FTDI based USB-serial adapter.
    Attachments:
    • WS010078261.zip (1.54 MB) You must be logged in to download this attachment.
  • #10 21589558
    divadiow
    Level 38  
    ah yes, I remember now. The other Leedarson dump we have is just as chatty on log out.

    Well, your 2mb backup boots just fine.

    Code: Text
    Log in, to see the code


    with OpenBK7231U_UA_1.18.125.bin renamed to OpenBK7231T_UA_1.18.125.bin and flashed with EF in T mode
    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware

    then OpenBK7231U boots. BL still silent. It is BK7231U_1.0.6, however.

    Code: Text
    Log in, to see the code


    Device has the same generic mac as my QIO flashed example on HLK-B30 - C8:47:8C:42:88:48 - not the mac your factory fw is seen with - 1c:d6:bd:d4:57:83

    Looks like TLV is at 0x10000 in your fw - your original mac can be seen in there:
    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware

    regarding TLV location, the same is true of the other AiDot Leedarson dump:
    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware

    So I guess if these types prove popular they may justify a release build to cater for the odd TLV location, with ref to:
    insmod wrote:
    To make sure that MAC and calibration data is correct TLV must be moved from 0x1FE000 to 0x1E0000 on BK7231U.


    factory OTA is at 132000, as it is with OpenBK7231U.
    here shows OBK OTA in progress with your bootloader

    Code: Text
    Log in, to see the code


    silent as the BL OTA process may be, it is still successful. I flashed down to PR build 1680_merge_55ebe0a12aba from 1.18.125 and it came back up as that. (I did get malloc failed with both OTA gui/app methods quite a bit).

    So, I guess it's TLV that's the most obvious issue

    Added after 12 [minutes]:

    manually setting mac in OBK does not seem to be supported at present. Comes back up as original
    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware
  • #11 21589577
    insmod
    Level 31  
    Is TLV header where it is now gets overwritten?
    We can't simply change where it is located, since OBK config and flash vars are dependent on its location.

    And perhaps bootloader log is on UART0?
  • #12 21589584
    divadiow
    Level 38  
    insmod wrote:
    We can't simply change where it is located, since OBK config and flash vars are dependent on its location.

    ah OK OK

    Here is dump of HLK-B30 with original Leedarson fw + OBK + those two OTAs mentioned above and the mac address change attempt

    original TLV remains
    Hi-Link HLK-B30 Development Board with C-Chip CC8000 and OpenBK7231U Firmware
    Attachments:
    • Winees_test_OBK_readResult_BK7231U_QIO_2025-25-6-21-32-22.bin (2 MB) You must be logged in to download this attachment.
  • ADVERTISEMENT
  • #13 21589586
    insmod
    Level 31  
    >>21589584
    Then it means we need some function on OBK (web app?) to read it and then write it at needed offset.
  • #14 21589591
    divadiow
    Level 38  
    insmod wrote:
    And perhaps bootloader log is on UART0?

    nothing on USB/CP210x P11 only D12/P0
  • #15 21589880
    jmkrzyszt
    Level 9  
    >>21589591 Hi, thanks for your efforts. AFAICU, the answer to my question is: yes, it's safe to flash my device with OpenBK7231U UART image, renamed to T, using BK7231 Easy UART Flasher. However, OBK is not yet able to detect and use device's MAC address from TLV and replaces it with its own, always the same, so only one device can be connected to a network (broadcast domain). Does that describe current status correctly?
  • ADVERTISEMENT
  • Helpful post
    #17 21589904
    insmod
    Level 31  
    In ESPHome it is not important where TLV is located, it can be adjusted at build.
    Code: text Expand Select all Copy to clipboard
    
esphome:
  name: Your Name
  friendly_name: Your Name
  platformio_options:
    board_flash.tlv: "0x10000+0x1000",

    Change 0x10000 to wherever it is located.
    For BK7231U those are also appliable
    Code: text Expand Select all Copy to clipboard
    
    board_build.bkcrypt_coeffs: 00000000000000000000000000000000
    board_build.bkboot_version: "0.1.4-bk7231u"
    board_build.mcu: "bk7231u"

    With bkcrypt_coeffs zeroed, you could flash it via uart.
  • #18 21589989
    jmkrzyszt
    Level 9  
    >>21589202 >>21589904 >>21589904 Perfect, thank you! I'll give it a try tonight and report.
    BTW, is that "0.1.4-bk7231u" a dummy placeholder just to avoid pulling a conflicting T bootloader (and using the one from flash instead), or does it point to an existing U bootloader version?
    Is there anything else I can do for you and your project about my device?
  • #19 21589997
    insmod
    Level 31  
    >>21589989
    It is a placeholder, but not for pulling T bootloader.
    If a default bkboot_version (for T) is detected, it sets a specific variable, that changes how it boots.
    It is a specific Tuya change, without it BK7231T bootloader doesn't fully boot. And if it is enabled on non-Tuya bootloader - it won't boot too.

    Extra: if you have the ability to flash via SPI (bootloader can't be flashed via UART on BK7231U/T/S), you can flash BK7231T bootloader and use normal T firmware (albeit built with zero keys). Though since it is now possible to flash U devices, it is not needed.
  • #20 21590030
    divadiow
    Level 38  
    insmod wrote:
    Then it means we need some function on OBK (web app?) to read it and then write it at needed offset.

    is this a possible/likely work-around?
  • #21 21590069
    insmod
    Level 31  
    >>21590030
    There is a read command.
    This is a choice of either adding separate write and erase commands and adding a script in web-app, or just adding a read TLV, erase destination and write what we've read, directly on device in one function.
  • Helpful post
    #22 21590739
    jmkrzyszt
    Level 9  
    >>21589904I've followed ESPHome instructions provided by @insmod (thank you!) and I've been able to flash my BK7231U ESPHome image (.rbl) to CC8000 over UART. However, original MAC address was not detected and got overwritten with C8:47:8C:42:00:48 (similar to C8:47:8C:42:88:48 with OBK).

    I've examined platformio documentation for BK7231T and compared a BK7231T factory image vs the BK7231U factory image. Based on that, I've managed to resolve the MAC issue by replacing
    Code: YAML
    Log in, to see the code
    entry with
    Code: YAML
    Log in, to see the code
    and re-flashing (OTA).

    Thank you @insmod and @divadiow for your support.

    Additional note: in the board_build.bkcrypt_coeffs entry, the string of zeros must be quoted, otherwise the build fails.
  • #23 21627951
    divadiow
    Level 38  
    clarification to make mapping to GPIOs in OpenBK7231U if using HLK-B30 a bit easier

    Pinout diagram of HLK-B30 module with color-coded GPIO and signal labels

    The inconsistencies in the D18/D16/D17/ESO labelling between module holes, pin header labels and board revisions is frustrating. Think this is correct.
    Following the logical numbering pattern on from ESO it probably makes sense that P21 is meant to be D16 and P20 is meant to be D17.
  • #24 21707295
    p.kaczmarek2
    Moderator Smart Home  
    I am playing with my BK7252 camera board, I flashed Arnoo_AiDot_RGBW_A19_(2ndGen)_(light.A001126)_Leedarson_CC8000_2.0.4.51.bin to it via SPI and got this on TX2:
    Terminal showing firmware boot log for CC8000 chip
    Also flashed this C-Chip_CC8000_HLK-B30_DevBoard.bin:
    RealTerm and BK7231 Easy UART Flasher interfaces with completed firmware write
    Code: text Expand Select all Copy to clipboard
    


õ:ퟄ�û訢ÿe¤†>      
V(0.1.4)
CPSR:0x000000D3
R0:0x3396E676
R1:0xFE7BFFB6
R2:0x9CFEF80B
R3:0x9EFD4765
R4:0x034DA3A1
R13:0xF2FAD7C9
R14(LR):0xB4FB121B
[I/FAL] Fal(V0.4.0)success
[I/OTA] RT-Thread OTA package(V0.2.4) initialize success.


go os_addr(0x10000)..........

 \ | /
- RT -     Thread Operating System
 / | \     3.1.0 build Apr  8 2021
 2006 - 2018 Copyright by rt-thread team
[FUNC]rwnxl_init

[bk]tx_txdesc_flush

[FUNC]calibration_main

get rfcali_mode:1

tssi_th:b-125, g-100

[rx_iq]rx_amp_err_rd: 0x026

[rx_iq]rx_phase_err_rd: 0x007

[rx_iq]rx_ty2_rd: 0x000

*********** finally result **********

gbias_after_cal: 0x17

gav_tssi: 0x0

gtx_q_dc_comp:0x201

gtx_i_dc_comp:0x1ff

gtx_i_gain_comp:1010

gtx_q_gain_comp:1023

gtx_phase_comp:497

gtx_phase_ty2:512

gtx_ifilter_corner over: 0xf

gtx_qfilter_corner over: 0x10

gtx_dcorMod:0x8, gtx_dcorPA:0x8

gtx_pre_gain:0x10

g_rx_dc_gain_tab 0 over: 0x80808080

g_rx_dc_gain_tab 1 over: 0x84808480

g_rx_dc_gain_tab 2 over: 0x8a788c7c

g_rx_dc_gain_tab 3 over: 0xa06c9470

g_rx_dc_gain_tab 4 over: 0xa068a068

g_rx_dc_gain_tab 5 over: 0xa0669f66

g_rx_dc_gain_tab 6 over: 0xa268a166

g_rx_dc_gain_tab 7 over: 0xa16aa168

grx_amp_err_wr:0x1ed

grx_phase_err_wr:0x003

**************************************

flash txpwr table:0xf

dif g and n20 ID in flash:2

dif g and n40 ID in flash:4

read txpwr tab from flash success

temp in flash is:280

xtal inital:280, 70, 16

lpf_i & q in flash is:12, 12

xtal in flash is:48

xtal_cali:48

--init_xtal = 48
-----pwr_gain:12, g_idx:12, shift_b:0, shift_g:0
-----[pwr_gain]12
rwnx_tpc_pa_map_init

[FUNC]ps_init

[FUNC]func_init_extended OVER!!!



tcp_port=1221762145

tcp_port=63957

lwIP-2.0.2 initialized!
igmp_mac_filter add 224.0.0.1 01:00:5E:00:00:01
register station wlan device sucess! 
igmp_mac_filter add 224.0.0.1 01:00:5E:00:00:01
register soft-ap wlan device sucess! 
beken wlan hw init

drv_pm_init
[D/FAL] (fal_flash_init:63) Flash device |             beken_onchip | addr: 0x00000000 | len: 0x00200000 | blk_size: 0x00001000 |initialized finish.
[D/FAL] (fal_flash_init:63) Flash device |         beken_onchip_crc | addr: 0x00000000 | len: 0x00200000 | blk_size: 0x00001000 |initialized finish.
[I/FAL] ==================== FAL partition table ====================
[I/FAL] | name       | flash_dev        |   offset   |    length  |
[I/FAL] -------------------------------------------------------------
[I/FAL] | bootloader | beken_onchip_crc | 0x00000000 | 0x00010000 |
[I/FAL] | app        | beken_onchip_crc | 0x00010000 | 0x00110000 |
[I/FAL] | download   | beken_onchip     | 0x00132000 | 0x000c4000 |
[I/FAL] | param1     | beken_onchip     | 0x001f6000 | 0x00004000 |
[I/FAL] | param2     | beken_onchip     | 0x001fa000 | 0x00004000 |
[I/FAL] | param3     | beken_onchip     | 0x001fe000 | 0x00001000 |
[I/FAL] | param4     | beken_onchip     | 0x001ff000 | 0x00001000 |
[I/FAL] =============================================================
[I/FAL] RT-Thread Flash Abstraction Layer (V0.4.0) initialize success.
Enter normal mode...



app_init finished

[Flash]id:0xb4016

flash_init end

ap ssid=-HLK-B30_3EE3,12345678-

[DRV_WLAN]drivers\wlan\drv_wlan.c L940 beken_wlan_control cmd: case WIFI_INIT!

_wifi_softap: ssid:HLK-B30_3EE3 key:12345678

ap init ok

ble start no ble name

ble name:BK7231BT-01, 45:33:4c:cc:3e:e3

-----rw_main task init----

-----rw_main  start----

gapm_cmp_evt_handler operation = 0x1, status = 0x0 

gapm_cmp_evt_handler operation = 0x3, status = 0x0 

STACK INIT OK

ble create new db

ble_env->start_hdl = 0x7

gapm_cmp_evt_handler operation = 0x1b, status = 0x0 

CREATE DB SUCCESS

start watch dog
rt_hw_wdg_start time=10000 threshold=5000
iSockFD=4

ip addr=660ba8c0,port=8080



TCP ERROR: tcp client connect server error! -1

msh />sending broadcast_deauth:5

Soft_AP_start

[saap]MM_RESET_REQ

[bk]tx_txdesc_flush

[saap]ME_CONFIG_REQ

rw_msg_send_me_config_req ps_on is 1

[saap]ME_CHAN_CONFIG_REQ

[saap]MM_START_REQ

[csa]csa_in_progress[0:0]-clear

mm_add_if_req_handler:0

hapd_intf_add_vif,type:3, s:0, id:0

apm start with vif:0

------beacon_int_set:100 TU

set_active param 0
[msg]APM_STOP_CFM
update_ongoing_1_bcn_update

mm_set_vif_state_req_handler

vif_idx:0, ch_idx:0, bcmc_idx:2

update_ongoing_1_bcn_update

hapd_intf_add_key CCMP

add is_broadcast_ether_addr

sta:255, vif:0, key:1

add hw key idx:1

uap_ip_start



configuring interface uap (with Static IP)
dhcp_check_status_init_timer



please use rtthread dncp start server
[DHCP] dhcpd_start: ap

[DHCP] aaaaaa=fe10a8c0,ffffff

[DHCP] aaaaaa=192.168.16.254,255.255.255.0

[DHCP] dhcp_server_start(): starting new DHCP server
[DHCP] dhcp_server_start(): starting DHCP server
def netif is no ap's netif, sending boardcast or no-subnet ip packets may failed

sending broadcast_deauth:5

cal dpll!

cal_bias!

do td cur_t:4095--last:idx:13,t:280 -- new:idx:23,t:500 

--0xc:08, shift_b:0, shift_g:0, X:0
td set tpc pwr: shift_b:0, shift_g:0

appm start advertising

socket_fd=4

cal dpll!

cal_bias!

do td cur_t:4095--last:idx:23,t:500 -- new:idx:33,t:500 

--0xc:08, shift_b:3, shift_g:3, X:63
init_xtal:48, delta:63, last_xtal:48

td set pwr: shift_b:3, shift_g:3, rate:54

td set tpc pwr: shift_b:3, shift_g:3

td set ble pwr: shift:3, cur_idx:0

iSockFD=5

ip addr=660ba8c0,port=8080

cal dpll!

cal_bias!

do td cur_t:4095--last:idx:33,t:500 -- new:idx:38,t:500 

--0xc:08, shift_b:3, shift_g:3, X:63
init_xtal:48, delta:63, last_xtal:63

td set tpc pwr: shift_b:3, shift_g:3



TCP ERROR: tcp client connect server error! -1

iSockFD=5

ip addr=660ba8c0,port=8080

    Wi-Fi network list showing secured network HLK-B30_3EE3 highlighted

    Added after 1 [minutes]:

    If that thing is running on my BK7252 and I can connect to the AP, would that mean that OpenBK7252_QIO_1.18.184.bin can run on CC8000?
    Helpful post? Buy me a coffee.
  • #25 21707403
    insmod
    Level 31  
    So if BK7252 firmware can be used on BK7231U, does that mean that encrypted Tuya BK7252 can run BK7231T bootloader? (BK7231N bootloader would actually be better, since current 7252 firmware wouldn't be bootable on T bootloader)
  • Helpful post
    #27 21707425
    p.kaczmarek2
    Moderator Smart Home  
    I added "drag and drop" binary support for flasher and external SPI reset so I can flash quickly. I also really need to add RTS/etc RESET to EF as well, but I don't have such USB to UART converter. Maybe I will just use CH341 as well, if possible, not sure.
    Helpful post? Buy me a coffee.
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion focuses on the Hi-Link HLK-B30 development board featuring the C-Chip CC8000/BK7231U SoC and its compatibility with OpenBK7231U firmware. Users report successful OTA updates and UART flashing of OpenBK7231U images to CC8000 devices using tools like BK7231 Easy UART Flasher and FTDI adapters. A critical issue is the handling of the MAC address and calibration data stored in the TLV (Type-Length-Value) section of flash memory, originally located at 0x1FE000 but needing relocation to 0x1E0000 for BK7231U compatibility. OpenBK7231U firmware currently does not automatically detect or preserve the device's original MAC address from TLV, causing network conflicts when multiple devices use the same default MAC. Workarounds include modifying firmware build parameters (e.g., board_flash.tlv or board_flash.calibration offsets) and using ESPHome platformio options to specify TLV location and zero out encryption keys (bkcrypt_coeffs) for UART flashing. The bootloader cannot be flashed via UART and requires SPI flashing; however, flashing BK7231T bootloader on BK7231U devices is possible but generally unnecessary due to improved U device support. Suggestions for firmware enhancements include adding functions to read, erase, and write TLV data via the web app to preserve MAC and calibration data. The thread also references related devices such as the Leedarson-made Winees WS010078261 RGBW bulb and discusses nuances in bootloader versions and their impact on device boot behavior.
Generated by the language model.
Today's popular

FAQ

TL;DR: For HLK-B30 and similar CC8000 boards with 2 MB flash, “TLV is the most obvious issue”: OpenBK7231U boots, SPI flashing from 0x0 works, and OTA can succeed, but some devices lose the factory MAC unless TLV or calibration data is handled correctly. This FAQ is for developers freeing CC8000 hardware from cloud firmware and preserving MAC/calibration during flashing. [#21589558]

Why it matters: It turns scattered forum findings into a citation-ready guide for flashing, debugging, OTA updates, and MAC-preserving migration on Hi-Link HLK-B30 and other CC8000 devices.

Method What it can change Proven in thread Main limitation
CH341A SPI from 0x0 Bootloader + full flash Yes Requires pad-level wiring
UART flashing App firmware only Yes Cannot replace bootloader
OTA from OpenBK7231U Download/app area Yes Web UI currently filters for .img
ESPHome UART/OTA path App + later OTA Yes Needs correct calibration/TLV setting

Key insight: OpenBK7231U already runs on CC8000 hardware, but reliable preservation of the original MAC depends on reading calibration or TLV from the correct flash offset, often 0x10000 on the affected Leedarson dumps.

Quick Facts

  • The HLK-B30 board exposes a 3.3 V supply on VBAT, and the tested module used an EN25QH16 2 MB SPI flash detected by NeoProgrammer. [#21586747]
  • OpenBK7231U OTA on HLK-B30 initialized its download slot at 0x132000 and closed near 0x1AF400, then rebooted successfully. [#21586752]
  • The stock partition layout shown by a later CC8000 dump used bootloader 0x00000000–0x00010000, app 0x00010000–0x00110000, and download 0x00132000–0x000C4000. [#21707295]
  • Debug output on HLK-B30 was confirmed on TX2 / D12 / P0, while nothing appeared on the USB-serial path tied to P11 in that test setup. [#21587742]
  • A working SoftAP example came up as 192.168.4.1/24 with SSID OpenBK7231U_8C428848, showing that the flashed firmware could fully boot and expose a config AP. [#21589558]

How do I flash OpenBK7231U on a Hi-Link HLK-B30 with the C-Chip CC8000 using CH341A SPI from address 0x0?

Use SPI, not UART, if you need a full image from address 0x0. 1. Wire CH341A to the HLK-B30 pads using the tested mapping, including RST, SCK, CS0, MOSI, MISO, and GND. 2. Put the board in SPI mode and confirm the EN25QH16 2 MB flash is detected. 3. Write the full merged image, such as OpenBK7231U_QIO_1680_merge_55ebe0a12aba.bin, starting at 0x0. This path is required when you also need to write the bootloader, because BK7231U has no ROM boot fallback in this context. [#21586747]

What is the correct HLK-B30 to CH341A pin mapping for SPI flashing, including the mislabeled D16/ESO pads on board revisions v2.1 and v3.0?

The tested mapping is: RST→D2, D17→SCK, ESO/D16 between D17 and D15→CS0, ESO between GND and D1→MOSI, D15→MISO, GND→GND. On v2.1, D16 is mislabeled as ESO. On v3.0, that label was corrected. A later clarification notes that the D18/D16/D17/ESO silkscreen remains inconsistent across holes and headers, so verify pad position, not only the printed label. [#21586747]

Why does OpenBK7231U on some CC8000 devices boot with a generic MAC address like C8:47:8C:42:88:48 instead of the factory MAC?

It happens because OpenBK7231U may not read the device’s original TLV or calibration data from the offset used by that CC8000 firmware. In the tested Leedarson dump, the factory MAC stayed visible in flash, but OpenBK7231U came up with the generic C8:47:8C:42:88:48 instead of the original 1C:D6:BD:D4:57:83. That means the firmware booted, but it did not consume the original MAC source correctly. [#21589558]

What is TLV on BK7231U/CC8000 firmware, and why does its flash location matter for MAC and calibration data?

"TLV" is a flash data structure that stores device-specific values, key characteristic data such as MAC address and RF calibration. Its location matters because firmware reads those values from a fixed offset. One thread note says BK7231U should move TLV from 0x1FE000 to 0x1E0000 for correct MAC and calibration handling, while some Leedarson-based CC8000 dumps appear to keep the relevant data around 0x10000 instead. If firmware looks in the wrong place, it boots with defaults. [#21586895]

How can TLV data be copied or moved so OpenBK7231U keeps the original MAC and calibration values on CC8000 hardware?

The practical fix is to read the original TLV or calibration block from its existing offset and write it to the offset OpenBK7231U expects. The thread narrowed this to either adding separate read, erase, and write commands in the web app, or implementing one device-side function that reads TLV, erases the destination, and writes it back in one step. That approach was proposed after confirming the original TLV remained intact in flash. [#21590069]

What is the difference between OTA .img, .rbl, and merged .bin files in the OpenBK7231U flashing process?

They target different flash paths. A merged .bin is the full image for SPI flashing from 0x0. OTA uses the download area, and the thread shows successful updates with OpenBK7231U through that path. .rbl also worked in ESPHome and OTA-style flows, but the OpenBK7231U web app currently filters for .img, not .rbl. That means the file may be valid while the current web UI still rejects its extension. [#21586752]

Which UART pin on the HLK-B30 carries debug output for CC8000/OpenBK7231U, and why might the bootloader stay silent on other UART pins?

The confirmed debug log came from TX2 on D12/P0. A later test also states that nothing appeared on the USB/CP210x path tied to P11, while output was visible on D12/P0. The bootloader can therefore look silent if you monitor the wrong UART. One reply also asked whether the bootloader log might be on UART0, which matches the observed need to probe a different serial pin than the obvious USB header. [#21589591]

How does OpenBK7231U UART flashing compare with SPI flashing on CC8000 devices when the bootloader cannot be replaced over UART?

UART flashing is enough to test or deploy OpenBK7231U on CC8000, but it cannot replace the bootloader. SPI flashing can replace both bootloader and application from 0x0. One expert summary in the thread states: “bootloader can't be flashed via UART on BK7231U/T/S.” In practice, UART worked by renaming the U image to a T name for Easy UART Flasher, while SPI remained the only path for full low-level recovery or bootloader experiments. [#21589997]

What steps were used to get OTA updates working on the HLK-B30 with OpenBK7231U, and why does the web app currently filter for .img instead of .rbl?

OTA worked after first booting OpenBK7231U normally, then uploading an OTA package through the GUI so the board wrote from 0x132000 upward and rebooted into the new app. 1. Flash or boot a working OpenBK7231U build. 2. Open the quick GUI or web page. 3. Upload the OTA image and wait for the reboot. The thread notes the web app currently filters for .img, not .rbl, even though .rbl can be valid in related workflows. [#21586752]

Why do 'No TLV header found in flash' and 'lfs is absent' appear in OpenBK7231U logs on the HLK-B30, and how serious are those messages?

They usually indicate missing optional data, not an immediate boot failure. No TLV header found in flash means OpenBK7231U did not find expected device data at the checked offset. lfs is absent means the little file system area is empty, so startup scripts like autoexec.bat are unavailable. In the same logs, the board still finished initialization, started HTTP, and even exposed SoftAP, so these messages are important for configuration fidelity, not proof of a dead flash. [#21589558]

How can ESPHome be configured for a CC8000/BK7231U device so it reads the original MAC correctly from calibration data at 0x10000?

Set ESPHome to read calibration data from 0x10000 instead of using the TLV key. The working fix replaced board_flash.tlv: "0x10000 0x1000" with board_flash.calibration: "0x10000 0x1000", then reflashed by OTA. That change made the original MAC read correctly on the tested CC8000 device. The same post also notes that the zero-filled board_build.bkcrypt_coeffs value must be quoted, or the build fails. [#21590739]

What does the placeholder setting board_build.bkboot_version: "0.1.4-bk7231u" do in ESPHome or LibreTiny builds for BK7231U-based CC8000 devices?

It is a placeholder that prevents the wrong boot behavior from being enabled, not a request to fetch a T bootloader. The thread explains that if the default BK7231T bootloader version is detected, the build sets a special variable for a Tuya-specific boot path. That path is needed on some T devices, but it can break booting on non-Tuya or non-T bootloaders. Using "0.1.4-bk7231u" avoids that conflicting mode on CC8000/BK7231U hardware. [#21589997]

What should I back up from a Leedarson CC8000 bulb before experimenting with OpenBK7231U, and which backup formats include the useful bootloader and calibration data?

Back up the full flash from 0x0 before testing anything. The thread explicitly recommends a full backup first, then checking whether the bootloader and TLV or calibration data are present. A 2 MB .bin dump is the most useful because it can include bootloader, app, and device data in one image. The user also had a UARTProgram .img, but the later analysis focused on the 2 MB backup as the one that “boots just fine” and exposes the original MAC in flash. [#21589558]

Which HLK-B30 GPIO labels correspond to the actual P20, P21, and related pins in OpenBK7231U, given the confusing D18/D16/D17/ESO board markings?

The later mapping clarification says the board silkscreen is inconsistent, but the logical numbering suggests P21 should be D16 and P20 should be D17. That matters because HLK-B30 labels differ between module holes, header labels, and revisions like v2.1 and v3.0. If you configure OpenBK7231U only from the printed D labels, you can assign the wrong GPIO. Use the clarified diagram and continuity checks where possible. [#21627951]

If original CC8000 firmware runs on a BK7252 board and exposes an AP, what would that imply about trying OpenBK7252_QIO_1.18.184.bin on CC8000 hardware?

It would suggest cross-compatibility is plausible, but the thread stops short of proving OpenBK7252 runs on CC8000. The reported experiment flashed original CC8000 binaries onto a BK7252 camera board, produced logs, and exposed an AP such as HLK-B30_3EE3. The follow-up question asked whether that implies OpenBK7252_QIO_1.18.184.bin can run on CC8000 hardware, but no confirmation answer appears in the provided posts. Treat it as an informed hypothesis, not a verified result. [#21707295]
Generated by the language model.
ADVERTISEMENT