AVR SPI issues programming with avrdude - Page 1
Forum section: electronics / projects

author: Silenus
author_rank: Contributor
timestamp: April 02, 2015, 11:58:51 am
content: Hey guys. I've got an ATmega1281V on a custom board of mine and when I try to upload code or view the device signature of the chip with avrdude I get the device signature changing randomly and if I try to program it, there is a first byte mismatch error at byte 0x00. I am programming the AVR with an arduino uno using the ISP programmer sketch. The wires I'm using I ave used to program another device before however that was using an ATmega2560 as the isp programmer (dont have anymore). At the ICSP header on the board, there is a 22pF cap between reset and ground and a 100nF cap between Vcc and ground. I've tried programming it using the arduino power pins and the boards own power but both yield same result. I have a feeling that the data being sent over the SPI bus is being corrupted somewhere along the line, which would explain why the device signature changes every now and then when I simply read it using (avrdude -c avrisp -b 19200 -P COM3 -p ATmega1281). Besides that, I'm fairly new to making my own boards from scratch (this is my second board) so I might have missed something. Any ideas what could be going wrong here?here are some snippetsC:\>avrdude -c avrisp -b 19200 -P COM3 -p ATmega1281avrdude: AVR device initialized and ready to accept instructionsReading | ################################################## | 100% 0.07savrdude: Device signature = 0x000000avrdude: Yikes! Invalid device signature.Double check connections and try again, or use -F to overridethis check.avrdude done. Thank you.C:\>avrdude -c avrisp -b 19200 -P COM3 -p ATmega1281avrdude: AVR device initialized and ready to accept instructionsReading | ################################################## | 100% 0.08savrdude: Device signature = 0xffffffavrdude: Yikes! Invalid device signature.Double check connections and try again, or use -F to overridethis check.avrdude done. Thank you.C:\>avrdude -P COM3 -b 19200 -c avrisp -p ATmega1281 -U flash:w:gas.hex -Favrdude: AVR device initialized and ready to accept instructionsReading | ################################################## | 100% 0.06savrdude: Device signature = 0x00ffffavrdude: Expected signature for ATMEGA1281 is 1E 97 04avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performedTo disable this feature, specify the -D option.avrdude: current erase-rewrite cycle count is 1593835520 (if being tracked)avrdude: erasing chipavrdude: reading input file "gas.hex"avrdude: input file gas.hex auto detected as Intel Hexavrdude: writing flash (134 bytes):Writing | ################################################## | 100% 0.15savrdude: 134 bytes of flash writtenavrdude: verifying flash memory against gas.hex:avrdude: load data flash data from input file gas.hex:avrdude: input file gas.hex auto detected as Intel Hexavrdude: input file gas.hex contains 134 bytesavrdude: reading on-chip flash data:Reading | ################################################## | 100% 0.10savrdude: verifying ...avrdude: verification error, first mismatch at byte 0x00000x0c != 0x00avrdude: verification error; content mismatchavrdude: safemode: lfuse changed! Was ff, and is now 0Would you like this fuse to be changed back? [y/n] yavrdude: safemode: and is now rescuedavrdude: safemode: hfuse changed! Was ff, and is now 0Would you like this fuse to be changed back? [y/n] yavrdude: safemode: and is now rescuedavrdude: safemode: efuse changed! Was ff, and is now 0Would you like this fuse to be changed back? [y/n] yavrdude: safemode: and is now rescuedavrdude: safemode: Fuses OKavrdude done. Thank you.

author: tonyarkles
author_rank: Regular Contributor
timestamp: April 02, 2015, 01:50:42 pm
content: Here's a couple of things that have burned me before:- Mixing up the connections to the header (if MISO ends up tied high, you'll get a stream of 0xFF)- Running the serial port at the wrong baud rate. Might not matter for USB devices that just enumerate as USB COM ports. Try 115200?- Driving the SPI bus too fast for the internal RC oscillator (it comes programmed by default to use a very slow clock until you burn the fuses to change that). There's an option for avrdude to slow it down.- Other devices on the SPI bus. I've had devices before that required a pull-up on their /CS line, otherwise they'd send data over MISO while avrdude was doing its thingI'd check those things in probably that order. I don't recall the option for slowing down the SPI clock, but it should be easy to find in the help.

author: madires
author_rank: Super Contributor
timestamp: April 02, 2015, 02:01:28 pm
content: Do you got a pull-up resistor for the reset pin?

author: nuno
author_rank: Frequent Contributor
timestamp: April 02, 2015, 03:32:50 pm
content: Quote from: tonyarkles on April 02, 2015, 01:50:42 pmAnd I add- avoid more than 30cm cable length, especially when programming with clock > 8MHz

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: April 02, 2015, 03:45:02 pm
content: I recently had this exact problem. It turned out to be one of my ICs pulling MISO low on power up. The datasheet did tell me about this fact but I didn't see it so now I have to pull the IC on and off the board.Do you share MISO or MOSI with anything that could be pulling the lines?

author: Silenus
author_rank: Contributor
timestamp: April 03, 2015, 04:42:07 am
content: Quote from: tonyarkles on April 02, 2015, 01:50:42 pm1. Checked the connections multiple times for continuity to the right pins on the MCU, seems to be fine2. The only way I don't get a sync error is at 19200 baud which is the arduino ISP baud rate3. I've tried the command line with -i 1000 to slow down the SPI bus but no effect.4. No other devices on the bus, the traces go directly to the chip with nothing else on it.Quote from: madires on April 02, 2015, 02:01:28 pmYeah 10k pull up.Quote from: alexanderbrevig on April 02, 2015, 03:45:02 pmNothing else on the bus so I don't see how it would be this.

author: Silenus
author_rank: Contributor
timestamp: April 03, 2015, 04:45:43 am
content: Here is a copy of another thread that I started detailing a better chronological order of events here.Hey guys, firstly my apologies if a solution I'm looking for has already been posted here, I have looked around 10's of posts from this forum and have tried a few things but my scenario seems somewhat unique that may require more advice.I have a self built embedded project that at the moment consists of a power supply, an ATmega1281V, an ICSP header and caps: 0.47uF across Vcc-GND (near PSU), 100nF across Vcc-GND (near atmega), 22pF across reset-GND (at ICSP header), 100nF across Vcc-GND (near ICSP header) and a 10k pull up resistor on the reset line.I am trying to use avrdude to program my device (using arduino uno as programmer), but as of yet I haven't been unable to read a valid signature. My first few attempts using (avrdude -c avrisp -b 19200 -P COM3 -p ATmega1281) resulted in changing device signatures:Code:C:\>avrdude -c avrisp -b 19200 -P COM3 -p ATmega1281avrdude: AVR device initialized and ready to accept instructionsReading | ################################################## | 100% 0.07savrdude: Device signature = 0x000000avrdude: Yikes! Invalid device signature.Double check connections and try again, or use -F to overridethis check.avrdude done. Thank you.C:\>avrdude -c avrisp -b 19200 -P COM3 -p ATmega1281avrdude: AVR device initialized and ready to accept instructionsReading | ################################################## | 100% 0.08savrdude: Device signature = 0xffffffavrdude: Yikes! Invalid device signature.Double check connections and try again, or use -F to overridethis check.avrdude done. Thank you.I stupidly read somewhere that the device signature might not be exactly what the avrdude expects and that you could try programming the device anyway with -F (dumb I know). Anywho, I ended up doing this:Code:C:\>avrdude -P COM3 -b 19200 -c avrisp -p ATmega1281 -U flash:w:gas.hex -Favrdude: AVR device initialized and ready to accept instructionsReading | ################################################## | 100% 0.06savrdude: Device signature = 0x00ffffavrdude: Expected signature for ATMEGA1281 is 1E 97 04avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performedTo disable this feature, specify the -D option.avrdude: current erase-rewrite cycle count is 1593835520 (if being tracked)avrdude: erasing chipavrdude: reading input file "gas.hex"avrdude: input file gas.hex auto detected as Intel Hexavrdude: writing flash (134 bytes):Writing | ################################################## | 100% 0.15savrdude: 134 bytes of flash writtenavrdude: verifying flash memory against gas.hex:avrdude: load data flash data from input file gas.hex:avrdude: input file gas.hex auto detected as Intel Hexavrdude: input file gas.hex contains 134 bytesavrdude: reading on-chip flash data:Reading | ################################################## | 100% 0.10savrdude: verifying ...avrdude: verification error, first mismatch at byte 0x00000x0c != 0x00avrdude: verification error; content mismatchavrdude: safemode: lfuse changed! Was ff, and is now 0Would you like this fuse to be changed back? [y/n] yavrdude: safemode: and is now rescuedavrdude: safemode: hfuse changed! Was ff, and is now 0Would you like this fuse to be changed back? [y/n] yavrdude: safemode: and is now rescuedavrdude: safemode: efuse changed! Was ff, and is now 0Would you like this fuse to be changed back? [y/n] yavrdude: safemode: and is now rescuedavrdude: safemode: Fuses OKavrdude done. Thank you.Now whenever I read my device signature, it's always 0x000000 and when I request the details of the chip I get this info:Code:C:\avrdude-6.0.1>avrdude -c avrisp -p atmega1281 -v -P com3 -b 19200avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/Copyright (c) 2007-2009 Joerg WunschSystem wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf"Using Port : com3Using Programmer : avrispOverriding Baud Rate : 19200AVR Part : ATMEGA1281Chip Erase delay : 9000 usPAGEL : PD7BS2 : PA0RESET disposition : dedicatedRETRY pulse : SCKserial program mode : yesparallel program mode : yesTimeout : 200StabDelay : 100CmdexeDelay : 25SyncLoops : 32ByteDelay : 0PollIndex : 3PollValue : 0x53Memory Detail :Block Poll Page PolledMemory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------eeprom 65 10 8 0 no 4096 8 0 9000 9000 0x00 0x00flash 65 10 256 0 yes 131072 256 512 4500 4500 0x00 0x00lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00Programmer Type : STK500Description : Atmel AVR ISPHardware Version: 2Firmware Version: 1.18Topcard : UnknownVtarget : 0.0 VVaref : 0.0 VOscillator : OffSCK period : 0.1 usavrdude: AVR device initialized and ready to accept instructionsReading | ################################################## | 100% 0.07savrdude: Device signature = 0x000000avrdude: Yikes! Invalid device signature.Double check connections and try again, or use -F to overridethis check.avrdude done. Thank you.Looking at the datasheet for my MCU, I can see that the default values for the fuses are 0x99 for high and 0x6F for low, however when I tried to change these back, I was unsuccessful. Note I also tried to slow down the SPI speed using -i 1000:Code:C:\avrdude-6.0.1>avrdude -b 19200 -i 1000 -p atmega1281 -c avrisp -P com3 -U lfuse:w:0x62:m -U hfuse:w:0x99:m -D -Favrdude: AVR device initialized and ready to accept instructionsReading | ################################################## | 100% 0.07savrdude: Device signature = 0x000000avrdude: Yikes! Invalid device signature.avrdude: Expected signature for ATMEGA1281 is 1E 97 04avrdude: reading input file "0x62"avrdude: writing lfuse (1 bytes):Writing | | 0% 0.00s ***failed;Writing | ################################################## | 100% 0.16savrdude: 1 bytes of lfuse writtenavrdude: verifying lfuse memory against 0x62:avrdude: load data lfuse data from input file 0x62:avrdude: input file 0x62 contains 1 bytesavrdude: reading on-chip lfuse data:Reading | ################################################## | 100% 0.02savrdude: verifying ...avrdude: verification error, first mismatch at byte 0x00000x62 != 0x00avrdude: verification error; content mismatchavrdude: safemode: lfuse changed! Was 62, and is now 0Would you like this fuse to be changed back? [y/n] navrdude: safemode: Fuses OKavrdude done. Thank you.Assuming the fuses to be zero, that means the clock is being sourced externally, so I soldered on my external quartz oscillator and 22pF caps but this didnt affect anything. I tried probing the xtal pins when the board was on but I couldn't see any signal on the DSO (although I'm not 100% sure how to check this, is it from xtal1 to gnd? or xtal1 to xtal 2?).So here I am now, not sure if it's my circuit that's wrong, or I've changed some fuses that disable programming, or if my SPI bus even works at all! There are too many factors that I can adequately dissect from one another to make an informed judgement about what to do next. Any advice guys? Thanks

author: Silenus
author_rank: Contributor
timestamp: April 03, 2015, 08:36:01 am
content: Okay so I hooked up the oscilloscope to the SPI data lines during the command "avrdude -P com3 -p atmega1281 -c avrisp -b 19200 -i 1000" and had a look at what the lines were doing:I'm not experienced in looking at these sorts of data transmissions in a real sense, but I have a suspicion there is a lot of noise around the circuit (whether this is significant or normal I don't know). Also should there be anything on the MISO bus? It would appear as if that activity on the MISO line is being coupled from the other lines. How would I fix this?

author: Psi
author_rank: Super Contributor
timestamp: April 03, 2015, 11:23:45 am
content: There is something very wrong with MOSI (yellow channel)It appears to be floating, MOSI is slave input, so a floating input would pickup other channels exactly like you are seeing.If it was working correctly you should see pulses of roughly the same voltage as the other channels.Have a look at the PC end of the MOSI line, you should see pulses coming out of the computer and for whatever reason they are not getting to the MCUAlso double check you have MOSI and MISO around the right way.MOSI on the PC end goes to MOSI on MCU end.M = master S = slave so the MOSI pin is Master Output or Slave Input.It's not like TX/RX where you reverse them.

author: Silenus
author_rank: Contributor
timestamp: April 03, 2015, 01:57:02 pm
content: Guys I fixed the problem, and I feel really really dumb. You cant program the ATmega1281V with SPI using the SPI pins in port B, you have to use PDI, PDO and SCKChanged the pins, everything is working fine now. Thanks for the help

author: Psi
author_rank: Super Contributor
timestamp: April 03, 2015, 08:41:37 pm
content: haha yea, i've been caught by that before on the ATmega640 which looks to be a similar MCU to your one.