Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
p.kaczmarek2 wrote:It seems we need to lower the default current, @divadiow
)
TL;DR: If you have a 2 MB Surplife BK7238 bulb and "QIO from 0x0" boot-loops, flash the original dump first, then write the
.rblOpenBeken image at0x132000; one tester said, "then the AP broadcasts." This FAQ is for people moving a WB43-M5 V1.1 bulb from stock firmware to OpenBeken without losing recovery options. [#21376560]
Why it matters: These BK7238 bulbs can look successfully flashed yet still fail to boot, hide the AP, or stop driving the BP5758D unless you use the right image type, address, UART, and current settings.
| Metoda | Plik | Adres flash | Wynik w wątku |
|---|---|---|---|
| Bezpośredni flash QIO | OpenBK7238_QIO...bin |
0x0 |
brak startu lub pętla bootowania |
| Flash OTA-style | OpenBK7238__...rbl.bin |
0x132000 |
AP pojawia się i firmware startuje |
| Przywrócenie kopii fabrycznej | pełny dump producenta | cały flash | urządzenie wraca do stanu wyjściowego |
Kluczowy wniosek: Najważniejsza różnica nie dotyczy samego narzędzia, lecz formatu obrazu i adresu zapisu. W tym wątku działający scenariusz dla WB43-M5 V1.1 to zachowanie kopii fabrycznej oraz wgrywanie obrazu
.rblna0x132000, a nie obrazu QIO od0x0. [#21438266]
I tried the command, but sadly it's still dead Jim 
35_243_20240425_ZG-BK38-BP101. [#21375947]rgbwc_ele 8 8 8 30 30, a w OpenBeken zasugerowano komendę BP5758D_Current 8 30, aby odwzorować prądy RGB i CW bliżej ustawień producenta. [#21633387]OpenBK7238__...rbl.bin at 0x132000. 3. Reboot and look for the OpenBeken AP before changing Wi‑Fi or LED settings. This exact flow brought up the AP on the Surplife BulbD46D with BP5758D after direct QIO flashing failed. [#21376560]firmwares folder, rename it to the expected BK7231N-style filename, enable advanced options, and select skip key check. BKFIL was also used successfully for writing both the factory dump and the .rbl image. The key point is that BK7238 support was still experimental, so write support depended on these specific tools and file naming workarounds. [#21376381]0x0 was the failing path in this thread. One boot log repeatedly showed go os_addr(0x10000) and restarted instead of reaching a working AP. Later testing confirmed that flashing QIO directly could fail to boot, while the .rbl image flashed from 0x132000 worked. A later fix also identified one boot issue as wrong encryption handling during build, which broke QIO boot until corrected. [#21438385]OpenBK7238__beken_sdk_f866976df64b.rbl.bin flashed at address 0x132000. The tester first restored the original full firmware image, then wrote the .rbl file from that offset. He reported that if you opened the COM port fast enough, you could catch the end of OTA activity, and after that the OpenBeken AP started broadcasting. That is the clearest successful recipe shown for this exact Surplife BulbD46D and BP5758D setup. [#21376560]BP5758D rgbwc_ele 8 8 8 30 30, and the suggested OpenBeken command was BP5758D_Current 8 30. CLK and DAT mapping also matter; later users tried GPIO 24 and 26. Wrong current or wrong pin mapping can leave the lamp dark even when Wi‑Fi still works. [#21633387].rbl file at 0x132000. For recovery, BKFIL proved especially useful because it handled whole-image restoration cleanly in the successful test. If you need predictable rollback, keep BKFIL ready even if you start with Easy Flasher. [#21376381]0x0 gave no usable output, while restoring stock and flashing the .rbl image at 0x132000 made the AP appear. Success in the flasher does not guarantee a bootable runtime image on BK7238. [#21376560].rbl OpenBeken path, and a later user restored backup firmware after BP5758D control stopped working. In that later case, the bulb still needed an app firmware upgrade before normal light control returned, which shows recovery may take two stages: flash restore first, vendor update second. Keep the original dump before any experiment. [#21633920]BP5758D_Current 8 30. The factory boot log showed rgbwc_ele 8 8 8 30 30, and a later warning suggested that running with higher defaults may have contributed to the lamp becoming unresponsive. One tester feared the driver was burnt, but the device later recovered on stock firmware, so misconfiguration is a realistic failure mode. Start low, confirm output, and only then change channel mapping or brightness-related settings. [#21633387]192.168.4.1, entered local Wi‑Fi credentials, still had a working UI, then after power cycling saw current drop from about 35 mA to 5 mA within 2 seconds and lost access. Separate posts showed BK7238 stability was still being fixed around OTA, flasher updates, and smaller firmware issues. So the likely trigger was a firmware-side crash during normal startup after config reload. [#21439906].rbl image was the OTA-style payload that booted correctly when written at 0x132000, while the QIO .bin written from 0x0 was the failing direct-flash path. You do not need the internal packaging details to use it safely here; the operational difference is what matters. The tester even noted you could catch the tail end of OTA over serial, then see the AP start. For this bulb, .rbl was the working install format and QIO-at-zero was not. [#21376560]