Sanguino v1.0 bootloader frustration (with much detail!) [SOLVED]

Ok, I've got a problem getting a bootloader on a Sanguino board (the long skinny one) that I've assembled. I've tried a bunch of different things and I think I may have a bad crystal oscillator. Here's essentially where I am now, with way more detail below.

---Question---
How critical is the timing for the compiled sanguino bootloader ATmega_644p.hex for 16Mhz vs 12Mhz crystals? I've ordered more crystals, but until they show up I tried using a 12Mhz crystal that I had, and avrdude still gave rc=-1 when trying to just read the chip. The fuse bits suggest that it just needs >8MHz, right? Is there something special about the way the bootloader works with the timing, or is there something worse wrong with my board?

---More Detail---
Sanguino v1.0 PCB from makerbot, with my own components.

WinXP SP2 with Arduino 0017, WinAVR 20090313, Sanguino software 1.4r1, avrdude 5.6 (Mar 5 09)

16MHz crystal from the local electronics supply (that may be suspect), with two 22pF ceramic disc caps. 12 Mhz crystal from same supply (with the same suspicion)

*3 SEPARATE* ATmega644P chips have been tried

USBtinyISP from adafruit, built from their PCB and my own components. Verified to work with other tiny2313's as well as the extruder 2.2 board

Brian Dean's parallel ICSP programmer, verified to work with tiny2313's (used it to program the USBtiny chip)

Arduino "miniusb" USB to TTL converter, v3 from adafruit, tried to run it in bitbang mode based on this ExMrClean post, with the correct pinouts from the arduino page and the FTDI datasheet, including setting the CTS# and RTS# pins in avrdude.conf as negative pins (ie, SCK ~3). Inconclusive: I could never get avrdude to respond other than rc=-1

High Voltage parallel programmer made from a Basic Stamp board of education and the atmega644p datasheet

---Process---
*Chip #1*
Tried burning the Sanguino bootloader using Arduino 0017 and USBtiny: rc=-1

Tried burning the Sanguino bootloader using avrdude with USBtiny the same target chip: rc=-1. Flaky USB connection from USBtiny as a result of using 1W zeners and not 0.5W. Replaced zeners and USB connection issue went away, but still rc=-1.

Tried powering chip from usbtiny and externally for all usbtiny tests. rc=-1

Tried to read chip using avrdude/bsd programmer: rc=-1

Tried using -B <0-40> with avrdude and usbtiny: rc=-1

Tried to use avrdude and usbttl in bitbang mode, with and without -B 4800: rc=-1

Tried to read chip using high voltage basic stamp: sucessfully read and reset fuses, erased chip.

Tried to burn bootloader with USBtiny/avrdude. Tried burning hex, writing lock bits to 0x3F, writing lfuse 0xFF, writing hfuse 0xDC, writing efuse 0xFD in one go, with intent to set lock bits to 0x0F on next command: SUCCESS writing hex, fuses (no flashing debug light tho). Next command to write lock bits gets rc=-1. (note: fuse values from boards.txt for sanguino)

Tried to get HVBasicStamp to read fuses again: all fuses, signature bits set to alternately 0x99 or 0x0A, attempts to reset fuses do not stick.

Tried again to read using avrdude/bsd programmer: rc=-1

Gave up on chip #1

*Chip #2*
Tried to start over by burning bootloader using arduino/usbtiny: rc=-1

Gave up on chip #2

*Chip #3*
Tried to burn bootloader with avrdude/usbtiny by writing hex, lock bit 0x3F, lfuse 0xFF, hfuse 0xDC, efuse 0xFD, lock 0x0F: SUCCESS writing all bits. No blinking debug light. Next avrdude read command rc=-1

Powered Sanguino board via external supply plugged into the wall and scoped the crystal: all I got was a nice clean low amplitude 60Hz wave (from the wall socket, i'm assuming), both in powered and unpowered states. Crystal dead?

Replaced 22pF caps with other ones of same type. rc=-1

Replaced crystal with 12MHz while waiting for replacement 16MHz. rc=-1 (no access to scope while at home).

---AVRDUDE---
Here's the output from avrdude for the Chip #3 program that seemed to work. No change was made to the hardware between commands.

D:\WinAVR\bin>avrdude -c usbtiny -p atmega644p -P usb

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e960a

avrdude: safemode: Fuses OK

avrdude done. Thank you.


D:\WinAVR\bin>avrdude -c usbtiny -p atmega644p -P usb -U flash:w:ATmegaBOOT_644p.hex:i -U lock:w:0x3F:m -U efuse:w:0xFD:
m -U hfuse:w:0xDC:m -U lfuse:w:0xFF:m -U lock:w:0x0F:m 0v

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e960a
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "ATmegaBOOT_644p.hex"
avrdude: writing flash (65382 bytes):

Writing | ################################################## | 100% 36.44s



avrdude: 65382 bytes of flash written
avrdude: verifying flash memory against ATmegaBOOT_644p.hex:
avrdude: load data flash data from input file ATmegaBOOT_644p.hex:
avrdude: input file ATmegaBOOT_644p.hex contains 65382 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 34.38s



avrdude: verifying ...
avrdude: 65382 bytes of flash verified
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3F:
avrdude: load data lock data from input file 0x3F:
avrdude: input file 0x3F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0xFD"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xFD:
avrdude: load data efuse data from input file 0xFD:
avrdude: input file 0xFD contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0xDC"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDC:
avrdude: load data hfuse data from input file 0xDC:
avrdude: input file 0xDC contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFF:
avrdude: load data lfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0x0F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x0F:
avrdude: load data lock data from input file 0x0F:
avrdude: input file 0x0F contains 1 bytes
avrdude: reading on-chip lock data:

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

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.


D:\WinAVR\bin>avrdude -c usbtiny -p atmega644p -P usb

avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.


avrdude done. Thank you.


D:\WinAVR\bin>avrdude -c usbtiny -p atmega644p -P usb -B 12

avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.


avrdude done. Thank you.

D:\WinAVR\bin>avrdude -c usbtiny -p atmega644p -P usb -B 12 -F

avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATMEGA644P is 1E 96 0A

avrdude done. Thank you.

Edited 1 time(s). Last edit at 11/13/2009 11:57PM by toomanyplugs.

The crystal isn't used when flashing the device with a ICSP.

I know on my board I had a faulty chip (took a few days to find the fault)

I'd suggest you get a multimeter and check the 5V rail, and check to see if there are any shorts or dry joints anywhere.

If you have a scope you can use it to see if the device is giving a response back.

I've checked the board for shorts, 5V rail seems ok, both regulated through the 7805 and from external source (usbtiny with jumper attached: 5V supplied thru ICSP from USB, etc).

Atmel seems to disagree that the crystal isn't used for ICSP programming:
support.atmel.no

Quote

One possible scenario is that you have programmed the fuse Bits to a clock source that does not exists, for instance you have fused your AVR to an external clock, but no clock is connected on the XTAL pins. In this situation ISP programming will not work, as it is dependent on the system clock.

So I guess I have to wait until my new crystals come in to be sure. Too bad the US mail doesn't move today because of the holiday (yes that's selfish and I mean no disrespect).

-Nik

I got the chip working again! It was indeed the crystal that was bad on my Sanguino board. I was able to reprogram the low fuse of the atmega back to the internal clock for the time being so at least I can watch the blinking light until the new crystal shows up.

For anyone else having problems with fuse settings and clock types, I was able to use a trick from the AVRFreaks forums to get the atmega644P to respond to avrdude again:

I took a stock attiny2313, programmed the low fuse to 0x24, which enabled the clock output, and fed that into XTAL1 on the atmega644p (leaving XTAL2 unconnected). This allowed the system clock from the attiny to feed a 1 MHz signal into the atmega's clock source and everything was hunky dory again!

I've used this method now to fix all 3 chips that I thought were borked. It's way easier than trying to use HVPP, especially when all that's wrong is the clock input fuse.

This method would work for any ~1 MHz square wave input to the XTAL1 pin, so you could probably use a 555 timer or function generator, etc. I just happened to have a couple of attiny's still around.

-Nik

toomanyplugs Wrote:
-------------------------------------------------------
> Arduino "miniusb" USB to TTL converter, v3 from
> adafruit, tried to run it in bitbang mode based on
> this ExMrClean post, with the correct pinouts from
> the arduino page and the FTDI datasheet, including
> setting the CTS# and RTS# pins in avrdude.conf as
> negative pins (ie, SCK ~3). Inconclusive: I could
> never get avrdude to respond other than rc=-1
Hi Nik

It's great to hear that you have worked though your problems with the crystal and got your chips responding again.

Is the "miniusb" from adafruit a 5v or 3.3v part? Also you mentioned trying the CTS# and RTS# as negative pins, can ask why you thought that would necessary?

Fred

Fred,

the miniUSB is I believe a 5V part, according to the product page at adafruit. I took the CTS# and RTS# pins as negative (or active low) based on the FTDI datasheet for the FT232RL, and the corresponding Application Note for bitbang mode.

I never got it to work that way, and I think I just found the reason why while trying to get the firmware loaded using the miniUSB in TTL mode: the TX and RX pins are swapped on the pinout from the Arduino site description (I traced them from the SMD FTDI chip to the breakout pin header). I think this causes one to hook up the pins backwards when trying to build the TTL cable as described on the Mendel USB and Power page.

I'm going to swap those now and see if it makes a difference (I've been unable to load firmware all night, no matter what reset timing I try).

Nik

Confirmed. That solved it. miniUSB TX and RX pins are labeled backwards, now I can upload firmware right away!

Hi Nik

Ok thats good to note. Let me put some keywords in here so the search engines can find this post.

AVDUDE, BITBANGER, AVR BOOTSTRAP ISP, Adafuit miniusb Ardunio USB bootstrap load.

I'm having this same problem with trying to install a bootloader onto my newly built Sanguino using a ATmega1284P chip. However, I didn't have a resonator to use with my Sanguino 1.3a pcb build, so I used a 16Mhz crytal in its place. After reading this, I'm wondering if I would solve my problem by soldering in two 22pF ceramic disc caps along with the crystal to make things work?

lol. found this on another site while searching for this:
good caps, but they're labeled 104 ... which is 100nf instead of the 20-20pf that I should be using.
Yes putting that value of cap on a crystal is killing it. I bet it works the same without the crystal.
"So are you surprised using a capacitor 5000 times too big won't work."
Too funny....
This person posted their answer about this. and apparently using 20-22pf caps worked for him.
[forum.arduino.cc]

However, I think I'm a little confused on how I'm supposed to set fuses for my 1284P chip for an ext crystal vs a resonator.