How to fix a bricked DVR module on Aomway Commander V1
I was a happy user of these nice goggles until one day I’ve noticed that the DVR module cannot be activated using the button, nor I was able to enter the DVR menu. Recording function just seemed completely gone. However, I was trying to upgrade the DVR firmware a few days before and so it was a rightful assumption that something has gone wrong in the process and it was the reason it doesn’t work. The funny thing is that I wanted to upgrade just to have the audio on/off option in the menu, but I wasn’t really needing it as I either have a mic on the VTX or just strip the audio channel from the recording if static noise is annoying. I didn’t need it, only wanted to have it and thus bricked the device. But at this point it wasn’t possible to redo the upgrade using the SD card and easily fix the problem, so I was looking for another way to revive the device. By looking at the firmware binary I’ve found that the design of Chinese-made DVR devices must be very similar to each other. The first clue telling me that they are and that the firmware can be written directly onto the flash chip was Kolin’s post on RC Groups and later I’ve found a post on Montis’s blog titled “Restoring bricked Eachine ProDVR after firmware update”. I discovered this information by googling for strings I’ve seen in the firmware file named CRESFW.BIN. As it turned out, the firmware for some other Chinese DVR devices is also distributed with the same filename and contains same character sequences.
In the end, I’ve learned how to read and write a flash chip directly!
So the good news is that the DVR on the Commander can be fixed after a failed upgrade attempt. The bad news is — well, not really that bad, since if you are in the RC hobby for a while, you must be used to tinkering with electronics and stuff — you have to take the goggles apart and prepare to solder jumper wires on the legs of the flash chip.
Things you will need:
- soldering iron with a relatively small tip (I used a TS100)
- thin jumper wires (I used these with dupont connectors)
- flashrom utility program for reading/writing the chip
- one of the programmer devices listed on flashrom’s site
- the stock firmware kindly provided by Aomway (you will need the .BIN file from the zip, it is 2097152 bytes long and the firmware from the official site or any other of different size will not work [see the end of this article for some details]!)
- I assume you know how to solder and have basic tools like solder, solder paste, pliers, screw driver set and multimeter
My choice for the programmer was the Raspberry Pi because I have one lying around and so it was obvious. Using the Pi is so convenient as it can run Linux and doing advanced things are just tend to be easier when using an advanced OS.
The repair process
The first step is opening a nice cold beer. It helps doing things that require precision more calmly.
Next we have to take the goggles apart. This must be obvious. Remove the foam on the face plate and unscrew the little screw at the nose. Remove the face plate. There are two more screws left on the bottom of the goggles. Pull apart the top and bottom pieces gently as there are ribbon cables inside.
Now you need to identify the flash chip. It is located on the top PCB where the top buttons are. It has eight legs and the inscription Winbond 25Q16CVNIG. Here’s a photo of it:
To know the exact type of the chip is required in order to find its datasheet with the description of the functionality of the legs (this excerpt from the datasheet can be seen below).
At this point we need to prepare the Raspberry and connect it to the chip. Installing flashrom on a Debian-based Linux distro is as easy as issuing the following command:
sudo apt-get install flashrom -y
In case you are using another operating system, please consult flashrom’s documentation on how to get the executable installed on your system. The point is to get the
flashrom command working on the command-line.
The way the Pi has to be connected to the chip is described in flashrom’s documentation. There you can find a connection table that shows which GPIO pin on the Pi goes to which leg on the Winbond chip. It is very important to power the chip from 3.3V input (as it is correctly shown in the documentation), because overloading the chip can easily kill it! Fortunately the Pi provides a very stable regulated 3.3V output which makes this very convenient. If you were to use an Arduino for flashing you might need additional components (like a resistor) to achieve the correct output voltage.
The image below contains all the information necessary for making the connections between the chip and the Pi. It doesn’t include lines representing the wires as I was only merging images together quickly, but the things you need to know are there. The only thing I did differently was not connecting /HOLD and /WP to VCC. This is because I couldn’t get flashrom to detect the chip that way. In some cases it is also possible that the chip has to be separated from the rest of the PCB during the flashing process by either completely removing it from the board or disconnecting its VCC leg. In my case none of this was necessary.
Note the dot both on the chip and the diagram which is for determining correct orientation. This is how all of the above looks like in real life:
This may sound silly, but do not have any device powered while you’re soldering to it!
After you have done with the soldering, it is always a good idea to make sure there are no shorts using a multimeter in continuity mode. Since the legs of the chip are relatively small (though not as small as on many other IC’s, by the way) it may be that you accidentaly connect some of them together, with a too big blob of solder for instance.
If everything seems okay, you can power the Raspberry. Remember not to power the goggles from its own power during the flashing process! Use only the 3.3V from the Pi to power the circuit!
When the Pi has booted, the connection can be tested. Open a terminal, type
flashrom -p linux_spi:dev=/dev/spidev0.0 and hit enter. The flashrom utility will now try to detect the type of the chip the programmer device is connected to. A similar output is expected:
flashrom v0.9.9-r1954 on Linux 4.9.41-v7+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org
Calibrating delay loop... OK.
Found Winbond flash chip "W25Q16.V" (2048 kB, SPI) on linux_spi.
No operations were specified.
If you get an error message stating “No EEPROM/flash device found.” then you need to double check your wiring and read the documentation related to your programmer of choice on flashrom’s website. This guide isn’t about meta-troubleshooting, it’s only a description of how I fixed my unit and what I’ve learned along the way.
In theory, if the current firmware on the chip was working and you wanted to change it for some other reason (for example to do an upgrade in a more complicated way), it’d be a good idea to make a backup of the chip’s content before writing to it. Of course in the current case the firmware is bricked, but out of pure curiosity you can backup the firmware by issuing this command:
flashrom -p linux_spi:dev=/dev/spidev0.0 -c W25Q16.V -r backup.bin
This would save the chip’s content to a file named backup.bin.
Now we can attempt to write the right firmware on the chip. To do this properly, the firmware binary has to be exactly 2097152 bytes in size (this is the capacity of the Winbond chip). The firmware file linked in the Introduction of this article is correct. To write the binary onto the chip use the following command:
flashrom -p linux_spi:dev=/dev/spidev0.0 -c W25Q16.V -w MB01.BIN
In the above
MB01.BIN is the firmware binary you’ve downloaded, I just renamed it for convenience.
The process should complete successfully. Now you can test your goggles without disconnecting everything, just shutdown the Raspberry and unplug its power cable, then power the goggles normally using the barrel connector. You should be able to activate DVR recording and enter the DVR menu. There will be a new option in the DVR menu to turn audio on and off. At this point you can assemble your goggles and you’re done.
Why you can’t just use the upgrade firmware
Normally, a firmware image must be of the same size as the capacity of the chip it is written to. By default, flashrom will complain if it is not, for eg.:
Error: Image size (1275738 B) doesn't match the flash chip's size (2097152 B)!
The capacity of the W26Q16.V chip is 2 Mb (or 16 Mbits). If you look at the size of the binary you can download from aomway.com you can see it is only 1.3 Mb. I presume the reason behind this is that the normal upgrade process employs some kind of patching and only parts of the chip are written. Whether the binary is written as is with a certain offset or sliced to parts and different parts are written to different offsets, is not known. By examining the chip backup I’ve made, I discovered that the binary on the chip contains a 64 bytes header which the upgrade binary does not and this supports my assumption about patching. Moreover, I tried to merge the upgrade binary into the backup binary starting after this header, but flashing the merged file didn’t make the device work. This tells me that the patching process could be more complicated, but again, the exact patching method is not known. At least I’m not skillful enough to read machine code and figure it out.
The point is you cannot just write the upgrade firmware on the chip, because it will not work. The binary you need is the complete firmware image of a working pair of googles. I acquired this binary by contacting Sean at Aomway and I’m really grateful that I was sent the file I was asking for within a single day or so!
The moral of the story is…
It’s not always a great idea to upgrade software if everything works and you don’t need the new features either.
I want to say thank you for these generous people for being so helpful and kindly sharing their knowledge with me! This made it possible for me to learn how to do chip flashing from zero to finally fixing my device in a single day!