Unable to Get Bus Message: Flashing NAS-IR02W6-PRO V3 on Linux Using Mono and HID Tool

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.

Hello, can you provide a more detailed photo of the device? Are TX/RX lines used in any way in this device, maybe for a button or for TuyaMCU?

Here are the photos

I am not sure if rx/tx lines are used in any way.

Added after 1 [minutes]:

I actually was able to go further with Hid tool by setting baudrate to 115200, but now unprotect fails. So again got stuck

Hello, is it BK7231N or BK7231T? Are you choosing the proper chip type in the dropdown list?

It is BK7321N, I did select the right chip type in the drop-down.

Added after 6 [minutes]:

This is the output from the HID tool.

❯ python uartprogram ~/Downloads/OpenBK7231N_QIO_1.17.181.bin -b 115200 -u -d /dev/ttyUSB0 -w --startaddr 0x0
UartDownloader....
program....
Unprotect Failed: | |[ ?k/s]

Really? Can you try the BK7231T mode, just to be sure?

BK7231T mode used on N will not brick the chip.

Tried that, I got the same error message, unable to set baudrate.

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?

I am using FT232, wires are normal breadboard jumper cables.

The wires may be too long.

Or there is something on the board connected to RX or TX pin, like a button, a resistor, a sensor.

Or a bad (or should I say, not enough stable) FT232.

Have you successfully flashed other devices that way?

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.

Well CH340G also produced the same results. Running out of ideas here.

Added after 11 [minutes]:

Here is a sample output from uartprogram with some debug information

The RX or TX line may be used for some other purpose, for example, for a button and it may interfere with flashing.

See our Qiachip video, we had a similar situation there: https://www.youtube.com/watch?v=PKkiqDNFIx8

Hi,

Locate pins 26 and 27 of the BK7231N.



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.

Greetings

Oh well, Went down cloudcutter route and success!!!!

For posterity here's what I did.



after this OTA upgraded to latest. IRSend -> Pin7 IRRecv -> Pin8 Wifi Status -> Pin9
Tested everything worked
???
Profit!

Any idea which pins correspond to RF send/recv?

Maybe doing Tuya extraction via OpenBeken can help:

@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?

Please do the template extraction from link above and we can check if there is a button pin specified in the JSON.

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.

This method works on Linux:

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!

{
"crc": 88,
"infre": 7,
"infrr": 8,
"netnc": 0,
"netyc": 1,
"owm": 0,
"rf_study_feq": 0,
"rsthold": 3,
"wfst_lv": 1,
"wfst_pin": 9
}

Figured out my IRSEND problem too. I incorrectly had "IR_" in front of the protocol.
IRSEND NEC 0x80 0x12 0
not
IRSEND IR_NEC 0x80 0x12 0