Conclusions References

This is a re-design of the popular avrusb500 programmer. The second version of avrusb500: avrusb500v2. When I started to develop the original avrusb500 during spring 2005 I had a modern programmer in mind. It should have a USB interface but have no "chicken and egg problem". That is: you should be able to build it from scratch without the need of another programmer to load the initial firmware. It should also be device independent. That is: should be possible to program Content: What is stk500 version 2? How to use this USB AVR programmer Solving the chicken and egg problem The hardware The avrusb500v2 software Soldering SMD chips Testing the hardware The bridge connector (CONN6) BitBang loading of the final firmware Using the USB AVR programmer Conclusions References By Guido Socher current and future AVR microcontrollers without the need to modify the programmer for every new chip. The result was avrusb500. The new avrusb500v2 has all the functionallity of the previous version and contains a number of new features based on suggestions from readers and customers: The led indicates now if the programmer is correctly connected to the target. This is a very useful feature as it is often not so obvious which way round the connector should fit onto the target board. A 1MHz emergency clock signal is provided. This can be used to recover a chip which was accidentally programmed with the wrong fuses. Explanation: Atmel calls their configuration bits "Fuses". They have however nothing in common with traditional fuses. They are bit patterns which can be used to configure the startup behavior of the microcontroller similar to the BIOS in a PC. They can be modified as needed at any time (they don’t burn like a real fuse) but within limits: If you accidentally program the AVR fuses for an external crystal but the hardware does not have such a crystal or the wrong crystal type then your hardware will be "dead". It is possible to recover such "dead" hardware by connecting the 1MHz clock output to the XTAL1 pin of the AVR and then re-program the fuses to the correct value. The firmware for avrusb500v2 is again open source and programmed in C. A link to the older (version 1) avrusb500 can be found at the end of this article. The avrusb500v2 is available as a kit from the online shop: http://shop.tuxgraphics.org _________________ _________________ _________________ What is stk500 version 2? Until not so long ago many programmers had specific knowledge about the possible target micrcocontrollers burned into the programmer. stk500 is a development board from atmel but it works also as programmer and the communication protocol between your PC and that programmer is therefore often called just stk500. stk500 version 1 was such a device dependent protocol. It needed updates for every new programmer that came out. At last Atmel had a good idea and developed a protocol which had some more generic procedures. This was then called stk500 version 2 and the exact specification is AVR068. There is also a more recent variant called AVR069. The stk500 AVR068 specification needs no longer device dependent data structures in the programmer hardware. All device dependent logic is now in the programmer software running on the PC. As of today avrstudio (for windows) and avrdude (for multiple OSs including Linux) support this version 2 of the stk500 protocol. The physical hardware interface to the PC is USB. This way we can build a fast and modern programmer which can be used under Linux, BSD, Windows, MacOS X and others. How to use this USB AVR programmer The avrusb500v2 programmer is an In System Programmer. That is: you do not have to remove the microcontroller from the circuit. Almost all Atmel microcontrollers have for this purpose an interface called SPI (Serial Peripheral Interface). The microcontrollers can be either spi master or spi slave. A spi slave is the microcontroller which is programmed and the programmer is the master. The master is controlling the clock (pin SCK) on the SPI interface. The purpose of the programmer is therefore to "convert" the stk500 protocol to spi commands. To run spi directly over usb would be too slow for normal programming and development. The spi protocol is implemented in the microcontroller hardware. The corresponding pins can used as output (master) when it has to function as a programmer or as input (slave) when you load software into the chip. Since we need the input pins needed for "solving the chicken and egg problem" and the atmega8 has a limited amount of clock speeds for the hardware spi we will use some generic IO pins as output and avrusb500v2 will therefore implement spi in software. The stk500 protocol defines a message format and appropriate commands such as CMD_SET_PARAMETER, CMD_LOAD_ADDRESS, CMD_PROGRAM_FLASH_ISP etc... The protocol sends chunks of data and this is very suitable for USB. The whole protocol is documented in the application note AVR068 (stk500 V2) from Atmel. This stk500 v2 protocol must not be confused with AVR061, which is version 1 of the stk500 protocol. Atmel has done a complete re-design. (Side note: avrusb500v2 and the older avrusb500 implement both the stk500 V2 protocol). Solving the chicken and egg problem Since this programmer contains already a microcontroller we must find a way to initially program it. For this we need a programmer ... the thing that we are about to build... A common solution is to sell microcontrollers with a pre-loaded boot loaded. The problem here is that those special microcontrollers are then specific to one vendor. They are not off the shelf microcontrollers. For the usb interface we use a FT232rl chip. This chip has an interesting mode called "bit-bang" mode. I have written a source code library called ftdibb (only 2 files .c and .h, available from http://tuxgraphics.org/~guido/) which implements this bitbang mode on top of the libUSB library. LibUSB (http://libusb.sourceforge.net) uses the /proc file system to send and receive custom usb messages to any usb device on the usb bus. A slight drawback is that this requires root permissions under Linux it is a slow process as we will send very short messages. Initially (when there is no firmware on loaded in the microcontroller) we have absolutely no storage place and no logic in the programmer. We must send all the commands directly from the PC, bit by bit. USB is fast when you send long chunks of data but it is very slow when you send only 1 bit at a time. This is however acceptable because: The initial firmware needs to be loaded only once. It saves us from having to get first a different programmer to load the initial firmware into this programmer There is no customer lock-in with special AVR chips. Any of the shelf atmega8/atmega88 will work. In other words the avrusb500v2 consists really of two programmers: One slow internal for the initial loading of the firmware and the actual avrusb500v2 programmer which is a very fast and stk500 V2 based programmer for every day use. I called the bitbang programmer for the initial loading "bbpg". I have modified the uisp programmer software for this purpose. You need to download uisp-20050207.tar.gz and then apply the uisp-20050207-usb-bbpg-patch.txt patch (cd uisp-20050207;patch -p1 < uisp-20050207-usb-bbpg-patch.txt ) or you can take the already patched sources (uisp-20050207-usb-bbpg.tar.gz, download at the end). Libusb needs to be installed before you compile the bbpg programmer. The avrusb500v2-X.Y.tar.gz package contains also a patched and pre-compiled binary. If you want to save some compile time then try this one first. You must name this version of uisp "uisp_bbpg". This is what the makefiles and scripts expect. The CD which is sold from http://shop.tuxgraphics.org together with the parts for this programmer can also be used for the initial loading of the firmware. It has the additional advantage that you can do this from the CD without root permissions.