AVR SPI issues programming with avrdude

[Silenus]

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 snippets

C:\>avrdude -c avrisp -b 19200 -P COM3 -p ATmega1281

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.07s

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.


C:\>avrdude -c avrisp -b 19200 -P COM3 -p ATmega1281

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.08s

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


avrdude done.  Thank you.




C:\>avrdude -P COM3 -b 19200 -c avrisp -p ATmega1281 -U flash:w:gas.hex -F

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.06s

avrdude: Device signature = 0x00ffff
avrdude: Expected signature for ATMEGA1281 is 1E 97 04
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: current erase-rewrite cycle count is 1593835520 (if being tracked)
avrdude: erasing chip
avrdude: reading input file "gas.hex"
avrdude: input file gas.hex auto detected as Intel Hex
avrdude: writing flash (134 bytes):

Writing | ################################################## | 100% 0.15s

avrdude: 134 bytes of flash written
avrdude: 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 Hex
avrdude: input file gas.hex contains 134 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.10s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x0c != 0x00
avrdude: verification error; content mismatch

avrdude: safemode: lfuse changed! Was ff, and is now 0
Would you like this fuse to be changed back? [y/n] y
avrdude: safemode: and is now rescued
avrdude: safemode: hfuse changed! Was ff, and is now 0
Would you like this fuse to be changed back? [y/n] y
avrdude: safemode: and is now rescued
avrdude: safemode: efuse changed! Was ff, and is now 0
Would you like this fuse to be changed back? [y/n] y
avrdude: safemode: and is now rescued
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

[tonyarkles]

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 thing

I'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.

[madires]

Do you got a pull-up resistor for the reset pin?

[nuno]

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 thing

And I add

 - avoid more than 30cm cable length, especially when programming with clock > 8MHz

[alexanderbrevig]

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?

[Silenus]

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 thing

I'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.

1. Checked the connections multiple times for continuity to the right pins on the MCU, seems to be fine
2. The only way I don't get a sync error is at 19200 baud which is the arduino ISP baud rate
3. 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.

Do you got a pull-up resistor for the reset pin?

Yeah 10k pull up.

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?

Nothing else on the bus so I don't see how it would be this.

[Silenus]

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: [Select]

C:\>avrdude -c avrisp -b 19200 -P COM3 -p ATmega1281

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.07s

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.


C:\>avrdude -c avrisp -b 19200 -P COM3 -p ATmega1281

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.08s

avrdude: Device signature = 0xffffff
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this 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: [Select]

C:\>avrdude -P COM3 -b 19200 -c avrisp -p ATmega1281 -U flash:w:gas.hex -F

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.06s

avrdude: Device signature = 0x00ffff
avrdude: Expected signature for ATMEGA1281 is 1E 97 04
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: current erase-rewrite cycle count is 1593835520 (if being tracked)
avrdude: erasing chip
avrdude: reading input file "gas.hex"
avrdude: input file gas.hex auto detected as Intel Hex
avrdude: writing flash (134 bytes):

Writing | ################################################## | 100% 0.15s

avrdude: 134 bytes of flash written
avrdude: 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 Hex
avrdude: input file gas.hex contains 134 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.10s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x0c != 0x00
avrdude: verification error; content mismatch

avrdude: safemode: lfuse changed! Was ff, and is now 0
Would you like this fuse to be changed back? [y/n] y
avrdude: safemode: and is now rescued
avrdude: safemode: hfuse changed! Was ff, and is now 0
Would you like this fuse to be changed back? [y/n] y
avrdude: safemode: and is now rescued
avrdude: safemode: efuse changed! Was ff, and is now 0
Would you like this fuse to be changed back? [y/n] y
avrdude: safemode: and is now rescued
avrdude: safemode: Fuses OK

avrdude 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: [Select]

C:\avrdude-6.0.1>avrdude -c avrisp -p atmega1281 -v -P com3 -b 19200
avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch
         System wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf"
         Using Port                    : com3
         Using Programmer              : avrisp
         Overriding Baud Rate          : 19200
         AVR Part                      : ATMEGA1281
         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    10     8    0 no       4096    8      0  9000  9000 0x00 0x00
           flash         65    10   256    0 yes    131072  256    512  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 AVR ISP
         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.07s
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.
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: [Select]

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 -F
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.07s
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATMEGA1281 is 1E 97 04
avrdude: reading input file "0x62"
avrdude: writing lfuse (1 bytes):
Writing |                                                    | 0% 0.00s ***failed;
Writing | ################################################## | 100% 0.16s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0x62:
avrdude: load data lfuse data from input file 0x62:
avrdude: input file 0x62 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.02s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x62 != 0x00
avrdude: verification error; content mismatch
avrdude: safemode: lfuse changed! Was 62, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK
avrdude 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

[Silenus]

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?

[Psi]

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 MCU

Also 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.

[Silenus]

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 SCK     

Changed the pins, everything is working fine now. Thanks for the help

[Psi]

haha yea, i've been caught by that before on the ATmega640 which looks to be a similar MCU to your one.