So your Tuya config contains:
but your device is using pins 7 and 8 in reality?
Helpful post? Buy me a coffee.
Code: JSON
Log in, to see the code
but your device is using pins 7 and 8 in reality?
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
$> pacman -Qi bk7231tools
Name : bk7231tools
Version : 2.0.2-1
$> bktools dissect_dump -O output -e --rbl --storage lcs-led-rgbw-lb2.img
RBL containers:
0x10f9a: bootloader - [encoding_algorithm=NONE, size=0xea20]
extracted to output
0x129f0a: app - [encoding_algorithm=NONE, size=0xec1a0]
extracted to output
Storage partition:
0x1ee000: 28 KiB - 3 keys
- 'gw_bi'
- 'tuya_seed'
- 'gw_di'
WARNING:root:Block by ID 2 does not exist, returning empty
extracted all keys to output/lcs-led-rgbw-lb2_storage.json
WARNING:root:Block by ID 2 does not exist, returning empty
extracted 'gw_bi' to output/lcs-led-rgbw-lb2_storage_gw_bi.bin
extracted 'tuya_seed' to output/lcs-led-rgbw-lb2_storage_tuya_seed.bin
extracted 'gw_di' to output/lcs-led-rgbw-lb2_storage_gw_di.bin
App code `user_param_key`:
- found! Extracted to output/lcs-led-rgbw-lb2_user_param_key.json
$> cat output/lcs-led-rgbw-lb2_user_param_key.json
{
"2235ccur": 14,
"2235wcur": 6,
"Jsonver": "1.1.9",
"brightmax": 100,
"brightmin": 5,
"cagt": 20,
"category": "0505",
"cmod": "rgbcw",
"colormax": 100,
"colormin": 10,
"colorpfun": 1,
"crc": 72,
"cwmaxp": 100,
"cwtype": 0,
"defbright": 100,
"defcolor": "c",
"deftemp": 100,
"dmod": 8,
"gmkb": 60,
"gmkg": 60,
"gmkr": 80,
"gmwb": 75,
"gmwg": 70,
"gmwr": 100,
"iicb": 0,
"iicc": 4,
"iicg": 1,
"iicr": 2,
"iicscl": 24,
"iicsda": 9,
"iicw": 3,
"module": "CBU",
"notdisturb": 0,
"onoffmode": 1,
"pairt": 600,
"pmemory": 1,
"prodagain": 0,
"remdmode": 1,
"rgbt": 15,
"rstbr": 50,
"rstcor": "c",
"rstnum": 5,
"rsttemp": 100,
"title20": 1,
"wfcfg": "spcl",
"wfct": 10,
"wt": 20
}
=> Pin 24 (scl) and 9 (sda) was extracted in combination with the SM2235 driver.
Sorry, exception occured: System.ArgumentNullException: Buffer cannot be null.
Parameter name: buffer
at System.IO.MemoryStream..ctor (System.Byte[] buffer, System.Boolean writable) [0x00009] in <296872a6734f443990477e3abd954b57>:0
at System.IO.MemoryStream..ctor (System.Byte[] buffer) [0x00000] in <296872a6734f443990477e3abd954b57>:0
at (wrapper remoting-invoke-with-check) System.IO.MemoryStream..ctor(byte[])
at BK7231Flasher.TuyaConfig.fromBytes (System.Byte[] data) [0x0013f] in <0c14a74d79404cf69fc2e40bca5b14d7>:0
at BK7231Flasher.TuyaConfig.fromFile (System.String fname) [0x00024] in <0c14a74d79404cf69fc2e40bca5b14d7>:0
at BK7231Flasher.FormMain.importTuyaConfig (System.String file) [0x00008] in <0c14a74d79404cf69fc2e40bca5b14d7>:0
"pins": {
"7": "BP5758D_DAT;0",
"8": "BP5758D_CLK;0"
},
TL;DR: On this bulb, 2 pins mattered most: "it works like a charm" only after OpenBeken used the BP5758D driver on pins 7/8, not the extracted 9/24. This FAQ helps LSC 2578539.2 owners fix UART flashing, wrong GPIO templates, and patched-firmware roadblocks. [#21431966]
Why it matters: This thread shows that a successful flash can still fail in practice if wiring, power injection, and extracted Tuya GPIO data do not match the real hardware.
| Approach | What the thread found | Practical result |
|---|---|---|
| BK7231 UART flashing | Works when wiring is corrected and the adapter's 3.3V lead is removed | Successful flashing reported |
| Tuya config extraction only | Reported iicscl 24 and iicsda 9 with SM2235 |
Wrong for this bulb batch |
| OpenBeken with verified pins | BP5758D, pins 7/8, map 0 1 2 3 4 |
Bulb worked |
| Tuya CloudCutter | Firmware 1.5.2 / 3.3.42 listed as patched |
Not suitable for profile-based cloud flashing |
Key insight: The biggest failure point was not the flasher itself. The real fix was verifying the live LED-driver pins on the PCB and ignoring a misleading Tuya extraction result.
bktools dissect_dump showed a 2MB flash image, a 28 KiB storage partition, and extracted iicscl 24 / iicsda 9 from user_param_key. [#21434152]BP5758D_DAT on pin 7, BP5758D_CLK on pin 8, and BP5758D_Map 0 1 2 3 4. [#21431966]U1_TX on the PCB, and the next troubleshooting step was to inspect the board's other side and follow traces to confirm which pads really reached UART1. On this bulb, trace inspection was used to challenge an incorrect initial assumption. [#21244235]startDriver BP5758D, setPinRole 7 BP5758D_DAT, setPinRole 8 BP5758D_CLK, BP5758D_Current 10 5, and BP5758D_Map 0 1 2 3 4. The same post also shared an importable template for BK7231N on a CBU module. [#21431966]iicscl: 24 and iicsda: 9 were extracted, yet the bulb only worked with OpenBeken on pins 7 and 8. A follow-up suggested the keys partition may have contained an older configuration that no longer matched the factory-wired board. [#21434397]bktools on the full dump and read the extracted user_param_key.json.
bktools dissect_dump -O output -e --rbl --storage <dumpfile>.user_param_key files in the output directory.module, iicscl, iicsda, and current values.iicscl 24 plus iicsda 9. [#21434152]1.5.2 / 3.3.42 BUILD AT:2023_09_05_15_44_43 was explicitly described as being on the known patched list, so a CloudCutter profile was considered impossible for that bulb. [#21426598]BP5758D_Map 0 1 2 3 4. The extracted current suggestion was 14 6, but the confirmed working post chose 10 5 for lower heat. That combination restored correct operation on the LSC RGB+CCT bulb. [#21431966]1.5.2 / 3.3.42 is on the known patched list, so CloudCutter profile flashing was ruled out. By contrast, direct UART flashing was the path that actually produced working OpenBeken installs on this bulb family. [#21426598]