Unable to upload to BW16

Working with the BW16 bought through Seeed, I have managed to erase the factory BW16 firmware using the OTA method.
I now see #calibration_ok:[2:19:11] coming out of Log-Tx when I reset, which I think means I’ve managed to push the BLINK application successfully.

I have checked that my USB uart is working in both directions, and is connected to the LogTx/Rx lines - I was able to control the native BW firmware.
I have managed to get the module into upload mode, in that it is chucking out loads of 0x15 characters at 115,200 bit/s
When I use the ‘Upload’ button in Arduino, I see the ‘countdown’, but then get the messages:
Uploading…error: Enter Uart Download Mode
Image tool closed!
Upload Image done.
I have a 'scope on the Rx and Tx lines, and can see no activity whatsoever coming from the PC.
It looks very much as though the upload tool is not successfully receiving the 0x15 characters, and is therefore not attempting to establish further communication.
I can see that the IDE is running upload_image_tool_windows.exe.
Trying to run that outside the IDE, I have discovered that it spawns amebad_image_tool.exe
Running that with the -v flag (guessed!) I can see that the program is trying to read one character from the UART, but receiving none - even though the 0x15 characters are being repeatedly sent by the platform.
If I separately open the COM port e.g. in Arduino Serial Monitor, I can see the characters coming in.
If I try to use the Arduino Upload button when I have my com port open in another application I see the error change to ‘could not open com port’, proving that the Upload button is trying to use the correct COM port.
Any ideas?

Additional information:
I have now tried with a different brand of USB serial adaptor - was CHS, now Prolific - same result.
Using Wireshark to monitor the USB transactions, if the serial port is opened either with PuTTY or with the Serial Monitor in Arduino, I see the incoming 0x15 characters arriving regularly.
When the serial port is opened by the Image tool, no characters are incoming.
So far as I can see, the Image Tool is not setting up the serial port properly.
The file path for the upload_image_tool_windows.exe is C:\Users\chris\AppData\Local\Arduino15\packages\realtek\tools\ameba_d_tools\1.0.7, and the file date on this executable is 03-Nov-21
The file date on ambad_image_tool.exe (which I think is called by the previous executable) is 16-July-21
I have tried ambad_image_tool.exe from the latest ambd_arduino-dev.zip - no difference.
Is this tool trying to make use of some specific FTDI features?

Hi @boatbodger

can you provide these information on your system:

  1. Windows version
  2. Arduino version
  3. Is this a new install of the board support package for the BW16, or an upgrade from an older version?
  4. Have you previously successfully uploaded an image from Arduino IDE to any of the RTL8720/21/22 boards?

It should not be using any FTDI specific features, since the default CH340 chip on the BW16 is also supported. But the baud rate of 1.5M might be too high for some usb-uart chips.
Here are a few more tests you can do to further isolate the problem:

  1. After compiling in Arduino IDE, go to AppData\Local\Arduino15\packages\realtek\tools\ameba_d_tools\1.0.7, you should see the compiled images km0_boot_all.bin, km4_boot_all.bin and km0_km4_image2.bin. In the same folder, open cmd and run the command upload_image_tool_windows.exe C:\Users\%USERNAME%\AppData\Local\Arduino15\packages\realtek\tools\ameba_d_tools\1.0.7 COMx, replacing the file path and COM port accordingly. This should show the same countdown as the Arduino IDE upload process, and my guess is that this upload would probably fail in the same way.
  2. Copy the compiled images km0_boot_all.bin, km4_boot_all.bin and km0_km4_image2.bin into AppData\Local\Arduino15\packages\realtek\tools\ameba_d_tools\1.0.7\tools\windows\image_tool, open cmd and run the command amebad_image_tool.exe COM3. This should skip the countdown and start uploading the images immediately. From your description, it sounds like this failed as well.
  3. Download the standard SDK image tool from GitHub, select the correct chip and use it to upload the same three images to the default addresses. This should work, and you can use this as a temporary stopgap measure while we try to figure out this issue.

Thank you for your response, and here are my answers:

  1. Windows Version: Windows 10 Home version 21H2, build 19044.1586. The driver showing against the CH340 is provided by wch.cn, version 3.5.2019.1
  2. Arduino version 1.8.19
  3. New install, version 3.1.2 (I tried reverting to 3.1.1 in case the latest was not the best, but no difference)
  4. The only successful upload was an OTA upload of the Blink application. I could not clear the BW firmware any othre way. I have never successfully pushed an upload through the UART

And now the tests you suggest. I first ‘updated’ to version 3.1.2 of the board package i.e. latest, closed Arduino, and started it again. I am now using an rtlduino board, which I have also cleared the flash using OTA, and the LED is blinking green after a reset.

1: I compiled in Arduino IDE, confirm that the three .bin files you mention are there and have today’s date. I set the board into bootloader mode (transmitting 0x15’s at 115,200 bit/s). When I run the command I get the following result:

C:\Users\chris\AppData\Local\Arduino15\packages\realtek\tools\ameba_d_tools\1.0.7>upload_image_tool_windows.exe C:\Users\chris\AppData\Local\Arduino15\packages\realtek\tools\ameba_d_tools\1.0.7 COM20
Please enter the upload mode (wait 5s)
Uploading…error: Enter Uart Download Mode
Image tool closed!
Upload Image done.


2: Copied the three files as suggested, and when I run the requested command I get the following:
C:\Users\chris\AppData\Local\Arduino15\packages\realtek\tools\ameba_d_tools\1.0.7\tools\windows\image_tool>amebad_image_tool.exe COM20
error: Enter Uart Download Mode
Image tool closed!


3: I downloaded just the Image_tool.exe, ran it to see the GUI. The 8720DN chip is not available, but the 8721DN is, so I chose that. I tried first with out entering bootloader mode and get the following result:
COM20 is open successfully!
Uart download server has started…
Err: Flashloader download fail
COM20 is closed successfully!
I then put the board into bootloader mode (pushing out x015’s) and get the same result:
COM20 is open successfully!
Uart download server has started…
Err: Flashloader download fail
COM20 is closed successfully!

On my scope, I can see that the tool is issuing commands on the serial port, but that this instantly kicks the module out of bootloader mode, and the green LED starts blinking again.

I will try to capture a trace and add it to this thread.


Thanks for the info.
Using the GUI image tool, can you try the flash erase feature, erasing at least 2048 KB from the default start address of 0x8000 0000. Afterwards, try using the GUI image tool to upload again.

It is a known issue that some BW16 have the firmware loaded in an OTA slot that causes upload issues in Arduino. Using OTA to overwrite is one solution, and doing a full flash erase is another. This should eliminate the possibility that the existing firmware is causing this issue.

I had tried to use Image_tool.exe to erase the 2048k flash - it seemed to do something, but came back with a failure saying something like “flag register error” - I did not capture the detail.

HOWEVER - I have found a solution.

On Friday when I was starting to get in to this, I had ordered an FTDI usb to serial ttl cable. This has just arrived.

Using this, I find everything works as expected.

So I am very sorry for wasting your time - it seems this was hardware related after all (even though - so far as I could tell, using fairly sophisticated diagnostic techniques, my hardware was good).

Thanks again for your help



I am glad to hear that you have found a solution with the FTDI cable. However, the image upload programs are supposed to work with CH340 chips, so thanks for the issue report anyways.

Now that I can make a ‘reference’ trace (on 'scope and on Wireshark/USB) I will try and find some time to work out what is going wrong in the hope that it may help somebody else. I have lost at least one working day’s worth of time, and its better if others don’t have to!
Thanks again