I am having some trouble with setting up an ATmega128 avr on breadboard. I am unable to burn bootloader or make any communication with the uc. I have done a LOT of digging, and tried the following things:
Using USBasp with -B4, then -B10 and -B64
Using ArduinoISP with the same speeds
Double, triple, quadruple, multiple checking all connection and soldering
Doubling every wire
Using 1MHz external clock and -B64, -B10
Using 5V external supply with common ground
Pulling PEN up/down
I think I have tried everything I found and I think the controller might be dead, because at first wiring I have made a mistake and connected m128 rst to programmer vcc, m128 vcc to programmer gnd, m128 gnd to programmer rst.
Does anybody have any other idea, or I might have fried the mcu?
I have tried another new ATmega128 on another, different board, with the same error. New means received from Atmel as engineering sample.
Is it possible that I have missed something, or burned both chip?
Assuming the wiring is right and the second chip wasn't connected to the bad wiring, I would try to connect the MCU you are trying to program to the Arduino using MISO-MISO, MOSI-MOSI, SCK-SCK and /RESET on the m128 to pin 10 (SS) of the Arduino.
Then upload the Arduino as ISP sketch and make a note of the COM port your arduino is connected to.
Then try a command prompt avrdude (form the Arduino folder ..\Arduino\hardware\tools\avr\bin) to see if you can talk to the m128 part:
somedude:
I would try to connect the MCU you are trying to program to the Arduino using MISO-MISO, MOSI-MOSI, SCK-SCK and /RESET on the m128 to pin 10 (SS) of the Arduino.
Then upload the Arduino as ISP sketch and make a note of the COM port your arduino is connected to.
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.
I managed to mess up the signature on one of my chips, but not to 000000, and it's still running.
If you want to keep troubleshooting and you've quadruple-checked the wiring and looked for shorts, you could try forcing the upload of the Blink sketch by using a command prompt avrdude with option -F.
Or, if you have a few parts, you could try a high voltage programming recovery of the MCU using this site as a reference, but you will need to map the pins to your Atmega.
By the way, use "code" tags, not "quote" tags for all code, not just the sketch, but also printout from the IDE including error messages. Proportional fonts - as well as embedded mark-up - thoroughly mangle the formatting.
I do not think connection is bad, because I soldered the wires to the pins and used gold plated connectors.
somedude:
I managed to mess up the signature on one of my chips, but not to 000000, and it's still running.
If you want to keep troubleshooting and you've quadruple-checked the wiring and looked for shorts, you could try forcing the upload of the Blink sketch by using a command prompt avrdude with option -F.
Or, if you have a few parts, you could try a high voltage programming recovery of the MCU using this site as a reference, but you will need to map the pins to your Atmega.
Sorry for being so brief, but I have to run.
Are you sure this would work for the mega128? I don't find similar named pins in the datasheet.
robinson01:
I do not think connection is bad, because I soldered the wires to the pins and used gold plated connectors.
Are you sure this would work for the mega128? I don't find similar named pins in the datasheet.
Absolutely not. I do not have one of the m128's so I can't test.
But the method should be the same, so it should work.
Since the chips might already be fried, you're not risking much, other than time.
The pin mapping should be based on the functions of the chip, not ports or digital pins.
This simple recovery tool connects to the ATtiny85's MISO, MOSI, SCK, /RESET and VCC pins, so I think that should work with any AVR, but I hope the experts on this forum can chime in.
I have managed to resolve the problem.
On the mega128 MOSI and MISO are NOT used for SPI programming, PDI and PDO is used. So the CORRECT connections are:
I found the problem. I removed xtal to use external clock, and forgot to put it back. I do not understad how did it work for the first time without xtal, but it works well now.
fuse from factory set for internal osc so no xtl required.
as far as the real isp pins, atmel had their head up their butt when creating that spec. this has caused endless pain over the years for noobs and experts alike. imo, except for the doc glitch, m128 one of the best avr deals going. you can buy several for the cost of one m1284 and often even cheaper than m328.
robinson01:
I did not modify factory set fuses for the first time,
that explains "how did it work for the first time without xtal". maybe fuses modified when attempting to download a program. specially if hardware is flaky and averdude asked the fateful question "change fuse back?". avrdude is the biggest chip killer i know. fans will deny and amazing this utility became so popular and adored. but then again same thing with windows so...
yes, but probably only of use to myself and the other two guys on this planet that still run real mode dos. many years ago i wrote a turbo-c program supporting both serial and isp flashing. even if i were to release to public probably of little value to anybody here.
imo the more practical solution for the masses would be to fix chip killer bugs in 'dude. ie the absolutely insane method of representing unused fuse bits and aforementioned "change fuse back?" fatal query. among others. this utility does seem to be the lesser of a few evils for those stuck in windows-land. 'nux-heads too.
as i mentioned the queer representation of fuse data is one. it causes some confusion among those who do not know that dude thinks unused bits are 0 when they should be 1. you can always reproduce this by simply comparing fuse bytes read with atmel data sheets. they do not match because creator got it in his head his way was better and from the start refused suggestions to change. apparently others rebuilding are afraid to deviate or just dont care.
another problem manifests with flaky hardware and may or may not be easy for you to duplicate. i see this with some of the "bad" usbasp discussed in the other thread today. also "good" ones with defective usb connection or programming cable that id way too long. usually says something like "fuse was originally 0x00, change it back?". iirc saying yes is what bricks the part. i just hit ctl-c to be safe and fix whatever caused that message. sometimes just using a different dongle.
I have noticed the unused fuse bits thing, and I suppose it is not a big deal if they are set to 0 or 1. If the fuses are read as 0 because of flaky hardware or connections and is set "back" to 0 successfully, then I probably would not consider that to be a bug. Safeguards could be added as a feature and that would probably be a good idea. I do agree these things are annoying, and can confuse users. I don't know if the part could be considered bricked or killed just because of fuse bits set to an inconvenient value, because for the price of a transistor, a couple of resistors, and a 12V battery they can be set back to normal using HV programming.