avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avrdude-dev] AVRDUDE and ATmega328p problems


From: Patrick .
Subject: [avrdude-dev] AVRDUDE and ATmega328p problems
Date: Wed, 14 Mar 2012 03:46:28 +0000

There is more then a few people having troubles with this chip and AVRDUDE and 
it seems not to be exclusive to any specific programmer or OS (not sure if it's 
a 64bit problem perhaps), the standard is a "avrdude: initialization failed, 
rc=-1" response and if forced passed that with -F swtich then you get a faulty 
device ID response

avrdude: Device signature = 0x000000
avrdude: Expected signature for ATMEGA328P is 1E 95 0F

I've had a look around in the code and the problem seems to be with these things

1. Power-up sequence:
Apply power between VCC and GND while RESET and SCK are set to “0”. In some sys-
tems, the programmer can not guarantee that SCK is held low during power-up. In 
this
case, RESET must be given a positive pulse of at least two CPU clock cycles 
duration
after SCK has been set to “0”.

2. Wait for at least 20ms and enable serial programming by sending the 
Programming
Enable serial instruction to pin MOSI.

3. The serial programming instructions will not work if the communication is 
out of synchro-
nization. When in sync. the second byte (0x53), will echo back when issuing the 
third
byte of the Programming Enable instruction. Whether the echo is correct or not, 
all four
bytes of the instruction must be transmitted. If the 0x53 did not echo back, 
give RESET a
positive pulse and issue a new Programming Enable command.

first of I haven't found any indication that SCK is set to 0 I can only find 
that RESET is pulled LOW also the fault response should merit a few re-tries 
(4?) with a RESET pulse before? 

I might be way off here being both tried and pushing the limits of my 
programming skills diving in to this but I've check, dubble checked, tripple 
checked and checked again that my connections from my programmer to my chip is 
correct and most people that have had the same problem have gotten it to work 
without any problems with other chips.

If anyone with a bit more code savy then me want to look in to this a good 
place to start would probably be 

Line 371 in usbtiny.c 
static int usbtiny_cmd(PROGRAMMER * pgm, unsigned char cmd[4], unsigned char 
res[4]) ... 

and track it from there

                                          

reply via email to

[Prev in Thread] Current Thread [Next in Thread]