Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
PXL_20230713_072152665.jpg
(2.43 MB)
You must be logged in to download this attachment.
TL;DR: At 115200 baud, the fix was not Mono tuning but changing method: "RX or TX line may be used for some other purpose" explains why UART flashing stalled on this Linux setup. This FAQ helps Linux users flashing a NAS-IR02W6-PRO V3 by showing when to stop fighting
unable to get busorUnprotect Failedand switch to Tuya Cloudcutter. [#20667886]
Why it matters: This thread shows that a BK7231N device can reject normal UART flashing on Linux yet still accept OpenBeken cleanly through Tuya Cloudcutter.
| Method | Linux result in thread | Main failure or outcome | Best use |
|---|---|---|---|
| Mono GUI tool | Unstable / failed | "unable to get bus" and later key-extraction issues | Only for quick tests |
hid_download_py / uartprogram |
Partly works | Bus access at 115200 baud, then Unprotect Failed |
Use if RX/TX are clean |
| Tuya Cloudcutter | Successful | OpenBeken flashed, then OTA updated | Best fallback when UART fails |
Key insight: If both FT232 and CH340G fail the same way, the board wiring is the stronger suspect than Linux itself. On this device, shared or loaded RX/TX lines were the most credible root cause, and Cloudcutter bypassed that whole path. [#20669566]
-b 115200, --startaddr 0x0, and a BK7231N image, but it still stopped at Unprotect Failed. [#20657806]OpenBeken-v1.17.130_bk7231n.ug.bin and reported firmware progress at 8%, 27%, 57%, 87%, and 98% before completion. [#20669566]infre: 7, infrr: 8, and wfst_pin: 9, confirming the IR receive and Wi-Fi status pins from device data. [#20705858]python uartprogram ... -b 115200 -u -d /dev/ttyUSB0 -w --startaddr 0x0, but Unprotect Failed still occurred. The most practical fixes suggested were shorter wires, checking whether RX/TX are used elsewhere on the board, and testing directly on the BK7231N chip pins instead of through the header. If that still fails, switch to Tuya Cloudcutter. [#20657806]infre: 7, infrr: 8, and wfst_pin: 9. RF send and RF receive were not resolved in the thread, so there is no verified RF GPIO mapping here. That makes RF the main remaining unknown on this board version. [#20705858]OpenBeken-v1.17.130_bk7231n.ug.bin over a local access point named cloudcutterflash. It succeeded after repeated UART failures with both FT232 and CH340G adapters. [#20669566]sudo ./tuya-cloudcutter.sh, choose Flash 3rd Party Firmware, then select 2.0.0 - BK7231N / oem_bk7231n_irbox_mol_ty. 2. Choose OpenBeken-v1.17.130_bk7231n.ug.bin and put the device into AP slow-blink mode twice when prompted. 3. Wait for upload progress to reach 98%, then let it reboot about 30 seconds and verify OpenBeken activity. [#20669566]hid_download_py was usually said to work but still failed here with Unprotect Failed, and Cloudcutter completed the flash successfully. If your board shows bus or unprotect errors after basic UART cleanup, Cloudcutter is the fastest practical fallback on Linux. [#20669566]0x1EE000. The extracted data looked sparse, but reading that region still exposed enough information to confirm Pin9 as the status LED and later helped validate the device configuration. [#20705858]Status LED: pin P9, then its device-configuration view revealed JSON fields such as infre: 7, infrr: 8, wfst_pin: 9, and rsthold: 3. Those values let you confirm IR receive, Wi-Fi status, and reset timing even when the full board type is not detected. [#20705858]failed to extract keys, and the user later saw the same extraction problem pattern outside that exact Linux workflow. That made the board data look incomplete or unsupported, rather than proving a simple GUI mistake. [#20705858]IRSEND NEC 0x80 0x12 0. The user confirmed that IRSEND IR_NEC 0x80 0x12 0 failed because the protocol name should be NEC, not IR_NEC. On this board, the command started working after the user fixed that one token, which makes syntax accuracy as important as the correct GPIO pin. [#20705858]0x1EE000, and recover GPIO assignments. In this thread, that path succeeded after repeated UART failures and confirmed working IRReceive and Wi-Fi status pins. [#20669566]