Hi there,
I am getting some strange problems when trying to read eeprom or flash contents on an ATmega 128 via the ISP header
avrdude version 5.10, tried on two machines both Linux in case the USB port on one was mucking me about
buspirate version 5.10, passes all self tests etc
If I connect with avrdude -v -p m128 -c buspirate -P /dev/ttyUSB0
Then all seems well I can read the fuse states etc
If I try and grab the flash or eeprom contents then it will get to a random percentage and hang (rx and tx lights stop flashing on the BP) and just sit there (see the full output below) It has once managed to grab the whole 4k of eeprom but I have never managed over 10% of the flash and sometimes it stops at around 4.
I've tried just letting the BP power my chip up via the 3.3v line and by just tying grounds together and powering up the PCB I am reading from...no difference...tried eliminating any external interference etc and on the circuit in question the relevant legs of the AVR don't go to anything but the ISP pads....Tried on 2 sample boards both of which I know are working fine.
On the next attempt the BP will be hung.....Trying to get a dump of the contents before I flash the chip in case it all goes wrong and I presume that if the read is failing thew write probably will too. I've seen it do little pauses before it fails sometimes..but when it stops proper I can go and make a cup of tea and it hasn't moved.
Any ideas anyone ?, complete output below
wstallwood@bench-thinkpad:~$avrdude -v -p m128 -c buspirate -P /dev/ttyUSB0 -U flash:r:test
avrdude: Version 5.10, compiled on Jun 29 2010 at 03:44:14
Copyright (c) 2000-2005 Brian Dean,
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/wstallwood/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyUSB0
Using Programmer : buspirate
AVR Part : ATMEGA128
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 4 12 64 0 no 4096 8 0 9000 9000 0xff 0xff
flash 33 6 128 0 yes 131072 256 512 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 4 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : BusPirate
Description : The Bus Pirate
Detecting BusPirate...
avrdude: buspirate_readline(): #
avrdude: buspirate_readline(): RESET
avrdude: buspirate_readline():
**
avrdude: buspirate_readline(): Bus Pirate v3a
** Bus Pirate v3a
avrdude: buspirate_readline(): Firmware v5.10 (r559) Bootloader v4.4
** Firmware v5.10 (r559) Bootloader v4.4
avrdude: buspirate_readline(): DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
** DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
avrdude: buspirate_readline(): took this out because it was hitting the forum spam filter
** and here
avrdude: buspirate_readline(): HiZ>
**
BusPirate: using BINARY mode
BusPirate binmode version: 1
BusPirate SPI version: 1
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e9702
avrdude: safemode: lfuse reads as BF
avrdude: safemode: hfuse reads as C2
avrdude: safemode: efuse reads as FF
avrdude: current erase-rewrite cycle count is -50462977 (if being tracked)
avrdude: reading flash memory:
Reading | ## | 3% 20.43s
Hi digimatic,
I'm sorry, I'm not sure what's going on. If I understand, you only have the single chip, and cannot test programming with another chip. As far as I know, programming should work on 168/368/etc.
You could log the serial port traffic and we could attempt to debug it, but I don't know enough about AVRdude to get very far. Maybe the AVRDude mailing list has suggestions too.
What you could also do is add '-v -v -v -v -v -v' to your make command. That will output all available debug information (can see every communication back and fourth and hopefully see whats dying.)
eg: wstallwood@bench-thinkpad:~$avrdude -v -p m128 -c buspirate -P /dev/ttyUSB0 -U flash:r:test
to: wstallwood@bench-thinkpad:~$avrdude -v -v -v -v -v -v -v -p m128 -c buspirate -P /dev/ttyUSB0 -U flash:r:test
I dont know off the top my head how many -v's are max but i think its 4 or 5. going over doesnt hurt there just ignored.
Also a note; I see you are using 3.3v. I remember somewhere else on this forum someone having an issue with the AVRdude support and when he switched to the onboard 5v instead it worked. Also a note; you should set -b 115200 and -B 5 in that command line aswell.
One more big note i overlooked. Unless your using an ATMEGA128L you cannot run or program that chip at 3.3v; min is 4.5v.
I would try at 5v and I bet you will be fine.
Also something you could try use the bus pirate to enter avrdude terminal mode; just use the same command with -t instead of -U and all that. Just programmer, port, baud, speed, and all that with -t.
Then in terminal mode you can try individual commands; eg read a certain section of flash; read just the low fuse bits; read all eeprom; and so n... and perhaps see where its stopping; see if its a specific command.
also have you tried a 2nd ATMEGA?