Browsed by
Tag: programming

Ultimate7e: Building from source

Ultimate7e: Building from source

[UPDATE: 17th May 2016] While the method below can still be used to build from source, PhracturedBlue has release a Docker container that contains the build environment with a GUI to ease the process. Find the wiki documentation about it here.

Alternatively, if you do not want to build from source yourself, compiled versions can be found on the Test Builds page on

Let’s walk through the process of building DeviationTX from source. You’ll need to do this if you have upgraded your Devo7e processor as outlined here. Again you will need to make sure you have installed the items that I listed here.

Setup and clone Git repository

First thing we need to do is to create an account on GitHub. From there we then have the choice to either Fork or Clone the Deviation code. Forking allows us to maintain a copy of the code that we can edit for our own preferences, but we will need to deal with having to do upstream pull requests and potential merge conflicts as the main codebase is updated by the DeviationTX team. In this post we’ll talk about cloning only, which assumes that you are happy to take the default options as setup by the team, or if you make changes, you will need to set those options again the next time you pull the latest commit from GitHub.

Adding the DeviationTX repository.
Adding the DeviationTX repository.

In SourceTree, click on the “New Repository” button and select “Clone from URL”. Fill in “Source URL” with You can also choose to edit the paths and name or just accept the defaults. Once done, click on “Clone” and wait for everything to be copied to the path you specified.

Setup Docker build environment

Using Kitematic to setup the build environment.
Using Kitematic to setup the build environment.

When you installed Docker, it should have also installed their management tool “Kitematic”. Open this up and click on the “New” button then key in “deviation” into the search field. This will bring up the Docker container that Mike (a.k.a mwm) has nicely prepared for us. The one we want is “deviation”. He has other images, but I won’t be talking about them here. To find out more, go to his forum post here.

Click on the “Create” button for the “deviation” container and wait for the image to download and install. You will then have the “deviation” image available on the left hand side menu under “Containers”.

Setup deviation volume path.
Setup deviation volume path.

With the container installed we now need to configure the volume path to the source code that we cloned with Git earlier. Select the “deviation” container and click on “Settings -> Volumes -> Change”, then select the directory that you had cloned the source code into. Once done, hit the “RESTART” icon.

Compiling DeviationTX

Compiling the DeviationTX source code.
Compiling the DeviationTX source code.

After the container has restarted, click on the “DOCKER CLI” button. This will bring up a terminal window that will allow you to access the command line for the deviation container. Type in docker attach deviation and hit the “enter” key twice. You should now be inside the deviation container. Type in make TARGET=devo7e-256 or one of the other targets that you need.

2016-04-17 02.12.09 pm

Wait for it to complete and you will have the DFU file that you need sitting in the src directory ready to be flashed to your transmitter. Note that if you have upgraded your processor in the 7e, you must use the Walkera Dfuse Tool and not Deviation-Uploader.

Updating to the latest commit and recompiling

Pull latest commit of DeviationTX.
Pull latest commit of DeviationTX.

When you wan to update to the latest commits by the team, you will need to first do a pull and merge into your cloned copy. Do this by clicking on “Pull”, select “origin” and “master”. Also check on “Commit merged changes immediately”, then click on “OK”.

Go back into your deviation container on Docker following the previous steps. Run make clean and make distclean before make TARGET=devo7e-256.

Hope you’re having fun!

Ultimate7e: Flashing the bootloader

Ultimate7e: Flashing the bootloader

We’ve now got a nice new processor installed in our 7e and we need to flash a boot loader onto it. The bootloader we need is the 256K variant that PhracturedBlue has so nicely modified for us. It is based on the original stock Walkera bootloader, but allows for files larger than 128K to be uploaded. You can find it from the links that I put in the “DeviationTX: Build environment and tools” post. I’ll assume that you’ve also already acquired and installed the other items from the post. You’ll want to download the file named “devo7ebootloader_256.bin”.


There are 3 sets of pads on the main board that we are interested in:

Programming Header: Connects to our ST-Link programmer. We’ll use the right 4 pins (ignore the RST pin) which are SDIO, CLK, GND, and VCC(VDD).

BOOT0: BOOT0 needs to be shorted together on power up.

Power Switch Bypass: If your ST-Link programmer does not provide power, you will need to have your battery hooked up and the bypass pins need to be shorted together to power up. Alternatively you can also reach around and turn on the power switch.

ST-LINKv2 Programmer (Clone)
ST-LINKv2 Programmer (Clone)

On our ST-Link programmer, we will want to use the SWD port and the pins that we will want to use are 3V3, CLK, GND, and IO(SDIO).


ST-Link wired to the Devo7e main board
ST-Link wired to the Devo7e main board

Everything is wired up. Notice the jumper I put on the BOOT0 pin. Please check and recheck that pins are connected properly and in the right order. Especially the power (VCC/VDD/3V3) and ground. Most mistakes that kill the board happens because of wiring error. Don’t plug the USB end to your computer yet.

ST-Link Utility needs to be "Run as administrator"
ST-Link Utility needs to be “Run as administrator”

Start up the ST-Link Utility programme on your computer. You will need to right click on it and have it “Run as administrator”. When Windows prompts you for permission, remember to click on “Yes”.

ST-Link Utility running and connected to Devo7e
ST-Link Utility running and connected to Devo7e

Once the programme is running, go ahead and connect the ST-Link programmer to your computer. We will now try to connect by going to the menu and clicking on “Target -> Connect” or clicking on the 3rd icon from the left that looks like a power plug. Make sure that the connection is successful, if not recheck your wiring.

2016-04-17 04.13.08 am

Once you have successfully connected, do the following:

  1. Click on “Target -> Erase Chip” or the 5th icon from the left. Select “Yes” when it asks if you want to continue.
  2. Click on “File -> Open file” and select the “devo7ebootloader_256.bin” bootloader file that you should already have downloaded to a local drive.
  3. Click on “Target -> Program & Verify”.
  4. Make sure that “Start address” is set to “0x08000000” and select either of the verification modes (both work fine).
  5. Click “Start” button.

2016-04-17 04.15.47 am

Once it is done, check you status window to see that everything went well. If it did, select “Target -> Disconnect” or the 4th icon from the left. Disconnect the wiring, remove the BOOT0 jumper and reassemble your radio.

Congratulations! You have just successfully upgraded your processor and are now ready to install DeviationTX with the Walkera Dfuse tool!


ESC reflash with SimonK firmware

ESC reflash with SimonK firmware


I hadn’t gotten around to modifying the internals of my TX so I figured I’d have a go at reflashing the Hobby King 20A (F-20A) ESCs first. I chose this ESC because:

  • They were really cheap
  • They supported reflashing with SimonK’s firmware
  • They had their test pads in a row so it would be easier
  • All it’s FETs were the same (N-Channel)

Some wiring had to be done to match the pin-outs from my 10 pin AVR programmer to the test pads on the ESC. I found the information that I needed over at this RC Groups thread. I also read the instructions found here at openpilot.

As for the firmware we can find it on github along with more useful instructions. I suggest you read all of it and refer to this spreadsheet for your particular ESC.


I wanted to test this really quickly so I just slapped some wiring together with a breadboard to get everything hooked up.


The test pads are in the following order: MOSI, MISO, SCK, -, +, RESET (from bottom to top). I took the time to tin the wire, that I took from an old IDE cable, to make sure I had good contact and no stray wires crossing pads. I then lined it up and held it in place with some scotch tape so that I didn’t have to keep holding it there. The tape doesn’t really maintain the contact so prior to programming I would still need to use my finger to press down, it just keeps me from fumbling around.

With the wiring done, I plugged the AVR programmer into the USB port and fired up AVRFuses.


I set the device to “ATmega8″ which is the microcontroller found on this ESC, and probably most other ESCs compatible with the SimonK firmware. I also pointed the hex file to the firmware file that I had downloaded for my ESC. Then I took a deep breath, pressed my finger to the wire on the ESC and clicked on program. A few seconds later… “SUCCESS”.

I unhooked the ESC and reconnected it to a battery, servo tester and motor. Upon doing this I heard 3 beeps followed by a 4th telling me that everything was good. A few twists on the servo tester and the motor was spooling like a dream.

The flashing instructions make mention of the fuses on the ESC. We do not need to do this and can leave it stock.


In case something was changed accidentally (and you still have access to the ATmega) here are the default fuse settings as seen by AVRFuses.

I, on the other hand, somehow managed to mess things up and bricked 1 of my 4 ESCs during the process. Not too bad for my first time doing this, but now I had to go order another ESC. I’ll probably buy a few as spare.

Atmel AVR programming on OS X

Atmel AVR programming on OS X

I finally received the AVR USBASP programmer that I ordered on today. I’ve been waiting for this so that I could start tinker with reflashing of ESCs and the Turnigy 9x that I had recently bought. I choose this one cause it had some built in protection (diodes) added.


It was also voltage selectable (3.3V and 5V) via adding or removing a 0ohm resistor. I plan on replacing the resistor with headers and a jumper later. It comes default as 5V which works for me, so I’ll leave it for now.

I run OS X, and most guides for things related to R/C are written for windows. I basically looked for the equivalent Mac based tools as described by the Windows based guides. I knew that I could do this cause there is nothing platform specific when it comes to working with the Atmel microcontrollers (the atmega8a that controls our ESC).

I chose to use CrossPack, by Objective Development Software, to provide me with the toolchain for working with the Atmel microcontrollers. And while I’m pretty comfortable with the OS X command line (many years of Linux), I figured that I wanted to be lazy and have a GUI interface. Thus I also chose to install AVRFuses, by Jason von Nieda, as the GUI that would hook into avrdude (comes with CrossPack and is the actual program that will flash the firmware to the ESC).

At the time of writing this, the versions that I used are (on OS X 10.7.4):

  • CrossPack-AVR-20120217.dmg

Installation is a piece of cake so I won’t go into that. I will however talk a bit about configuring AVRFuses so that it can talk to the AVR Programmer through avrdude.


After installing both pieces of software, open up AVRFuses and go to it’s preference pane. Here we will need to define “Path to avrdude” and if you read the readme file that came with CrossPack, you would know that it installs by default to “/usr/local/CrossPack-AVR-20120217/” and the full path to avrdude is “/usr/local/CrossPack-AVR-20120217/bin/avrdude”.

The programmer that I bought was USBASP so I selected “usbasp” (obviously), You may need to select a different option depending on your programmer. The port should again be selected based on the hardware programmer that you are using, and it is pretty safe to leave the baud rate at “[Default]“.

There has not been an update to AVRFuses since 2008, but I wanted to leave the option checked in case Jason decides to do something someday. I also left “Show avrdude Command Lines” so that I could monitor what was going on Click on “Close” and if everything is good you will see a nice green “SUCCESS” in the output console.

Now we can get ready to reflash the TX and some ESCs. I’ll write about those later on.