User Tools

Site Tools


product:usb2ax:firmware_update

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
product:usb2ax:firmware_update [2014/01/18 17:37]
xevel
product:usb2ax:firmware_update [2017/11/15 02:53] (current)
xevel
Line 5: Line 5:
 ==== Getting the firmware ==== ==== Getting the firmware ====
  
-The latest official firmware binary can be found on the [[firmware|firmware page]].+The latest official firmware binary can be found on the [[firmware|firmware page]].\\ 
 +Also, take the time to **check if you actually need to upgrade** or if you already have the latest one, the info is on the same page.
  
 ==== Updating the firmware ==== ==== Updating the firmware ====
  
-You have a new firmware and you want to put it in the USB2AX, ​Great!+You have a new firmware and you want to put it in the USB2AX, ​great!
 There are three ways to do it: There are three ways to do it:
-  
  
-  * [[#Automatic]] - for normal firmware update, with minimal user action. +  * [[#Regular]] - for normal firmware update, with minimal user action. 
-  * [[#​Recovery]] - for when something went wrong with the Automatic ​mode, or for custom firmwares. Requires actions on the board.+  * [[#​Recovery]] - for when something went wrong with the Regular ​mode, or for custom firmwares. Requires actions on the board.
   * [[#ICSP]] - for geeks.   * [[#ICSP]] - for geeks.
  
-  +=== Regular ​===
-=== Automatic ​===+
  
-For most people, the Automatic ​procedure will work nicely. +For most people, the Regular ​procedure will work nicely. It is supported by the firmwares made by Xevelabs.
-It is supported by the firmwares made by Xevelabs, and relied upon by the automatic firmware update tool.+
  
-This update method is supported both for Windows and Linux.+This update method is supported both for [[#Windows ​version|Windows]] ​and [[#Linux version|Linux]]. 
 + 
 +=== Regular : Windows version ===
  
-**Windows version**\\ 
 //Tested on Win7 64bits.//\\ //Tested on Win7 64bits.//\\
-Prerequisites:​ 
-  * Installing Atmel FLIP 
-  * Getting the USB2AX_Update application 
-  * ...  
  
-FIXME +Get the [[http://​xevelabs.com/​usb2ax/​USB2AX_Updater_Win_v1.1.zip| USB2AX_updater tool]] (updated Nov 2017).
- +
  
-**Linux Version**\\ +  ​Run //usb2ax_updater.exe//.
-//Tested on Ubuntu 10.10 32bits.//+
  
-1) Install dfu-programmer >=0.5.4+{{ :​product:​usb2ax:​usb2ax_updater.jpg?nolink |}}
  
-Debian Squeeze only has 0.5.1so you might have to build it from sources:+  * Select the appropriate COM port and click "Run Bootloader"​. 
 +  * If it's the first time you do it, the [[USB2AX]] will re-enumerate as //​ATmega32u2 DFU//Cancel the online search for driverand manually install the driver from the //​dfu-prog-usb-1.2.2//​ folder. 
 +  * Select the new firmware that you want to upload (without spaces in the path!), and click "​Program USB2AX"​. 
 +  * Done!
  
-<code bash> 
-apt-get install libusb-dev 
-#download and uncompress dfu-programmer 
-cd dfu-programmer-<​version>​ 
-./configure 
-make 
-</​code>​ 
  
-The binary is in ./src+=== Regular : Linux Version === 
 + 
 +1) Install dfu-programmer >=0.5.4
  
 //Maybe add the user to the uucp group so you don't have to run dfu-programmer as root... but it did not work for me.// //Maybe add the user to the uucp group so you don't have to run dfu-programmer as root... but it did not work for me.//
  
-2) Run the bootloader using the python script. ​FIXME+2) Run the bootloader using the python script: [[https://​raw.github.com/​Xevel/​usb2ax/​master/​firmware/​lufa_usb2ax/​usb2ax_run_bootload.py|usb2ax_run_bootload.py]]
  
-3) Run the programmer :+Edit it to change the tty port accordingly. It requires Python 2.7 and PySerial. 
 + 
 +3) Run the programmer ​(replace //​USB2AX.hex//​ by the actual name of the new firmware):
  
 <code bash> <code bash>
-./dfu-programmer atmega32u2 erase +dfu-programmer atmega32u2 erase 
-./dfu-programmer atmega32u2 flash USB2AX.hex +dfu-programmer atmega32u2 flash USB2AX.hex 
-#/!\: the .hex needs to have UNIX-style end of lines (\n, LF), and will not work with DOS end of lines (\r\n CRLF)! +#/!\: with some versions of dfu-programmer, ​the .hex needed ​to have UNIX-style end of lines (\n, LF) instead of DOS end of lines (\r\n CRLF)! 
-./dfu-programmer atmega32u2 start+dfu-programmer atmega32u2 start
 </​code> ​ </​code> ​
  
-== More info for power users ==+4) Done! 
 + 
 +=== More info for power users ===
  
-  * Running the bootloader on the USB2AX is as simple as sending on its serial port the following ascii bytes: 0xff 0xff 0xfd 0x02 0x08 0xf8 +  * Running the bootloader on the USB2AX is as simple as sending on its serial port the following ascii bytes: 0xff 0xff 0xfd 0x02 0x08 0xf8 ([[https://​github.com/​Xevel/​usb2ax/​blob/​master/​firmware/​lufa_usb2ax/​usb2ax_run_bootload.py|Python example]]). Upgrading from version v04 to a newer revision, a second simplified way to do it has been added: open the port at 1200bps, enable DTR, then disable DTR and close the port quickly. ​
-Here is an example in Python, the latest revision of which you can be found in the git repository ​(usb2ax_run_bootload.py ​FIXME )+
-<code python>​ +
-import serial +
-bootload_cmd = '​\xff\xff\xfd\x02\x08\xf8'​ +
-ser = serial.Serial("​COM7"​) +
-ser.write(bootload_cmd) +
-ser.close() +
-</​code>​+
  
   * For commands aimed at the USB2AX, time between two bytes must not exceed 2ms. However, for commands sent to the servos, the maximum byte to byte time acceptable is of 100ms (see http://​support.robotis.com/​en/​product/​dynamixel/​dxl_communication.htm ).   * For commands aimed at the USB2AX, time between two bytes must not exceed 2ms. However, for commands sent to the servos, the maximum byte to byte time acceptable is of 100ms (see http://​support.robotis.com/​en/​product/​dynamixel/​dxl_communication.htm ).
Line 85: Line 72:
 === Recovery === === Recovery ===
  
-The Recovery mode is mostly there as a fail-safe: if something goes horribly wrong with the [[#Automatic]] way or if you want to use a third party firmware, you can always get back to a working state without an additional programmer.+The Recovery mode is mostly there as a fail-safe: if something goes horribly wrong with the [[#Regular]] way or if you want to use a third party firmware, you can always get back to a working state without an additional programmer.
  
-Doing that is a two step process: running the bootloader, then uploading the firmware into the flash memory. Only the first part is detailed here since the second is the same as in the [[#Automatic]] way.+Doing that is a two step process: running the bootloader, then uploading the firmware into the flash memory. Only the first part is detailed here since the second is the same as in the [[#Regular]] way.
  
 **Please be aware that attempting these is done at your own risks!** **Please be aware that attempting these is done at your own risks!**
Line 102: Line 89:
  
   * with a button and a capacitor (requires soldering)   * with a button and a capacitor (requires soldering)
-Solder a small capacitor (in the uF range) between GND and HWB, and a button between GND and RST. When you press the button for a second or two, this will discharge the capacitor, and when you release the button, it will keep the voltage on HWB low enough for long enough for the bootloader to run.+Solder a small capacitor (in the uF range) between GND and HWB, and a button between GND and RST. When you press the button for a second or two, this will discharge the capacitor, and when you release the button, it should ​keep the voltage on HWB low enough for long enough for the bootloader to run.
  
-  * with tweezers or a cable +  * with tweezers or a piece of wire 
-Take a pair of metallic fine tweezers or a cable with stripped ends, touch one end on the GND pad and the other one successively on HWB (leave it for a second) and RST (just touch it). You will get better results if you switch from one to the other very quickly. If you are lucky, the stray capacitance of the HWB trace maintains it low enough for long enough for the bootloader to run.+Take a pair of metallic fine tweezers or a piece of wire with stripped ends, touch one end on the GND pad and the other one successively on HWB (leave it for a second) and RST (just touch it). You will get better results if you switch from one to the other very quickly. If you are lucky, the stray capacitance of the HWB trace maintains it low enough for long enough for the bootloader to run.
  
  
 === ICSP === === ICSP ===
  
-The ICSP method allows you to change the bootloader or do away with it to use the remaining 4k of FLASH, but requires an ICSP programmer and some soldering.+The ICSP method allows you to change the bootloader or do away with it to use the full 32k of FLASH, but requires an ICSP programmer and some soldering.
  
-To connect the ICSP to the board, the necessary pads are broken out on the bottom. You will need to remove the clear protection around the board, then connect:+To connect the ICSP to the board, the necessary pads are broken out on the bottom ​side. You will need to remove the clear protection around the board, then connect:
  
 //ICSP pin number <-> pin functionality <-> place to get it on the USB2AX// //ICSP pin number <-> pin functionality <-> place to get it on the USB2AX//
Line 126: Line 113:
 ==== Customizing the firmware ==== ==== Customizing the firmware ====
  
-The sources of the firmware are available in [[https://paranoidstudio.assembla.com/code/​paranoidstudio/​git/​nodes/​master/usb2ax/soft|the Git Repository]] of the project.+The sources of the firmware are available in [[https://github.com/Xevel/​usb2ax/​|the Git Repository]] of the project.
  
 Read the README file to get an idea of what is going on, read the code, and start hacking away! Read the README file to get an idea of what is going on, read the code, and start hacking away!
product/usb2ax/firmware_update.1390063047.txt.gz · Last modified: 2014/01/18 17:37 by xevel