I was only able to talk to my ATmega1284P once?

Hi all, I could use some help.

I built a Gen7 board around an ATmega1284P. The micro was completely blank, so I decided to use avrdude (in Linux) with a DAPA cable (http://reprap.org/wiki/Burning_the_Sanguino_Bootloader_using_DAPA) to flash a bootloader onto it. I executed the first command to set the fuses:

./avrdude -C ../etc/avrdude.conf -c dapa -p atmega1284P -P /dev/parport0 -B 5 -U lfuse:w:0xF7:m -U hfuse:w:0xDC:m -U efuse:w:0xFC:m

Everything seemed to work perfectly. The avrdude printed output as it wrote each set of fuses, verified that they were actually set, and stated that the programming attempt was successful.

Next, I tried to flash the bootloader:

./avrdude -C ../etc/avrdude.conf -c dapa -p atmega1284P -P /dev/parport0 -B 1 -U flash:w:../../../Gen7/bootloaders/Gen7/bootloader-1284P-20MHz.hex

but avrdude says "AVR device not responding" and "initialization failed, rc=-1". A Google search for this error yields lots of forum posts about the circuit being wired incorrectly and fuses being set incorrectly. I was able to talk to it once, which suggests my programmer is wired correctly, and I used the settings on the Gen7 page, which I suspect are known-working. Now if I try running the fuse command again, I get the same error message. I don't know if I've reached a problem with my microcontroller or my board. If it turns out to be the board, then I apologize for posting in the wrong forum. I just don't know where to look for the problem since I was able to successfully communicate with the board exactly once.

Any advice is greatly appreciated. Thanks!

Erik

Your success was with -B 5 while your failure was with -B 1. I never tried a parallel port programmer, but I've read they're slow. So you might have more success when continueing with -B 5 (or even -B 10).

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi Traumflug,

thanks for the suggestion. I've tried both the first and second instructions with several values of B each, including 5, up to 250. Each attempt yields the same error.

I've also tried without the -B flag, as instructed here: [reprap.org]

If I try a -F to force it to ignore the first error, then the second error states that the device ID is 0x000000 and is incorrect for an ATmega1284P, which is basically a reiteration that it can't talk to the device.

Erik

Edited 1 time(s). Last edit at 10/20/2012 09:24AM by Erik.

Another possible reason might be your oscillator for the CPU clock not working. Factory fresh ATmegas run off the internal clock, your fuse settings set that to an/the external crystal.

Is your 16/20 MHz crystal soldered carefully, are the capacitors nearby the right size, etc. ?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I used the 20 MHz crystal recommended in the Gen7 1.4.1 page (http://www.mouser.com/Search/ProductDetail.aspx?qs=65dIHZNch5tdetNmTbdTNw%3d%3d) and the recommended size of capacitors. I know the tolerances on those small caps can be pretty wide, so I even used a multimeter to check their capacitance and selected the closest I could find. I will verify that the oscillator circuit is soldered correctly.

Thanks Traumflug,

Erik

Erik

Couple of things to check that may help (Or not).

1. If you are attemtping to use the arduino IDE 1.0.1 or better they changed the default bootloader and they way it talks to the IDE/avrdude. from 1.0.1 onwards it uses optiboot. I have had a number of custom Arduno-ish projects stop talkign to the IDE because of this. Reloading with a suitably compiled copy of optiboot fixed this in all cases. The incorect signature is a classic case of this. With optiboot the correct device signature is returned.

2. The fuse settings need to be correct for clock source and freq etc. I have experienced the same with incorect fuse settings ie it programs fine but fails there after. The initial problem I had was that it looked like it worked OK but would fail when I tried to run anything (I was using amforth, resident forth, on them at the time).

Failing the two above I have no idea, but thought it worth mentioning them.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

The fuses most likely the culprit are your crystal setting, your Boot Reset setting or your Reset Disable setting.

Some of these the only way to fix is high voltage programming via a STK500/STK600 or a Dragon and this would prove difficult if you have a surface mount device.

I checked your fuse settings by entering them into one of the AVR Fuse Bit Calculators that can be found online, nothing jumps out at me, I would think if you're at 16Mhz to 20Mhz, running your crystal at Full Swing would be a good thing. However, if you did accidently foul up the fuse bit settings your chip could be bricked unless you know somebody with access to a programmer that is capable of doing Parallel High Voltage Programming, such as an STK500, STK600 or AVR Dragon.

Here's a link to one of the Fuse Calculators....

[www.engbedded.com]

If you're still having problems you could mail your chip to me if it's a socketed device and I can either un-brick it or mail you a new one.