Atmel ATmega not programming over DAPA
February 25, 2007 1:26 PM Subscribe
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.
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.
The forums on AVRFreaks.net will likely be more useful then this forum.
posted by nickerbocker at 3:27 PM on February 25, 2007
posted by nickerbocker at 3:27 PM on February 25, 2007
Response by poster: I can't get it to compile because of it not finding stdio.h, though I have gcc installed.
posted by Napierzaza at 5:21 PM on February 25, 2007
posted by Napierzaza at 5:21 PM on February 25, 2007
if it can't see stdio.h, something is very wrong with your gcc.
posted by polyglot at 9:19 PM on February 25, 2007
posted by polyglot at 9:19 PM on February 25, 2007
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.
posted by JackFlash at 11:35 PM on February 25, 2007
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.
posted by JackFlash at 11:35 PM on February 25, 2007
« Older Tools! Tools will solve all my problems! | How can I randomly display blocks of text in a... Newer »
This thread is closed to new comments.
posted by flabdablet at 2:57 PM on February 25, 2007