Burn bootloader to Atmega32u4 using Arduino as ISP

I have been working on a project, making a quadcopter flight control board, with some much needed help from Crossroads :slight_smile: from files released under Creative Commons. The processor used is an Atmega32u4 and the documentation that shows how to burn the bootloader, use a USBasp programmer. I am finding it impossible to get Windows 7 to install the correct drivers for the programmer I have tried a variety of drivers by manually pointing Windows to the driver location but it keeps “insisting” that the right drivers are already installed, being what I assume are the generic Windows ones. Consequently the programmer just comes up as Unknown Device.

My question is can I use the Arduino Uno R3 as an ICSP and if so which of the two sets of pins do I use seeing as there are two, one labelled ICSP for USB interface and the other ICSP for Atmega328 See image and thanks to Nick for that. Here are the instructions supplied to facilitate the burning of the bootloader to the flight control board.

Neither. Those are the headers for programming the two avrs on the uno. If you google Arduino as ISP you will see that pins 10 to 13 on the uno connect to the SPI pins of your avr.

Thanks somedude, so they are to receive data not send it in a manner of speaking :)

Well, they both serve for in-circuit serial programming the two devices on the uno, with communications going two ways on each one when you have a programmer connected.

In a sense, yes, you can use those two headers, one at a time, to "send" programs to the 16U2 or the 328P.

To program another AVR with the Uno you need to put that device's reset pin to low, so that it goes into programming mode. The Uno, when used as a programmer, will use pin 10 for that purpose, so that is why you can't use the header. the other 3 SPI pins: SCK, MISO and MOSI, are connected to both the ICSP header and to pins 11 to 13 on the Uno, but you need an output pin (10) to drive Reset low on the device being programmed.

Thanks for taking the time to explain. Yes prior to thinking about trying to use the Uno to flash the bootloader onto the Atmega32u4 on this flight controll board (FCB), I soldered a Atmega32u4 to a breakout board and successfully flashed the bootloader onto it and verified its success by uploading a modified blinky to it. Then I went to try and flash the Atmega that is in circuit on the FCB, via the programming pins on it but as I said the USBasp programmer will not work because of a Windows driver issue that I cannot resolve. This is when I thought that maybe I can flash the FCB Atmega the same way with the Uno as ISP. The bit that I am having trouble understanding is that I look at pins 10, 11, 12 and 13 on the Uno and yes D11 is Mosi, D12 is Miso, D13 is SCK so they all correspond to the same pins that are available at the FCB programming pins but D10 on the Uno is SS, which I think is Slave Select? but the other pin required on the FCB is RST not SS as on the FCB. Can I do this and if so how do I connect it please. Sorry for the rudimentary image

First, make sure your special board is ok to power with 5V and has 5V logic levels, because that is what the Uno is going to supply to it.

Make sure the ArduinoISP sketch is loaded on the Uno before you connect the other wires and the capacitor.

Connect your 2 question marks together. Select on the Tools, Programmer menu: "Arduino as ISP" Select on the Tools, Board menu "Leonardo" then, Tools, Board, Burn Bootloader.

Thanks dmjlambert,

I will check that the FCB has 5V logic levels, which I assume I do by looking at the schematic and seeing what voltage is applied at the VCC pins on the Atmega32u4, is that correct please?

I am pretty sure it does but I would hate to fry this board as they are few and far between for the present :)

I was just a little confused with that last connection seeing as one was SS and the other RST. Wish me luck and thanks to both you and somedude for taking the time to help me

Pedro

Yes, you can look at the schematic. Or go ahead and plug in the USB cable to power it up and measure with a voltmeter between the VCC and GND pins of the ISP programming header.

Oh, I see what you mean. There is a jumper on the USBasp to select between 5v and 3.3v and I am pretty sure the the Atmega requires 5v to function. Is that your understanding?

The ATmega32U4 does not require 5V to function. It may run on any of a variety of voltages. I don't know if there are other components on your special board which require operation at 3.3V and would be damaged by VCC at 5V. I recommend figuring that out before you proceed.

Thanks again for your help and patience :) I will thoroughly check it out before proceeding

Pedro147: I was just a little confused with that last connection seeing as one was SS and the other RST.

Pedro

Uno's pin 10 has a special function as /SS. However, when the arduino as ISP is loaded, it is being used as an output pin. That output pin puts the target AVR being programmed in programming mode, which is done by putting /RESET in a low state. That is why pin 10 on the Uno goes to the /RESET pin on your target AVR.

I thought this needed clarification... ☺

Thanks for that somedude. It gets a bit complicated when there are multiple functions for some pins depending on what code they are running :)

No worries.

Cool website, BTW…

Thanks somedude :)

I get very few visitors to my site and even less compliments. It's just a place to host a bit of my WebDev practise

I am still having no success in burning the bootloader to this flight board with the Atmega32u4 as the micro controller. I decided to try the Arduino Uno as ISP method again using digital pins 10 , 11, 12 and 13 as RST, MOSI, MISO, and SCK respectively with GND and VCC with a 10uf cap between reset and GND and this is what it generated:

C:\Program Files\Arduino 1.6.6\hardware\tools\avr/bin/avrdude -CC:\Program Files\Arduino 1.6.6\hardware\tools\avr/etc/avrdude.conf -v -patmega32u4 -cstk500v1 -PCOM4 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m

avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is "C:\Program Files\Arduino 1.6.6\hardware\tools\avr/etc/avrdude.conf"

Using Port : COM4 Using Programmer : stk500v1 Overriding Baud Rate : 19200 AVR Part : ATmega32U4 Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PA0 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 ByteDelay : 0 PollIndex : 3 PollValue : 0x53 Memory Detail :

Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack


eeprom 65 20 4 0 no 1024 4 0 9000 9000 0x00 0x00 flash 65 6 128 0 yes 32768 128 256 4500 4500 0x00 0x00 lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : STK500 Description : Atmel STK500 Version 1.x firmware Hardware Version: 2 Firmware Version: 1.18 Topcard : Unknown Vtarget : 0.0 V Varef : 0.0 V Oscillator : Off SCK period : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000 (retrying)

Error while burning bootloader. Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000 avrdude: Yikes! Invalid device signature. Double check connections and try again, or use -F to override this check.

avrdude done. Thank you.


So I assume that the crux of the problem are the lines

avrdude: Device signature = 0x000000 avrdude: Yikes! Invalid device signature.

When I googled this it seems to possibly point to the fact that there is no functioning oscillator in the micro. When I looked at the error output above it says "Oscillator : Off"

There is a 16mhz resonator on the flight control board, is this of any help in diagnosing my problem please.

Thanks in advance Pedro

Well I am about out of practical ideas. Double and triple check your wiring before going any further.

The supporting circuitry on the board, such as the resonator, could be bad. I suppose you could remove the resonator and replace it and see what happens. Or with the resonator removed you can apply an external clock signal to the xtal1 pin of the target chip, using an alternate version of ArduinoISP sketch that provides clock out such as Adafruit's version.

Or you could have a short or open on the board. You need to do some meticulous tracing with an ohm meter to find problems.

If the problem is with the processor, the fuses may be set to disallow serial programming, which means you can no longer use ICSP on it. In order to recover from that you would need access to a great number of pins on the processor and do high voltage parallel programming to recover the fuses. You would probably need to remove the processor using Chip Quik or other SMD removal alloy and temporarily solder it on a plain breakout board and program it, then transfer it back, or get a fresh ATmega32U4 and remove and replace the chip.

Thanks for your reply dmjlambert. The perplexing thing is that the board is functioning correctly but it is just not showing up in device manager, so if I want to reflash a modified version of the operating code on it (a common scenario with processors used for these applications), I cannot do this via the Arduino IDE. I would assume that if the resonator was defective then the board would not be operating as it currently is if that makes sense. Is there any way that I can read what the fuses are set to? Maybe one of Nick Gammon's pieces of code

If the board is functioning, but you can't program it, it could be because the fuses were set to specifically disallow further programming, either by accident or intentionally. If ICSP programming can't even read the device signature, it will not be able to read the fuses. There are sketches which can read the fuses from within the board itself, but you need to be able to load the sketch on the board. It seems whoever sold you the board should be able to tell you if it is programmable and help you program it.

I am not clear from reading the entire thread what the history of this board is. I'm wondering if you ever programmed it, or received it with a program on it already. Or did you build the board or solder the ATmega32U4 on it yourself, or what? I am just not clear on the sequence of events that got you to this point, or what the whole story is.

dmjlambert: It seems whoever sold you the board should be able to tell you if it is programmable and help you program it.

Yes this is a purchased board although I am also in the process of assembling some others myself. Yes the boards are programmable by uploading Arduino code to them via USB by using the Arduino IDE and the Multiwii GUI. This board already has this code installed on it but after a hard crash the board can reset itself to the default settings which make it hard for a novice to fly. This is when it needs to be accessed via the GUI interface to reset the options in the Multiwii software. Because the PC is not recognising the board i.e. - it does not show up as a com port in device manager, this cannot be done. This is why I suspected that maybe there was a problem with the bootloader and If I re-flashed it and re-uploaded the operating code this would all be resolved. It is just strange that the board is still operating enough to fly so obviously the Atmega is functioning adequately for this task. Maybe as you surmise the fuses have inadvertently been reset to disallow further programming. Is there no way that the Atmega can be "reset" I suppose obviously not unless the PC can "see it" which is a real catch 22 situation :)