The avrdude: stk500_recv() error message is alerting you to a generic connection error between your computer and the Arduino. I wish I could keep it simple and tell you this error happens because of one single problem, but that would be too easy. This generic error can pop up for a host of reasons.
avr stk500 programmer software 13
Download File: https://jinyurl.com/2vzm0h
The whole process of loading the bootloader code and burning properly the fuses to make an ATmega microcontroller an "Arduino" is managed by the Arduino Software (IDE): it provides a specific menu item and allows you to use a variety of programming devices.Among the programmers, the "Arduino as ISP" is the cheapest and most practical solution to burn a bootloader on another Arduino board with ATmega, 32U4 or ATtiny.
In the picture above we are connecting two UNO boards for bootloader burning with the "old style" connections: the top board is the Target, the bottom board is the Programmer. Note the yellow connection from D10 of the programmer to RESET of the target. On MKR family of boards, you can't use D10 for reset; we suggest D6 and you must remember to change the line 73 of the ArduinoISP sketch - #define RESET 10 - putting "6" insteat of 10.
The Arduino MEGA above is programming an Arduino UNO connecting D51-D11, D50-D12, D52-D13, GND-GND, 5V-5V and D10 to RESET. This type of board needs a 10µF electrolytic capacitor connected to RESET and GND with the positive (long leg) connected to RESET. The capacitor has to be placed after the programmer board has been loaded with the ISP sketch.
The Arduino family of boards includes 5V and 3.3V devices. When using an Arduino that is not 5V tolerant (Due, Zero, ...) as the programmer, make sure to not expose any of the programmer's pins to 5V. A simple way to accomplish this is to power the complete system (programmer and target) at 3V3.
In the above picture you see the wiring between a MKR1000 and a UNO. As described above, everything runs on 3.3V, taken from VCC and GND of the MKR1000 and sent to 5V and GND of the UNO. The same connection could be made to the ICSP of the UNO following the pinout explained in the page. We have used the same colors for the wires as in the other pictures to help you switch from the "old wiring" to the ICSP connector with ease. Please note that the MKR family of boards share the same pinout, therefore you can use any MKR board as ISP programmer. If you use a MKR board as ISP programmer, remember to change the line 73 of the ArduinoISP defining the actual pin used on the MKR board to Reset the target (6 in the picture above).
Note: Please do not connect to USB or power supply the boards while you set up the connections and wires. We also suggest that you first program the Arduino used as ISP programmer before you proceed with the wiring to the target board.
The open source software tool used to program the microcontroller is avrdude. The process goes through four steps: unlocking the bootloader section of the chip, setting the fuses on the chip, uploading the bootloader code to the chip, locking back the bootloader section of the chip.
Select the item in the Tools > Board menu that corresponds to the board on which you want to burn the bootloader (not the board that you're using as the programmer). See the board descriptions on the environment page for details.
Microcontrollers are usually programmed through a programmer unless you have a piece of firmware in your microcontroller that allows installing new firmware without the need of an external programmer. This is called a bootloader.
To burn the bootloader, you'll need to buy an AVR-ISP (in-system programmer), USBtinyISP or build a ParallelProgrammer. The programmer should be connected to the ICSP pins (the 2 by 3 pin header) - make sure you plug it in the right way. The board must be powered by an external power supply or the USB port.
The Pololu USB AVR Programmer v2.1 is a drop-in replacement for the older Pololu USB AVR Programmer v2 with several hardware improvements that are described in the ?Comparison to previous AVR programmers? section below.This product requires a USB A to Micro-B cable to connect to a computer.
Supported AVR microcontrollersThe programmer should work with all AVRs that can be programmed with the AVR ISP (in-system programming) interface, which is also known as in-circuit serial programming (ICSP), serial programming, or serial downloading, but it has not been tested with all devices. We expect it to work with most AVRs in the megaAVR (ATmega) family, and it works with some members of the tinyAVR (ATtiny) family, but it does not support the Tiny Programming Interface (TPI), and it does not work with the XMEGA family or with 32-bit AVRs. The programmer features upgradable firmware, allowing updates for future devices.
The programmer is designed for use with AVR microcontrollers running at either 3.3 V or 5 V. By default, the programmer expects the target to be self-powered, but it can be configured to deliver power to the target device in low-power systems.Supported operating systemsWe support using the Pololu USB AVR Programmer v2.1 and its configuration software on desktop versions of Windows (7, 8, and 10), Linux, and Mac OS X 10.11 or later. Older versions of Windows are not supported.
Bonus feature: TTL-level serial portThis programmer doubles as a USB-to-serial adapter. The programmer installs as two virtual COM ports: one for communicating with programming software and one for general-purpose serial communications. This means that you can seamlessly switch between programming an AVR and debugging it through the TTL serial port without having to open and close your terminal program. In addition to the serial transmit (TX) and receive (RX) lines, the programmer lets you use A and Bas serial handshaking lines that can be configured using our software.
The six pins on the serial header (GND, A, VCC, TX, RX, and B) are arranged to be similar to the pinout of commonly-available FTDI USB-to-serial cables and breakout boards. In the default configuration, pin B is used as the DTR output (and pin A is an unused input), which allows you to plug the programmer directly into a variety of Arduino-compatible boards (including our A-Star 328PB Micro) and use it to upload programs to the board via a serial bootloader.
Abstract: 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 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 versionand 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: _________________ _________________ _________________ 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 hasto function as a programmer or as input (slave) when you load softwareinto 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 somegeneric 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 guido/) which implements this bitbang mode on top of the libUSB library. LibUSB ( ) 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 The CD which is sold from 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. The hardware The specification from Atmel for the STK500 V2 communication protocol is 37 pages long. It is however not a problem to fit it into an atmega8 microcontroller. It fills about half of the available memory. Here is the schematic drawing. The right side is the usb to rs232 conversion circuit to provide usb connectivity to the atmega8/atmega88. The whole circuit is self powered. That is: unlike may other programmers you do not need additional pins to draw the power from the target circuit. Click on the picture to see a larger version. The circuit diagram is also available as PDF We need an external crystal for the atmega8/atmega88. This is because the UART for the serial communication via usb needs to run at 115.2K baud and this can only be done with a crystal. Why do we need 115.2K baud? This is mainly because Atmel has designed it's avrstudio software this way. The hardware can work with either atmega8 or atmega88/atmega168 because I have written the software such that it can be compiled for both platforms after configuring the right platform in the Makefile. The background is that theoretically the atmega8 can be clocked up-to 16MHz and the atmega88/atmega168 up to 20MHz. The fast clock speed is needed because the SPI interface to the target is implemented in software and in order to get a fast AVR programmer we need the speed. In other words if you want to follow strictly the specifications then you should use 14.7456MHz for atmega8 or 18.4320MHz for atmega88/atmega168. It turns however out that minimal overclocking of the atmega8 is not a problem as long as the power supply voltage of the atmega8 is close to 5V. The atmega8 has as of today probably the best price to feature ratio. My recommendation is therefore: use atmega8 and a 18.4320MHz crystal. A new and really useful feature is the target connector polarity recognition. The tuxgraphics connector is symmetric withstandard color codes. The Atmel 10 and 6 pin connector have a notch but very often the target boards have just the plain pins coming. No damage is done if the connector is inserted the wrong way round but it is still annoying if you have to troubleshoot why the programmer does not seem to work. avrusb500v2 has now an LED which goes on as soon as the connector is correctly inserted. A main source of troubles is therefore eliminated. The connection from the target reset pin to ADC0 is used for this purpose.There is also and output for the 1MHz emergency clock signal (CONN5) anda 5V output to power a target (CONN2) if needed. Be however aware thatthere are no fuses or current limiting components on CONN2. No morethan 20mA should be taken from CONN2. If you want a fused USB power supplyto power external hardware from the USB bus of you computer theI can recommend the 5Vmini power supply, USB( ). The avrusb500v2 software avrusb500v2 has this self boot-strapping feature which makes it possible for anybody to build this hardware with out the help of others to get the first firmware loaded. For this purpose the connections between the MOSI, SCK, MISO pins and the ftdi chip are needed. Those pins would however also be needed if we would use the hardware SPI in the atmega chip towards the target. The old avrusb500 required therefore a 5 pin bridge cable. The new avrusb500v2 implements the SPI towards the target in software. Any pin can therefore be used as output towards the target. Just the reset pin is, for safety reasons, connected and disconnected after the initial firmware loading. To implement the SPI in software I started with hand optimized assembler but soon I found that well written C code can do the job too especially when a 18MHz crystal is used to clock the atmega. C-code is easier to read and maintain. SPI is a very simple interface. Programmer controls the clock line called SCK. At the rising clock edge the data is shifted on the MOSI pin from programmer to target at on the MISO pin from target to programmer. In hardware this is easily implemented as a shift register. In software it can be done like this: unsigned char i=128; // shift 8 bitunsigned char rval=0; // data read from targetwhile(i!=0){ // MOSI if (data&i){ PORTD= 1 Guido Socher, tuxgraphics.org 2ff7e9595c
Comments