Yup seems to work, that's kinda epic, I imagine this will help with any future off brand devices significantly.
![[BL2028N/BK7231M] Flashing Dogness D07 (Belon Chip) - Boot Issues](https://obrazki.elektroda.pl/6738486400_1717592156.png "[BL2028N/BK7231M] Flashing Dogness D07 (Belon Chip) - Boot Issues")
Yup seems to work, that's kinda epic, I imagine this will help with any future off brand devices significantly.
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
terryb8s wrote:>>21112216 Thank you divadiow, I didn't realize the title would be available in the first post but that makes sense now that you say it... fixed the title now.
"pins": {
"6": "Btn;2",
"28": "Rel;5"
},..
p.kaczmarek2 wrote:does button also trigger channel 5? I don't think so.
TL;DR: With a 2 MB flash dump and the factory bootloader preserved, the workable fix was: "leave the factory one" and flash OpenBeken as a QIO app instead of replacing boot code. This FAQ is for Dogness D07 and similar BL2028N/BK7231M-style devices that boot to garbage UART output or lose Wi‑Fi after flashing. [#21109139]
Why it matters: This thread shows how to recover and modernize an RT-Thread-based BK7231 device without destroying the original boot path.
| Option | Boot result | Required special settings | Reported issues |
|---|---|---|---|
| Standard BK7231N OpenBeken flash from 0x0 | No boot | None | UART shows squares, no AP |
| LibreTiny/ESPHome UF2 with zeroed crypto settings | Boots | Custom key/IV and 0x132000+0xAE000 download map |
Initial Wi‑Fi issues |
| OpenBeken QIO while preserving factory bootloader | Boots | Keep factory bootloader, then flash app | RF restore may still be needed |
Key insight: The decisive fix was not a different UART adapter or more power. The device used a nonstandard RT-Thread bootloader and partitioning, so preserving the original bootloader and app layout mattered more than flashing another generic BK7231N image. [#21096057]
szMem: 1000000, which corresponds to a 16 Mbit / 2 MB flash size used throughout the recovery attempts. [#21096016]go os_addr(0x10000) and RT-Thread OTA init, indicating the original application booted from 0x10000, not a typical plain Tuya-style layout. [#21453281]00:00:00 and UAP became unreliable; after RF restore, a unique MAC returned and STA mode connected correctly. [#21108271]0x0 to 0x10000. 3. Flash the OpenBeken QIO app without overwriting boot code. Later flasher changes explicitly skipped the bootloader by default because overwriting it was considered a mistake on these devices. That approach solved booting on the Dogness D07 while keeping the RT-Thread startup path intact. [#21109139]0x0 to 0x10000. 3. Flash OpenBK7231N_App_QIO_1.0.0.bin, then restore RF/Net if needed. A later code note confirmed the combined image used 0x10000, not 0x11000, when overwriting the bootloader section in the build workflow. [#21108341]00:00:00, plus a UAP that either failed to load or connected with no usable web app. After RF restore, the device regained a unique MAC and connected correctly in STA mode. The thread also noted that full erase wipes the RF partition, while later OpenBeken flashing does not recreate its original contents automatically. [#21105171]0x1D0000 with length 0x1000, and NET info at 0x1D1000 with length 0x1000. The original Dogness logs also showed missing or defaulted calibration items such as TX power tables, thermal values, and XTAL settings when reading flash. [#21453281]bkcrypt_coeffs, custom OTA key and IV, and a nonstandard 0x132000+0xAE000 download map. OpenBeken also worked later, but only after preserving the factory bootloader path or using adjusted builds. If your goal is first boot on this exact Dogness D07, LibreTiny reached a working state earlier in the troubleshooting timeline. [#21103253]WARN: TCPIP mutex is NOT locked (1) caller 53D07 while the AP initialized, yet another tester reported seeing similar “mutex” messages on a different device where AP still worked. That makes it a plausible clue, not a confirmed diagnosis. On the Dogness D07, AP instability persisted even after RF restore, so the warning alone does not explain everything. [#21109280]board_build.bkcrypt_coeffs: "000...000", board_build.bkota.key: "0123456789ABCDEF0123456789ABCDEF", board_build.bkota.iv: "0123456789ABCDEF", and board_flash.download: "0x132000+0xAE000". Then generate the UF2 and flash it with ltchiptool. That produced a bootable image on the Dogness D07 and enabled further LibreTiny or OpenBeken testing. [#21103253]RT-Thread OTA package(V0.2.4) and booting with go os_addr(0x10000), which already differs from typical plain OpenBeken assumptions. “RT-Thread OTA is a firmware update framework that boots applications from a defined offset and manages packaged images, using its own partition expectations and metadata.” That difference explains why a generic BK7231N image failed until the factory boot path was respected. [#21453281]Btn_ScriptOnly plus autoexec.bat. In the Dogness config, pump control used P8 and P9 on channel 4, while P28 was a relay on channel 5. The user found that a normal button mapping still triggered channel 5, but stripping the config showed the LED driver caused that interaction. The maintainer’s recommended workaround was Btn_ScriptOnly and manual scripting so the pump slider stays independent from LED toggles. [#21112302]P8 and P9 with an oscilloscope in November 2024, hoping to reduce pump noise versus plain PWM. The maintainer replied that he had never seen BK7231 generate such waveforms and asked whether the GPIO had been isolated before measurement, suggesting passive components on the board may have altered the observed shape. That leaves the waveform unconfirmed and unreproduced. [#21316886]