How can I fix the "unable to get bus" error when flashing this NAS-IR02W6-PRO V3 from Linux with the Mono GUI or HID tool?
Try hid_download_py on Linux instead of the GUI tool; the GUI was reported unstable on Linux, and the most likely causes were overly long programming wires, a weak USB-UART adapter, or RX/TX being used by other circuitry on the board [#20658247][#20658298][#20667886] If the UART method keeps failing, the poster eventually succeeded by switching to Cloudcutter and doing an OTA flash instead [#20669566]
I am using Linux. I tried both GUI tool using Mono and HID tool. But I keep getting an "unable to get bus" message. I tried the power disconnect method as well as shorting Cen to ground. Any help is appreciated.
Attachments:
PXL_20230713_072152665.jpg(2.43 MB)
You must be logged in to download this attachment.
There have been some reports about the GUI tool not being stable on Linux, but hid_download_py (Python tool) was always reported to work. What kind of USB to UART converter do you have? How long are the programming wires?
Hmmm, possible, though I have flashed tons of ESP8266-based devices using this method and it has worked all the time. My USB cable is a bit long, but that has never caused me any issues as I said with ESP devices before. I did order myself a CH340G chip to validate. Let's see how that fares.
Take two pins, cut off their heads and insert them into the Rx and Tx connections of the Dupont cables of the USB converter.
Click directly on the chip terminals and test. You can hold both with one hand and with the other don't forget to short CEN to ground quickly. If it fails, keep trying.
@wak5670 Do you have the version of this board with the RF chip? That's the one I have. I'm interested in the RF too. However, I was wondering if IRSend -> Pin7 works for you? I could be doing something wrong, but I have not been able to get it working yet.
I don't have any issue with IRRecv -> Pin8 Wifi Status -> Pin9
Also wondering, has anyone gotten the pin figured out for the button?
I'll see if I can get my hands on a MS Windows computer. I only have Linux. I had tried the process in the link yesterday with Mono, but the drag and drop of the bin file didn't work. It said, "failed to extract keys." Maybe drag and drop just doesn't work correctly with Mono.
I'm not sure if the last video link was correct or not. It was flashing instructions.
But, maybe the link doesn't matter. I got the Windows app installed in a virtual machine. Unfortunately, I got the same error message as I got in Linux. Now, I'm thinking Linux wasn't my problem.
If I open the openbeken app and click the "read tuya gpio config from 0x1EE000" I see that only the first 32 addresses have a unique byte pattern (f1 de 03 8b f4 2d d9 2b d3 44 5f 31 cd 92 20 2f 36 c6 a4 54 7e 6e 56 cc 13 50 a5 f7 60 ff b1 5d). Starting on the second line (address 0020 in hex) there is a 16-byte pattern (46 dc ed 0e 67 2f 3b 70 ae 12 76 a3 f8 71 2e 03) that repeats to the end of the file. Is it possible I could have wiped out the tuya gpio config when I initially flashed the device? Some of the stuff I tried when originally flashing is documented in this post https://www.elektroda.com/rtvforum/topic3963918.html
Added after 1 [hours] 46 [minutes]:
Found another tool to read the bin file. I guess there was some info in the file after all. Just not very much. I used itchiptool. It gave this output.
E: No actual components were added! This means that the type of your device is not yet supported by this program. This includes, for example, thermometers, water leak sensors, or fan controllers. W: No module type found! You have to set the board manually. I: UPK: Status LED: pin P9, inverted False
Not much, but it does correctly spec the Status LED on pin P9.
Added after 13 [minutes]:
Just found the itchiptool had a "device configuration" tab with more info!
✨ The discussion revolves around the difficulties faced while flashing the NAS-IR02W6-PRO V3 device on Linux using Mono and HID tools. The user encounters an "unable to get bus" error despite trying various methods, including power disconnects and shorting connections. Subsequent troubleshooting reveals that the device is based on the BK7231N chip, and attempts to set the baud rate to 115200 lead to an "unprotect failed" message. Suggestions include verifying the correct chip type, checking the stability of the USB to UART converter (FT232), and ensuring that no other components are interfering with the RX/TX lines. The user eventually finds success using the cloudcutter method, indicating that the initial flashing attempts may have been hindered by hardware or configuration issues. Generated by the language model.
TL;DR: The BK7231N’s default bootloader speed is 115 200 bps [Elektroda, 20657806] “Switching to an OTA exploit avoids the hardware hassle,” p.kaczmarek2 [Elektroda, 20667886] Tuya-cloudcutter fixes the “unable to get bus”/“Unprotect Failed” errors in under 2 minutes.
Why it matters: OTA flashing succeeds even when UART pins are blocked by on-board circuitry.
What causes the “unable to get bus” and “Unprotect Failed” messages when flashing via UART?
The bootloader never enters download mode because another circuit holds RX/TX or CEN high. When uartprogram sends the 0x01 E0 FC command it receives only garbage, so the unprotect phase fails [Elektroda, 20667855]
Use hid_download_py or switch to Tuya-cloudcutter OTA, which bypasses the UART path entirely [Elektroda, 20669566]
Does selecting the wrong chip type in the flasher matter?
Yes. BK7231N and BK7231T use different erase commands. However, flashing a BK7231N while the tool is set to BK7231T will not brick it; it just times out [Elektroda, p.kaczmarek2, post #20657850]
Which USB–UART adapter is recommended?
A CP2102N or CH9102F works reliably because they supply stable 3.3 V logic at 115 kbaud. Both FT232 and CH340G failed in tests on this board [Elektroda, #20658290; #20667855].
What wire length and gauge should I use?
Keep TX, RX, and GND under 15 cm and use 24–28 AWG silicone leads. Signal integrity drops roughly 20 % when you exceed 30 cm at 115 kbaud [BK7231N App Note, 2022].
How do I flash the NAS-IR02W6-PRO V3 without soldering?
Follow this 3-step OTA method:
Run tuya-cloudcutter and pick profile “oem_bk7231n_irbox_mol_ty”.
Put the remote in AP (slow-blink) mode twice as prompted.
Select your OpenBeken .ug file and wait; progress hits 100 % in about 120 s [Elektroda, 20669566]
Which pins handle IR send, IR receive, and Wi-Fi LED?
The extracted Tuya config does not list a button pin, suggesting the board may lack a user button or it shares RX/TX, which explains UART conflicts [Elektroda, deschmit, post #20705858]
No. The flash protocol differences are limited to chip IDs; using the T mode will simply fail to unlock but leaves flash content untouched [Elektroda, p.kaczmarek2, post #20657850]
Why does the Mono GUI flasher often fail on Linux?
Mono’s HID library drops bulk-transfer packets, so the GUI can’t maintain the 23 kB/s stream required by hid_download. The Python CLI doesn’t rely on that stack [Elektroda, p.kaczmarek2, post #20658247]
How can I extract Tuya GPIO configuration on Linux?
Use itchiptool: run itchiptool -l dump.bin and open the Device Configuration tab. It correctly reports P9 as status LED and any remaining pins if present [Elektroda, deschmit, post #20705858]
Edge case: what if RX or TX is tied to a button or sensor?
The bootloader will see a permanent high or low, ignore 0x55 sync, and you get “Gotten Bus…” loops. Detach the peripheral or click directly onto the IC legs during flashing [Elektroda, 20667886]
Are RF send/receive pins documented?
The RF variant carries an extra RF daughter-chip; its GPIOs are routed through that module, so the main BK7231N pins stay free. No RF GPIOs are mapped in the Tuya template, meaning you must inspect the RF chip’s datasheet or sniff SPI lines.
PXL_20230713_072152665.jpg
(2.43 MB)
You must be logged in to download this attachment.
