Comments on: Atmel ATmega not programming over DAPA

Question: Atmel ATmega not programming over DAPA

Napierzaza — Sun, 25 Feb 2007 13:26:32 -0800

AVR Programming Hell: I've built my own Atmel programmer for my ATmega32 and it doesn't work a lick.

I built the following circuit to the letter and tested it over and over:
http://www.captain.at/electronics/atmel-programmer/

But nothing happens when I try to program it using UISP (in Debian Linux). I have modprobed my LPT port but it always fails after 32 tries to program the chip.

Does anyone know if this is a good schematic for DAPA programming for the Atmel?

I'm trying to verify that my LPT port works but am not sure how to via Linux.

By: flabdablet

flabdablet — Sun, 25 Feb 2007 14:57:00 -0800

What results do you get from the set.c and reset.c code that the page you linked to links to?

By: nickerbocker

nickerbocker — Sun, 25 Feb 2007 15:27:25 -0800

The forums on AVRFreaks.net will likely be more useful then this forum.

By: Napierzaza

Napierzaza — Sun, 25 Feb 2007 17:21:23 -0800

I can't get it to compile because of it not finding stdio.h, though I have gcc installed.

By: polyglot

polyglot — Sun, 25 Feb 2007 21:19:21 -0800

if it can't see stdio.h, something is very wrong with your gcc.

By: JackFlash

JackFlash — Sun, 25 Feb 2007 23:35:31 -0800

You can buy a programmer from Atmel for about $30 and the complete software IDE with editor, C compiler, linker and programmer is free for download. Requires Windows however. For that little bit of money I wouldn't bother messing with gcc and home grown hardware especially if you don't have the tools or skills for debugging it.

But if you insist, you must first get set.c and reset.c working and verify that the port pins toggle. If not, there is something wrong with your port device driver.

Make sure that you have power and ground attached to the AVR chip and the parallel port and verify with a voltmeter.

Beyond that there are any number of problems that could arise. For example the AVR defaults to using the internal oscillator at 1 MHz. The SPI clock must be less than 1/4 of the AVR frequency. That means SPI clock must toggle at no more than 250 KHz. I don't know if the programming software has any kind of timing built into it to make sure you don't exceed this frequency.

Reset must be asserted to the chip before programming and you must wait about 100 ms for the internal reset delay to time out before attempting programming. Both reset and SCK must be low before starting programming.

The first command sent to the device must be program enable command 0xAC530000. The device must echo back the byte 0x53. If not, then you have done something wrong and there is no point in looking farther. You should be able to step through the programmer application code to see if this is correct.