ATmega8 with arduino as ISP programming issues...

[GabYoung92]

I have searched around for answers but I haven't been able to get my problem solved

After building myself a linear PSU, I wanted a voltage panel.  I did not like any pre-made ones so I decided to make one myself using 4x 7-segs and a microcontroller using the chips' ADC.

I bought an ATmega8 chip and did some basic programming with it using my freetronics Eleven (UNO) to program it as an ISP.  (I did not burn a bootloader as I don't need it).  Using the Arduino IDE (1.0.1) I was able to program the blink program onto the ATmega8 chip using my Eleven as the ISP. I modified the program and re-uploaded to the chip a couple of times with no problems.  Throughout testing of the chip, I did not have an external oscillator connected and it still worked.

Now a week later, after writing my program.. I can not seem to get it to upload!  I have checked my wiring over and over, pinouts, and voltages... No luck!

But when I select the "Arduino NG or older w/ Atmega8" (which I used when i first got the chip) I keep getting the error
- "Yikes! Invalid device signature.Double check connections and try again, or use -F to overridethis check.".

I have followed http://arduino.cc/forum/index.php?topic=112452.0 and I get an error of: avrdude:
- "stk500_getsync(): not in sync: resp=0x66"

I'm lost because I know I had it working.. 

Any ideas of what I could do to fix this?

[Psi]

If you have another ATMEGA8 lying around, just try swap them around. It's so easy to do you might as well try it first.
It proves the chip and fuse bits aren't the issue.

You don't seem to have any resistors on those LEDs?
If their being driven directly from an I/O port, and haven't exploded, it will be because they're pulling the I/O voltage down by a few volts.
This maybe preventing the programming signals from being detected.
(Note if the programmer board has its own resistors then you can ignore this comment)

Double check the
- Power and Ground connections
- RESET, SCK, MISO, MOSI and remember M=master S=slave I=input O=output
- Remove that pullup resistor you have between RESET and VCC (It doesn't need it and if it's pulling too hard it maybe causing issues)

When checking connections connect the DMM probe between the actual pin of the IC and the header of your programmer. This checks all connection points along the way.
Also check all pins for a short to their adjacent pins.

Put your program aside and try a brand new program. Just something simple that blinks a led.

If it still doesn't work then pull all the wires and chips out of the breadboard. Rotate the breadboard 180 degrees and rebuild your circuit.
Often you get bad connections with breadboards.

Sometimes with small circuits it's quicker to just rebuild than to try and track down the problem.

[GabYoung92]

I've only got the one chip (Other than an ATmega8515 that I couldn't program?)

Nope I didn't have resistors connected. This is how I did it the first time. 

I've now used a resistor for the status LED's (driven from the programmer) and I've removed the pullup resistor as well. I tried to upload again and got:

- avrdude: Expected signature for ATMEGA8 is 1E 93 07
         Double check chip, or use -F to override this check.

Re-uploading gives me :

-avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.

The chip is an ATmega8  (picture attached)

I deleted my Arduino IDE, re-downloaded the latest and tried, no luck  
I'm thinking that I may have to connect an external oscillator.

[GabYoung92]

I've checked all the connections for continuity.  No issues there.  I checked the pins on each ATmega.  And there are no shorts.

And I've tried putting the chip on a different breadboard, still the same issues.


I've got a feeling that I'm experiencing what's written in this thread:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=99652

[Psi]

Sometimes fuse bits do get corrupted, but normally it happens while your working not between putting the project aside and picking it up again later.

If it was me, i'd try and reprogram it with a simple printer port connection. That would rule out the programer board.

An external oscillator is worth a try

[GabYoung92]

Damn,  I had ordered some but still waiting for them to arrive.  Would it be possible to link off of the oscillator on the Arduino board connected to the Atmega328p?

[Psi]

There is a website somewhere that shows someone resetting the fuse bits on a ATMega using some switches to simulate the high voltage programming mode.

ie, entering the programming mode and sending commands by hand with switches on all the i/o pin!

I cant find the url though, also not sure if it was an atmega8.

[amyk]

There is a website somewhere that shows someone resetting the fuse bits on a ATMega using some switches to simulate the high voltage programming mode.

ie, entering the programming mode and sending commands by hand with switches on all the i/o pin!

I cant find the url though, also not sure if it was an atmega8.

This?

http://ilikebugs.blogspot.com/2006/09/avr-necromancer.html

A bit tedious, but it works if you follow the instructions in the datasheet. I've done it a few times.

[Psi]

yeah, i think that's the one.

I remember it having more detail though

[Erwin Ried]

Usually the programmers set the lock bits to avoid reprograms I have lots of attinys dead because of that, you can build an HV programmer and it works but I am waiting now a attiny resetter to automate the process.

Check this: http://www.microcontrollerprog.com

[alm]

Why would you need a HV programmer to clear the lock bits? Erasing the chip should clear them.

If you screwed up the clock fuses (eg. external clock), you may need to provide a clock source. You can usually feed it a square wave, unless it was set to LF crystal, then you need a 32 kHz crystal. If you set the RSTDISBL fuse, then you do need a HV programmer to clear it.

Like Psi, I would also suspect bad wiring or poor breadboard contacts.

[Psi]

The other thing you can get is shorts between breadboard sections when you put a long wire into the board.
The wire can sometimes bend over inside and start moving sideways until it hits another conductor.

It tends to happen on the cheap breadboards.

You do have the programmer MOSI connected to slave MISO and vice versa right?

[GabYoung92]

The other thing you can get is shorts between breadboard sections when you put a long wire into the board.

I've made my own jumper leads using pin headers and heat shrink to cover the joint. So should be no issues there, hopefully. 


I bought another ATmega8, hooked everything up (programmer and the circuit), programmed the chip and away it went with no problems. Displays lit and did exactly what I wanted.  I modified my code a little and went to re-upload it (Didn't touch any wires) and now from the Arduino IDE, i'm getting:

avrdude: verification error, first mismatch at byte 0x02e9
         0xe9 != 0xe0
avrdude: verification error; content mismatch

My code is designed to light one segment, darken it, and light the next one.  Sweeping all the segments to have a constant display.  Now it is slowly scanning across (about 1 second to do a sweep)  ?

[amyk]

Noisy environment during programming can cause that. Ensure the wires to the programmer are as short as possible and located away from any sources strong EM fields.

It's not behaving as you want because the code has been corrupted. Do a full chip erase, and try again.

Also keep in mind ESD precautions.

[GabYoung92]

Noisy environment during programming can cause that.

Do a full chip erase, and try again.

Sounds likely.  I am using decoupling caps.  Is the erase possible using the Arduino as the ISP?

Thanks

[TerminalJack505]

Noisy environment during programming can cause that. Ensure the wires to the programmer are as short as possible and located away from any sources strong EM fields.

It's not behaving as you want because the code has been corrupted. Do a full chip erase, and try again.

Also keep in mind ESD precautions.

Also, put some caps on your breadboard.  Put a small cap (~10uF) across the power rail and ground and put a 100nF across the MCU's power pins, VCC and GND.

[GabYoung92]

Also, put some caps on your breadboard.  Put a small cap (~10uF) across the power rail and ground and put a 100nF across the MCU's power pins, VCC and GND.

Yup, I'm using decoupling capacitors on my breadboard.  I'm using 10uF across the rails, and 10nF greencaps directly next to the chip.

I've tried to upload

Code: [Select]

void setup()
{}

void loop()
{}
and i'm still getting a mismatch error. 


Is the device now locked from any more programming?

[Psi]

avrdude: verification error, first mismatch at byte 0x02e9
         0xe9 != 0xe0
avrdude: verification error; content mismatch

This means the micro is responding OK and being programmed with your code, but when it read the code back out of the micro the two didn't match.
So there's a corruption happening somewhere.
This is almost always a bad connection, noise on the power/ground connection or overly long cables.


Sometimes i see micros that will run even with a power or ground wire disconnected as the power feeds in through one of the I/O ports from somewhere else.
In this situation you get all sorts of errors like that.
Maybe put an LED+resistor across the ATMega8 vcc/gnd pins to check there is voltage/current there. It should not dim when you try and program the chip.

Also be sure you have connected all VCC and all GND pins. As well as AVCC.
You shouldn't leave any power/ground pins unconnected.



When you get stuff like

Expected signature for ATMEGA8 is 1E 93 07
  -avrdude: Yikes!  Invalid device signature.

That means the MCU isn't responding at all.
It could be broken, unconnected or have its fuse bits set to ignore reprogramming

[GabYoung92]

I have checked my voltages on the pins.  Any pin that needs 5V, I've measured around the range of 5.1volts. 

GND pin 8 connected to GND
GND pin 22 connected GND

VCC pin 7 connected to +5V
AVCC pin 20 connected to +5v

AREF pin 21 floating.

I've attached extra code to set digital pin 0 (pin2) to high.  I'm still only reading 0.1V on that pin.    I'll pull all the wires out and start again?

[TerminalJack505]

Have you tried running avrdude manually from the command line?  You might try running it to see if you can get into terminal mode. 

I'm guessing you'd type something like this:

avrdude -p m8 -c arduino -t

I don't know if you need the -P option or not.  You might mess around with the different command line option that affect timing to see if they help.  I suspect your MCU is running at 1 MHz but your programmer is trying to upload data at a faster rate.

[GabYoung92]

Code: [Select]

avrdude -p m8 -c arduino -P COM7 -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: Expected signature for ATMEGA8 is 1E 93 07
         Double check chip, or use -F to override this check.

avrdude done.  Thank you.

I posted a link earlier of a tutorial I followed.  I added to the board.txt file this: and I was using this to utilize the internal oscillator

Code: [Select]

atmega8u.name=ATmega8-noxtal @8MHz

atmega8u.upload.protocol=arduino
atmega8u.upload.maximum_size=7168
atmega8u.upload.speed=19200

atmega8u.bootloader.low_fuses=0xe4
atmega8u.bootloader.high_fuses=0xc2
atmega8u.bootloader.path=atmega8_noxtal
atmega8u.bootloader.file=ATmegaBOOT.hex
atmega8u.bootloader.unlock_bits=0x3F
atmega8u.bootloader.lock_bits=0x0F

atmega8u.build.mcu=atmega8
atmega8u.build.f_cpu=8000000L
atmega8u.build.core=arduino
atmega8u.build.variant=standard

[Psi]

From reading that config file am i right in assuming you're trying to run the onboard RC osc at its max 8mhz?
Because i always had programming issues doing that myself. 1Mhz was fine but anything above 4mhz on the RC i found unstable for ISP programming.
The issue went away using a crystal instead.

Have you tried running avrdude manually from the command line?  You might try running it to see if you can get into terminal mode. 

I'm guessing you'd type something like this:

avrdude -p m8 -c arduino -t

I don't know if you need the -P option or not.  You might mess around with the different command line option that affect timing to see if they help.  I suspect your MCU is running at 1 MHz but your programmer is trying to upload data at a faster rate.

Yeah, slowing down the data rate is definitely something to try.
-i 20 adds some ISP delay but I dunno if that works for arduino programmers?

[TerminalJack505]

That signature must be of the chip on the Arduino board.  At least it matches that of an ATmega328.  Maybe that's not the way you launch avrdude when you're using the Arduino board as the programmer.  It isn't something I've ever tried to do myself.

[Psi]

Yes, that command seems to be trying to reprogram your programmer, not your ATmega8
AVRDUDE was looking for an ATmega8 and found a 0x1e950f (ATmega328) so aborted the process.

[TerminalJack505]

I have to wonder if your Arduino has lost it's 'programmer' firmware.  Have you tried re-uploading it?

[GabYoung92]

I have to wonder if your Arduino has lost it's 'programmer' firmware.  Have you tried re-uploading it?

Shouldn't have... I've reaupload the ArduinoISP sketch again and reconnected up the ATmega8 via http://arduino.cc/en/Tutorial/ArduinoISP  (bottom left image)

Code: [Select]

avrdude -p m8 -c arduino -P COM7 -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: Expected signature for ATMEGA8 is 1E 93 07
         Double check chip, or use -F to override this check.

avrdude done.  Thank you.
Yup it's reading the signature of the arduino 328p chip, not the ATmega8...  should I be using any other commands for AVRdude?

Bit of a bummer really... New chip, got to upload once, now same issues.  Should have burnt the bootloader?

[TerminalJack505]

It's interesting that your config file is using a slower upload speed than the webpage you linked to.

Your config has this:

atmega8u.upload.speed=19200

...and one of the pages has this:

atmega8noxtal.upload.speed=38400

Have you tried both just in case?

The only other thing I can think of is there's an issue with the reset line.  Maybe the Arudino programmer isn't pulling it low.

[GabYoung92]

It's interesting that your config file is using a slower upload speed than the webpage you linked to.

Your config has this:

atmega8u.upload.speed=19200

...and one of the pages has this:

atmega8noxtal.upload.speed=38400

Have you tried both just in case?

The only other thing I can think of is there's an issue with the reset line.  Maybe the Arudino programmer isn't pulling it low.

Yes, I had changed the speed.

Using 38400, The error led just lights and I get:
avrdude: stk500_getsync(): not in sync: resp=0x66

Using 19200, There is programming via the status led, and I get:
avrdude: verification error, first mismatch at byte 0x00c0
         0x64 != 0x60
avrdude: verification error; content mismatch

Using 9600, I get a solid error status and:
avrdude: stk500_getsync(): not in sync: resp=0xff

[TerminalJack505]

I notice that you said you didn't burn a boot loader.  I haven't looked too close but the fuse bits in that config look like they are setup for a boot loader.

[GabYoung92]

I notice that you said you didn't burn a boot loader.  I haven't looked too close but the fuse bits in that config look like they are setup for a boot loader.

No, I haven't burnt one.  I was going to avoid burning one as I was going to upload the program to the chip and put it into a board stuck in my power supply so I didn't see the point of using it.  Also I don't have any 16Mhz X-TAL, so i was trying to use the internal clock as timing is not critical. 


Also, Thanks for your help. I hope I'm not making you pull your hair out

[TerminalJack505]

I've attached extra code to set digital pin 0 (pin2) to high.  I'm still only reading 0.1V on that pin.    I'll pull all the wires out and start again?

Is this the pin that connects to the ATmega8's RESET# pin?  Is this change something you did in the Arduino ISP code?

[Psi]

How come the high fuse bits are set C2

atmega8u.bootloader.high_fuses=0xc2
atmega8u.bootloader.low_fuses=0xe4

C2 = 1100 0010

This sets CKOPT to 0 (programmed)

ATMega8 datasheet says CLOPT should be un-programmed when using internal RC clock

Un-programmed is the default so this may explain why it worked the first time.

The low fuse value E4 seems ok, but it does set CKSEL to 0100 which for internal RC is 8mhz which i had issues with.

[GabYoung92]

I've attached extra code to set digital pin 0 (pin2) to high.  I'm still only reading 0.1V on that pin.    I'll pull all the wires out and start again?

Is this the pin that connects to the ATmega8's RESET# pin?  Is this change something you did in the Arduino ISP code?

The arduino has the arduinoISP sketch on it. I was trying to upload my code to the ATmega8 chip using the arduino as the ISP. I added code into my program to switch HIGH an unused digital pin (pin 0, physical pin 2) on the ATmega8 chip to do some debugging.  Pin 1 of the chip is the Reset pin, pin 2 is digital pin 0.  There is no shorts between these two pins. 

[GabYoung92]

How come the high fuse bits are set C2

atmega8u.bootloader.high_fuses=0xc2
atmega8u.bootloader.low_fuses=0xe4

C2 = 1100 0010

This sets CKOPT to 0 (programmed)

ATMega8 datasheet says CLOPT should be un-programmed when using internal RC clock

Un-programmed is the default so this may explain why it worked the first time.

The low fuse value E4 seems ok, but it does set CKSEL to 0100 which for internal RC is 8mhz which i had issues with.

I see where you are coming from.  So I'm guessing I need to obtain an external oscillator and reprogram the high fuses or erase the device?

[TerminalJack505]

The arduino has the arduinoISP sketch on it. I was trying to upload my code to the ATmega8 chip using the arduino as the ISP. I added code into my program to switch HIGH an unused digital pin (pin 0, physical pin 2) on the ATmega8 chip to do some debugging.  Pin 1 of the chip is the Reset pin, pin 2 is digital pin 0.  There is no shorts between these two pins.

Ah.  I see.

I notice that you said you didn't burn a boot loader.  I haven't looked too close but the fuse bits in that config look like they are setup for a boot loader.

No, I haven't burnt one.  I was going to avoid burning one as I was going to upload the program to the chip and put it into a board stuck in my power supply so I didn't see the point of using it.  Also I don't have any 16Mhz X-TAL, so i was trying to use the internal clock as timing is not critical. 


Also, Thanks for your help. I hope I'm not making you pull your hair out

No problem.  I'm probably not going to be of much help since I've never tried using a Arduino for ISP before. 

I'm guessing you don't happen to have an AVR ISPMKII, JTAG ICE or Dragon?

[GabYoung92]

I'm guessing you don't happen to have an AVR ISPMKII, JTAG ICE or Dragon?

unfortunately not.  That's why I'm using the Arduino    

Just gave a quick ebay search.  Should I get myself a one hung low one to play around with or go the extra and get a brand name one?

[TerminalJack505]

...I'm slowly reading through those webpages you linked to.

Apparently avrdude will talk to the Arduino ISP using the AVR ISP mkII protocol.

If so then you should be able to run:

avrdude -p m8 -c avrispmkII -P com7 -t

...to get into terminal mode.  You might try it and see if you can talk to the device and read the fuse bits.

[TerminalJack505]

Just gave a quick ebay search.  Should I get myself a one hung low one to play around with or go the extra and get a brand name one?

Personally, for the money I'd get an Atmel brand.  That's a topic that will start a war of religions, though, so that's just between you and me.   

[Psi]

I see where you are coming from.  So I'm guessing I need to obtain an external oscillator and reprogram the high fuses or erase the device?

I'm not sure, CKOPT just adds a capacitor to ground for doing an external RC osc. It may still work with it enabled.

I've not used Arduinos before, only raw AVRs with avrdude. So i'm not sure exactly how the arduino ide fits into things but..

I can't see it ever working until avrdude finds the correct signature.
From your post on the previous page we can see it's finding the programmer mcu and not the ATMega8.
So there must be a setting wrong somewhere.

However.

avrdude: verification error, first mismatch at byte 0x00c0
         0x64 != 0x60
avrdude: verification error; content mismatch

This text you posted indicates that the programming has actually started but has encountering a mismatch error. Which would indicate that the signature was correct (or it wouldn't have started)

So i'm quite confused.
But if i had to guess i'd say your ATmega8 is still ok and running off the internal RC oscillator correctly.
If a clock fuse had been set wrong and the RC osc stopped working you wouldn't be getting mismatch errors.

[GabYoung92]

...I'm slowly reading through those webpages you linked to.

Apparently avrdude will talk to the Arduino ISP using the AVR ISP mkII protocol.

If so then you should be able to run:

avrdude -p m8 -c avrispmkII -P com7 -t

...to get into terminal mode.  You might try it and see if you can talk to the device and read the fuse bits.

Using -c arduino I get incorect signature (the 328p responds)

Using -c avrispmkII I get a solid error led and:

avrdude -p m8 -c avrispmkII -P com7 -t
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout

Just gave a quick ebay search.  Should I get myself a one hung low one to play around with or go the extra and get a brand name one?

Personally, for the money I'd get an Atmel brand.  That's a topic that will start a war of religions, though, so that's just between you and me.   

Fair enough.  I may get a cheapie for now.  Then later down the track get a proper programmer. 

[GabYoung92]

PSI, that's what has had my confused.

It needs an upload bitrate of 19200 to work at all, status lights display programming correctly, it's just the verification that's the issue.

[TerminalJack505]

Using -c avrispmkII I get a solid error led and:

avrdude -p m8 -c avrispmkII -P com7 -t
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout

You might need to use either the -b option or the -B option.  Either that or the -P option will be something different.

For now try using -B...

avrdude -p m8 -c avrispmkII -P com7 -B 100 -t

[Psi]

So you get the avrdude progress bar ####### etc...
It just says mismatch during the read back part?

[GabYoung92]

TerminalJack505,

Code: [Select]

avrdude -p m8 -c avrispmkII -P com7 -B 100 -t
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
^C
Psi,

No there's no progress bar (I'm assuimging you mean in the Arduino IDE)  Just going straight to and error.


Not sure what I've done now, but all I'm getting is an invalid signature error. 

[TerminalJack505]

You might try this then...

avrdude -p m8 -c avrispmkII -P com7 -b 19200 -t

[GabYoung92]

You might try this then...

avrdude -p m8 -c avrispmkII -P com7 -b 19200 -t

I just get:

Code: [Select]

avrdude: stk500v2_ReceiveMessage(): timeout
However....

Code: [Select]

C:\Users\Gabriel Young\Desktop\Freetronics\arduino-1.0.1\hardware\tools\avr\bin>
avrdude -p m8 -c AVRisp -P com7 -b 9600 -t
avrdude: stk500_getsync(): not in sync: resp=0xff

avrdude done.  Thank you.


C:\Users\Gabriel Young\Desktop\Freetronics\arduino-1.0.1\hardware\tools\avr\bin>
avrdude -p m8 -c AVRisp -P com7 -b 38400 -t
avrdude: stk500_getsync(): not in sync: resp=0x66

avrdude done.  Thank you.


C:\Users\Gabriel Young\Desktop\Freetronics\arduino-1.0.1\hardware\tools\avr\bin>
avrdude -p m8 -c AVRisp -P com7 -b 19200 -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.08s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

[TerminalJack505]

Well, you might as well use the -F option just so you can maybe get a little peek at what it's connecting to.

[GabYoung92]

Well, you might as well use the -F option just so you can maybe get a little peek at what it's connecting to.

Code: [Select]

avrdude -p m8 -c AVRisp -P com7 -b 19200 -t -F

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.07s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATMEGA8 is 1E 93 07
avrdude> ?
>>> ?
Valid commands:

  dump   : dump memory  : dump <memtype> <addr> <N-Bytes>
  read   : alias for dump
  write  : write memory : write <memtype> <addr> <b1> <b2> ... <bN>
  erase  : perform a chip erase
  sig    : display device signature bytes
  part   : display the current part information
  send   : send a raw command : send <b1> <b2> <b3> <b4>
  parms  : display adjustable parameters (STK500 only)
  vtarg  : set <V[target]> (STK500 only)
  varef  : set <V[aref]> (STK500 only)
  fosc   : set <oscillator frequency> (STK500 only)
  sck    : set <SCK period> (STK500 only)
  spi    : enter direct SPI mode
  pgm    : return to programming mode
  help   : help
  ?      : help
  quit   : quit

Use the 'part' command to display valid memory types for use with the
'dump' and 'write' commands.

avrdude> sig
>>> sig

Reading | ################################################## | 100% 0.08s

Device signature = 0x000000

avrdude> part
>>> part

AVR Part                      : ATMEGA8
Chip Erase delay              : 10000 us
PAGEL                         : PD7
BS2                           : PC2
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                       Pol
led
  Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadB
ack
  ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ------
---
  eeprom         4    20   128    0 no        512    4      0  9000  9000 0xff 0
xff
  flash         33    10    64    0 yes      8192   64    128  4500  4500 0xff 0
x00
  lfuse          0     0     0    0 no          1    0      0  2000  2000 0x00 0
x00
  hfuse          0     0     0    0 no          1    0      0  2000  2000 0x00 0
x00
  lock           0     0     0    0 no          1    0      0  2000  2000 0x00 0
x00
  calibration    0     0     0    0 no          4    0      0     0     0 0x00 0
x00
  signature      0     0     0    0 no          3    0      0     0     0 0x00 0
x00

avrdude>

[TerminalJack505]

That's encouraging.  Try the following...

dump lfuse 0 0
dump hfuse 0 0
dump lock 0 0
dump signature 0 3

[GabYoung92]

That's encouraging.  Try the following...

dump lfuse 0 0
dump hfuse 0 0
dump lock 0 0
dump signature 0 3

I'm hoping that I have done this correctly:

Code: [Select]

avrdude -p m8 -c AVRisp -P com7 -b 19200 -t -F

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.08s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATMEGA8 is 1E 93 07
avrdude> dump lfuse 0 0
>>> dump lfuse 0 0

avrdude> dump hfuse 0 0
>>> dump hfuse 0 0

avrdude> dump lock 0 0
>>> dump lock 0 0

avrdude> dump signature 0 3
>>> dump signature 0 3
0000  00 00 00                                          |...             |

avrdude> sig
>>> sig

Reading | ################################################## | 100% 0.07s

Device signature = 0x000000

avrdude> part
>>> part

AVR Part                      : ATMEGA8
Chip Erase delay              : 10000 us
PAGEL                         : PD7
BS2                           : PC2
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                       Pol
led
  Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadB
ack
  ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ------
---
  eeprom         4    20   128    0 no        512    4      0  9000  9000 0xff 0
xff
  flash         33    10    64    0 yes      8192   64    128  4500  4500 0xff 0
x00
  lfuse          0     0     0    0 no          1    0      0  2000  2000 0x00 0
x00
  hfuse          0     0     0    0 no          1    0      0  2000  2000 0x00 0
x00
  lock           0     0     0    0 no          1    0      0  2000  2000 0x00 0
x00
  calibration    0     0     0    0 no          4    0      0     0     0 0x00 0
x00
  signature      0     0     0    0 no          3    0      0     0     0 0x00 0
x00

avrdude>

[Psi]

Looks like it's communicating with thin air.

[GabYoung92]

Looks like it's communicating with thin air.

Which is the opposite of what I want

I noticed in the help menu, an option to erase chip...  Should I give this a go?

[TerminalJack505]

That's weird.  It didn't read any of the fuse settings and the signature is blank.  I'm pretty sure that's how you read the fuse bits.

You might have some options you can set via the 'params' command as well since your Arduino is emulating an AVR ISP.

There's a timing-related parameter in there that I've had to change a few times.

[GabYoung92]

That's weird.  It didn't read any of the fuse settings and the signature is blank.  I'm pretty sure that's how you read the fuse bits.

You might have some options you can set via the 'params' command as well since your Arduino is emulating an AVR ISP.

There's a timing-related parameter in there that I've had to change a few times.

I'm all ears to try anything.

[TerminalJack505]

Try dumping some of the flash memory.  I'm just curious if you're really communicating with the chip.

[GabYoung92]

Try dumping some of the flash memory.  I'm just curious if you're really communicating with the chip.

ATmega8 chip I got today:

Code: [Select]

avrdude> dump flash
>>> dump flash
0000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

avrdude>
ATmega8 chip I bought a couple of days ago:

Code: [Select]

avrdude> dump flash
>>> dump flash
0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude>

[Psi]

Does your computer have a printer port (LPT)

You can pretty much wire them up pin for pin to any AVR and reprogram it with avrdude

avrdude -i 20 -p m8 -P lpt1 -c bsd -e -U flash:w:mycode.hex

You need to get 5V from somewhere else though, there is no 5V out on a printer port sadly.

The pinouts can be found here
http://www.pocketmagic.net/wp-content/uploads/2009/02/avr-bsd.png
The labels given (MISO etc.) are the slave micro pins. so just match them up 1:1

The 4 resistors can be anything less than 1K, i normally use 220R or sometimes leave them out completely (risky).

[TerminalJack505]

So what does the 'parms' command return?  There's a 'SCK period' setting.  My ISP returns 10.37 us.  I'm curious what yours is.

Code: [Select]

~ > avrdude -p m8 -c avrispmkII -P usb -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9307
avrdude> parms
>>> parms
Vtarget         : 5.0 V
SCK period      : 10.37 us
avrdude>


[GabYoung92]

Does your computer have a printer port (LPT)

You can pretty much wire them up pin for pin to any AVR and reprogram it with avrdude

avrdude -i 20 -p m8 -P lpt1 -c bsd -e -U flash:w:mycode.hex

The pinouts can be found here
http://www.pocketmagic.net/wp-content/uploads/2009/02/avr-bsd.png
The labels given (MISO etc.) are the slave micro pins. so just match them up 1:1

You need to get 5V from somewhere else though, there is no 5V out on a printer port sadly.

I'll have to try that tomorrow on another computer (My laptop doesn't have a LPT).  Power will be no problem

TerminalJack505:

Code: [Select]

avrdude> parms
>>> parms
Vtarget         : 0.0 V
Varef           : 0.0 V
Oscillator      : Off
SCK period      : 0.1 us
avrdude>
A whole load of nothing...  by the looks of it.  Using my DMM, GND to VCC has 5.14V




http://www.logikdev.com/2011/02/15/reset-clock-fuse-bits-on-avr/
I know that's not for my chip, but maybe?

[TerminalJack505]

Just realized that I gave you the wrong commands for reading the fuses.  Try these...

dump lfuse 0 1
dump hfuse 0 1
dump lock 0 1

[GabYoung92]

Just realized that I gave you the wrong commands for reading the fuses.  Try these...

dump lfuse 0 1
dump hfuse 0 1
dump lock 0 1

Code: [Select]

avrdude> dump lfuse 0 1
>>> dump lfuse 0 1
0000  00                                                |.               |

avrdude> dump hfuse 0 1
>>> dump hfuse 0 1
0000  00                                                |.               |

avrdude> dump lock 0 1
>>> dump lock 0 1
0000  00                                                |.               |

avrdude>

[TerminalJack505]

Those fuse settings aren't right, obviously.

That SCK period may be too fast.  Try changing it with the SCK command.

Code: [Select]

sck 11

[GabYoung92]

Those fuse settings aren't right, obviously.

That SCK period may be too fast.  Try changing it with the SCK command.

Code: [Select]

sck 11

I wired up an ATmega8515 and I'm getting the same thing.  Maybe it's the arduino or the protocol that's causing errors?

Code: [Select]

avrdude -p m8515 -c AVRisp -P com7 -b 19200 -t -F

avrdude: please define PAGEL and BS2 signals in the configuration file for part
ATMEGA8515
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.07s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATMEGA8515 is 1E 93 06
avrdude> sig
>>> sig

Reading | ################################################## | 100% 0.07s

Device signature = 0x000000

avrdude> part
>>> part

AVR Part                      : ATMEGA8515
Chip Erase delay              : 9000 us
PAGEL                         : P00
BS2                           : P00
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                       Pol
led
  Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadB
ack
  ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ------
---
  eeprom         4    20   128    0 no        512    0      0  9000  9000 0xff 0
xff
  flash         33     6    64    0 yes      8192   64    128  4500  4500 0xff 0
xff
  lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0
x00
  hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0
x00
  lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0
x00
  calibration    0     0     0    0 no          4    0      0     0     0 0x00 0
x00
  signature      0     0     0    0 no          3    0      0     0     0 0x00 0
x00

avrdude>

[TerminalJack505]

Could be.  That page you linked to used a setting of 1000 for the SCK parm.  You might try that.  That setting basically controls how fast the programmer talks to the chip so 0.1us may be to fast.  I'm using 10us on my programmer.  1000us should work for any clock speed.

[GabYoung92]

Those fuse settings aren't right, obviously.

That SCK period may be too fast.  Try changing it with the SCK command.

Code: [Select]

sck 11

Code: [Select]

avrdude> sck 11
>>> sck 11

avrdude: stk500_setparm(): (a) protocol error, expect=0x14, resp=0x12
avrdude (sck): failed to set SCK period (rc = -2)
avrdude>
Plus, the heartbeat, error and programming leds are all on now.

I don't know..  I think I may leave this for now and give the LPT port a go later on.

[TerminalJack505]

I bet the Arduino ISP firmware doesn't support that option.  The timing is probably hardcoded.

Did you check the status of the RESET# pin on the ATmega8 while you where in avrdude?  It should be low.

[GabYoung92]

I bet the Arduino ISP firmware doesn't support that option.  The timing is probably hardcoded.

Did you check the status of the RESET# pin on the ATmega8 while you where in avrdude?  It should be low.

While avrdude is running.  The programing led is on, and I'm getting (DMM) 0V on the reset pin of the ATmega8 chip.  With reference to VCC, the RESET pin is -5.1 volts, so low.


Something I've just noticed...

Code: [Select]

avrdude> parms
>>> parms
Vtarget         : 0.0 V
Varef           : 0.0 V
Oscillator      : Off
SCK period      : 0.1 us
Oscillator is off.. should that be?

[TerminalJack505]

I'm guessing we're not using avrdude correctly for the ISP 'programmer'. 

Just for grins you might try this as well when you launch avrdude...

avrdude -p m8 -c avrispmkII -P usb -t

The oscillator option probably works like the STK500 where you can have it (the STK500 board) generate a clock for the MCU.  You don't want that in this case.

[GabYoung92]

I'm guessing we're not using avrdude correctly for the ISP 'programmer'. 

Just for grins you might try this as well when you launch avrdude...

avrdude -p m8 -c avrispmkII -P usb -t

The oscillator option probably works like the STK500 where you can have it (the STK500 board) generate a clock for the MCU.  You don't want that in this case.

Changing the -c param causes the error LED to light and I just receive a timeout message.  I've found using -c with AVRisp is the only way to get avrdude communicating through the arduinoISP. (Not sure if it is actually working, but the terminal seems to like it). 

I've got a feeling that the chip has been programmed to use an external clock which I think may explain why they are not responding as expected. 

I will give the printer port a go tomorrow.  Thanks guys!

 

[TerminalJack505]

I've got a feeling that the chip has been programmed to use an external clock which I think may explain why they are not responding as expected.

Have you tried hooking up a crystal and capacitors to the XTAL1 and XTAL2 pins?

[Erwin Ried]

I'm guessing we're not using avrdude correctly for the ISP 'programmer'. 

Just for grins you might try this as well when you launch avrdude...

avrdude -p m8 -c avrispmkII -P usb -t

The oscillator option probably works like the STK500 where you can have it (the STK500 board) generate a clock for the MCU.  You don't want that in this case.

Changing the -c param causes the error LED to light and I just receive a timeout message.  I've found using -c with AVRisp is the only way to get avrdude communicating through the arduinoISP. (Not sure if it is actually working, but the terminal seems to like it). 

I've got a feeling that the chip has been programmed to use an external clock which I think may explain why they are not responding as expected. 

I will give the printer port a go tomorrow.  Thanks guys!

 

Buy a cheap USB ISP programmer in ebay, I got mine at 4 usd with the cable and shipment ( http://www.ebay.com/itm/USB-ASP-ISP-Programmer-Adapter-10-Pin-Cable-For-ATMega8-AVRDude-CAN-PWM-Series-/140784185108?pt=LH_DefaultDomain_0&hash=item20c7642f14 ). I use khazama programmer to upload the code, no commands and let your arduino to be free

[GabYoung92]

Just bought the programmer... Now to wait till it arrives



TerminalJack505,
I don't have any spare ones, however I could pull one out of an old device.  Should I try and find a certain frequency?


And I'm unable to use the parallel port

[TerminalJack505]

Just bought the programmer... Now to wait till it arrives



TerminalJack505,
I don't have any spare ones, however I could pull one out of an old device.  Should I try and find a certain frequency?


And I'm unable to use the parallel port

The more I think about it, the more I suspect the 'programmer'.  Especially considering it didn't work with the 8515.  Assuming, of course, we were invoking avrdude correctly for that particular programmer.

[GabYoung92]

Ok I found a LPT header in my tower, grabed pin diagrams and hooked it up as per a previous post. 

I've tried to install the giveio but...

Code: [Select]

H:\avr\bin>install_giveio
Copying the driver to the windows directory
target file: C:\Windows\giveio.sys
        1 file(s) copied.
Remove a running service if needed...
Installing Windows NT/2k/XP driver: giveio
installing giveio from C:\Windows\giveio.sys... ok.
starting giveio... start failed (status 1275):
This driver has been blocked from loading

ERROR: Installation of giveio failed
I am running windows7 64bit.  I've given a quick google search and most things I've read say it doesn't work on 64bit.  Is there any other program I could use or would it be best to wait until my programmer arrives?
(http://www.ebay.com/itm/USB-ASP-ISP-Programmer-Adapter-10-Pin-Cable-For-ATMega8-AVRDude-CAN-PWM-Series-/140784185108?pt=LH_DefaultDomain_0&hash=item20c7642f14)

[Psi]

Just to test it you could boot that PC on a ubuntu linux live cd.

sudo su

apt-get install avrdude

avrdude -i 20  -p m8 -P /dev/parport0 -E noreset -c bsd -e -U flash:w:mycode.hex


If you're wondering what the "-E no reset" does it just means the mcu will start running once avrdude finishes.
(Otherwise avrdude sets the port back how it found it, which in linux is with reset held low)

[GabYoung92]

Just to test it you could boot that PC on a ubuntu linux live cd.

sudo su

apt-get install avrdude

avrdude -i 50  -p m8 -P /dev/parport0 -E noreset -c bsd -e -U flash:w:mycode.hex


If you're wondering what the "-E no reset" does it just means the mcu will start running once the code has been written.
(Otherwise in linux the default LPT port state is with reset low, so after programming the device stays reset and you have to unplug the header to get it to run.)

I'll give that a go.  Downloading 12.04 now,
Am I able to upload the arduino bootloader to the chip using avrdude so that programming is easy until my programmer arrives?

[Psi]

Yes, if you have a bootloader hex file you should be able to upload that in the same way.

However you will need to change the fuse bits to enable the reset vector and set the required boot blocks size.
It may also need the EEPROM preserve fuse set, if the boot loader uses the eeprom?


To change a fuse bit you can go
 
avrdude  -c bsd -p m8 -E noreset -P /dev/parport0 -U lfuse:w:0x??:m 
avrdude  -c bsd -p m8 -E noreset -P /dev/parport0 -U hfuse:w:0x??:m
where ?? is the hex value to set and where lfuse/hfuse specifies which fuse byte you're setting

This is where people make mistakes and set the hfuse to what the lfuse should be or get the bit order reversed etc..

Best thing to do is first read out the current fuse bits and check to see if they make sense, as this checks if your method of reading/understanding them is correctly.

I don't think you can just display them on the screen with avrdude but you can read them out as files

avrdude  -c bsd -p m8 -E noreset -P /dev/parport0 -U hfuse:r:high.hex:r
avrdude  -c bsd -p m8 -E noreset -P /dev/parport0 -U lfuse:r:low.hex:r

Now you have two files.. high.hex and low.hex
If you run  "hexdump low.hex"  you will get

0000000 00ef                                   
0000001

So EF is the current low fuse value for that example.
Convert to binary and compare to datasheet to see which flags are set.

If you're unsure about fuse bit stuff, ask before doing it.

[GabYoung92]

Oh noes! I think..

First go I connected to the ATmega8..  second go I plugged it into the 328p on the arduino board..

Is there something I'm doing wrong here?

Code: [Select]

ubuntu@ubuntu:~$ sudo avrdude -p m8 -b 19200 -P /dev/parport0 -c bsd -F

avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATMEGA8 is 1E 93 07

avrdude done.  Thank you.

ubuntu@ubuntu:~$ sudo avrdude -p m328p -b 19200 -P /dev/parport0 -c bsd -F

avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATMEGA328P is 1E 95 0F

avrdude done.  Thank you.


[Psi]

-b does nothing when using the LPT port, it's for setting the serial port baudrate.
I've never needed to use -F to force communication. If it can't detect the signature then it's not going to work so there's no point forcing it.
Try add -i 20  that will slow down the LPT program rate.

Do you have the mega8 connected to the printer port pins correctly and are you supplying the mega8 with 5V power from somewhere?
Can you post a pic of it?

[GabYoung92]

-b does nothing when using the LPT port, it's for setting the serial port baudrate.
I've never needed to use -F to force communication. If it can't detect the signature then it's not going to work so there's no point forcing it.
Try add -i 20  that will slow down the LPT program rate.

Do you have the mega8 connected to the printer port pins correctly and are you supplying the mega8 with 5V power from somewhere?
Can you post a pic of it?

I've unpluged it since then.  I salvaged a 14.3F1FB crystal and two caps.  Connected them up using the arduino as ISP and tried again... But I can't seem to get it to read the signature. 

Picture of what i've got currently

[amyk]

I was also thinking of recommending you try the simple parallel port interface, but it seems you can't get any communication happening. This can happen if you've accidentally programmed RSTDISBL, which may have been due to the same thing that caused the corruption earlier.

If I were you I'd just hook it up in parallel programming mode manually (a few switches and debounced pushbuttons is enough, and a 12V source through current-limiting resistor - 250uA is enough) and at least see if the signature bytes can be read out. The advantage of this mode is it doesn't need a clock at all, and while they're latched on the output you can probe the pins with a multimeter to see if they're the expected values. The datasheet explains the procedure in detail.

[TerminalJack505]

That should probably work if the MCU is set to use an external xtal.  Are those caps ~15pF?

The code for the programmer firmware says:

// Windows users should consider WinAVR's avrdude instead of the
// avrdude included with Arduino software.

Is this the version of avrdude you're using?

[GabYoung92]

That should probably work if the MCU is set to use an external xtal.  Are those caps ~15pF?

The code for the programmer firmware says:

// Windows users should consider WinAVR's avrdude instead of the
// avrdude included with Arduino software.

Is this the version of avrdude you're using?

I'm not sure of the fuse programming.  I used the boards template on http://arduino.cc/forum/index.php?topic=112452.0 to try and program it to use the internal clock. 

The markings on them are 102 100v, 1000pF from doing a quick search.. I know they are far too large.. but it was the only caps I could salvage to try the XTAL.  I've got an order of 16MHz crystals and 20pF caps on the way.  But for the time I'd thought I would try this setup.

Yes, I was using avrdude which was inside my Arduino IDE package.  I'm installing WinAVR as I'm typing this.

[TerminalJack505]

You never programmed the 8515, right?  And it doesn't work with the programmer either?  If so then I say something's wrong on that side instead of the MCU. 

Did you make any changes to the firmware?  I saw one of the pages suggest a change that looks like would affect the timing.

Note for Arduino 1.0: you need to make one small change to the ArduinoISP code. Find the line in the heartbeat() function that says "delay(40);" and change it to "delay(20);".

[GabYoung92]

You never programmed the 8515, right?  And it doesn't work with the programmer either?  If so then I say something's wrong on that side instead of the MCU. 

Did you make any changes to the firmware?  I saw one of the pages suggest a change that looks like would affect the timing.

Note for Arduino 1.0: you need to make one small change to the ArduinoISP code. Find the line in the heartbeat() function that says "delay(40);" and change it to "delay(20);".

No I've never been able to program the 8515. Well my arduinoIDE has always told me it's failed. 

I'm using 1.0.1 which has updated the sketch already so I didn't have to change any of the code.


I think its the chip.  I'm trying to burn the bootloader onto the ATmega8 using the Arduino via arduinoIDE but I'm still getting the signature error. 

[TerminalJack505]

I'm wondering if your sketch is the same one that I got then.  I grabbed the latest version (.04) and the code still has this...

Code: [Select]

void heartbeat() {
  if (hbval > 192) hbdelta = -hbdelta;
  if (hbval < 32) hbdelta = -hbdelta;
  hbval += hbdelta;
  analogWrite(LED_HB, hbval);
  delay(40);
}
So far as the 8515 goes, if it's never been programmed then avrdude shouldn't have any issues connecting to it since there's no chance that the fuses have been fubarred yet.

[GabYoung92]

I'm wondering if your sketch is the same one that I got then.  I grabbed the latest version (.04) and the code still has this...

Code: [Select]

void heartbeat() {
  if (hbval > 192) hbdelta = -hbdelta;
  if (hbval < 32) hbdelta = -hbdelta;
  hbval += hbdelta;
  analogWrite(LED_HB, hbval);
  delay(40);
}
So far as the 8515 goes, if it's never been programmed then avrdude shouldn't have any issues connecting to it since there's no chance that the fuses have been fubarred yet.

Loaded up Arduino 1.0.1, ArduinoISP sketch.  Yep, delay(20);

I'll re-upload the ISP program to my 328, connect the 8515 and give it a go.

[GabYoung92]

Code: [Select]

avrdude -p m8515 -c avrisp -b 19200 -P COM7

avrdude: please define PAGEL and BS2 signals in the configuration file for part
ATMEGA8515
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.07s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.


[TerminalJack505]

I'm out of ideas.  I guess the next thing to try is HV parallel programming.  You might be able to find a Arduino sketch to help in that regard.

[LEECH666]

Just something I noticed: I think you don't have to specify the -P COM7 if you're using an USB programmer like the AVRisp (Arduino). At least I never did when I used the AVRisp to programm my perfboard USBtinyISP (ATtiny2313). Maybe that's why it's reading garbage, because it's trying to access the COM Port 7 somehow and nothing is connected to it?

http://www.ladyada.net/make/usbtinyisp/avrdude.html

Using it is simple, just indicate usbtiny as the programmer type. The port option is ignored as it always uses USB.

I think the Arduino AVRisp works the same way. (Might not be true for Linux?)

I managed to fix some AVRs with bad fuse settings this way:

- I set up my Arduino to generate a clock (basically the blinky sketch without delays is what I used here). Any other clock source will probably do, like the calibration output of a scope. If you own one.

- Hooked up the clock output of the toggleing Arduino to the XTAL1 input of the broken AVR. GND of Arduino connected to GND of the AVR (obviously).

Used USBtinyISP to flash fuses with following command:

avrdude.exe -p m168 -c usbtiny -U lfuse:w:0x62:m -U hfuse:w:0xdf:m -U efuse:w:0xf9:m -B 2000

Notes:

Not all AVRs have extended fuses (efuse).

The -B option specifies the ISP clock speed. 2000 is a rather slow value. It didn't work for me without that -B option. You can read some more about the -B option on the link to Lady Ada a bit further up my post.

I put in the default fuse settings for the ATmega168 (m168). You can find out the default fuse settings of many AVRs on this handy homepage: http://www.engbedded.com/fusecalc/

I admit I didn't read the full thread, so if this has been said before, I am sorry.

Cheers,
Florian

[GabYoung92]

LEECH666 I'll have to give that a go in the morning.  See if it makes a difference because it sort of makes sence because com7 is the port to the arduino.. this may be an issue, I'm not sure, but worth a go of course!

No DSO as of yet, but I recently ordered a Rigol ds1502e and was hoping for it to turn up today! no luck so maybe in the morning. Would the 1khz clock be fast enough?  I'm using my only arduino as the ISP so I don't think I've got any way to do the clock, except on the DSO I'm waiting on...

Great website! now to make sure I select the right thing and that I can get these chips working again

Don't worry, It's pretty much me trying different ways to get this to work, and failing  

[TerminalJack505]

There is documentation for the Arduino ISP firmware here.

[TerminalJack505]

Wow!  Did you see this bug?

void start_pmode() {
  spi_init();
  // following delays may not work on all targets...
  pinMode(RESET, OUTPUT);
  digitalWrite(RESET, HIGH);  // Note: Target MCU is brought out of reset.  Per Atmel spec.
  pinMode(SCK, OUTPUT);
  digitalWrite(SCK, LOW);    // Note: But SCK is set as an output and driven low.
  delay(50);
  digitalWrite(RESET, LOW);
  delay(50);
  pinMode(MISO, INPUT);
  pinMode(MOSI, OUTPUT);
  spi_transaction(0xAC, 0x53, 0x00, 0x00);
  pmode = 1;
}

That's a big problem.  Basically the programmer brings the MCU out of reset for 50 ms and during that time has the SCK pin set as an output and drives it low.  If the firmware on the chip being programmed happens to use that pin as an output and drives it high it can damage the chips. 

You might check to see if your Arduino can still make use of that pin.  It might be fried.  I would also put current-limiting resistors on all those pins from now on until you get a real programmer.  I looked through the programmer firmware and it's pretty much a big hack.

[LEECH666]

I guess you also could use your PC soundcard plus some waveform generation software as a clock source.

I'm tempted to make a video on fixing AVRs with wrong clock fusebit settings using different kinds of clock sources and an Arduino / USBtinyISP.

[GabYoung92]

TerminalJack505,

I've just extended to the blink program to switch all of the digital pins on, and all of them go HIGH and LOW, so no problems there.

Yea I was hoping to use it without having to get a programmer, but I've bought a cheap Chinese one so hopefully I get some luck then!


LEECH666,
I was thinking of doing something like that.  I know i would wire up the com of the audio jack to ground, but the pos pin, should I wire that to XTAL1 or XTAL2 on the ATmega8?

Go for it! Be great to watch, and hopefully I can learn from it

[LEECH666]

But you would be faced with my horrible German accent.

Might try to shoot a video later.

I think it was XTAL1 which needs to be used.

Cheers,
Florian

[GabYoung92]

But you would be faced with my horrible German accent.

Might try to shoot a video later.

I think it was XTAL1 which needs to be used.

Cheers,
Florian

Don't mind German   (One of my lecturers has a strong Russian accent which at times is quite funny when he says things).

I'll have to give it a go.  Thanks!

[amyk]

I guess you also could use your PC soundcard plus some waveform generation software as a clock source.

That might not produce enough voltage. According to the datasheet for the ATmega8 it has to be at least 0.8Vcc which is 4V for a 5V supply and 2.64V for 3.3V. Line level output is usually 2Vpp. (It can go below 0 to -1V, which is definitely not good for the AVR at all, but this could probably be avoided in software.) Careful use of an amplifier might work.

I'd go the HVPP route if I were you. Not as much equipment needed to setup if all you want to do is erase the chip and/or reset the fuses. Then again, some of us on here probably do like playing with all that extra stuff

[GabYoung92]

I guess you also could use your PC soundcard plus some waveform generation software as a clock source.

That might not produce enough voltage. According to the datasheet for the ATmega8 it has to be at least 0.8Vcc which is 4V for a 5V supply and 2.64V for 3.3V. Line level output is usually 2Vpp. (It can go below 0 to -1V, which is definitely not good for the AVR at all, but this could probably be avoided in software.) Careful use of an amplifier might work.

I'd go the HVPP route if I were you. Not as much equipment needed to setup if all you want to do is erase the chip and/or reset the fuses. Then again, some of us on here probably do like playing with all that extra stuff

If I used the sound card, I would interface it with a transistor pair and source through a sensible voltage to the clock pin.

I'm not sure how to do the HVPP, is there a good tutorial I could follow?

[LEECH666]

Since you already have an Arduino you might want to check out this Arduino shield.
http://mightyohm.com/blog/products/hv-rescue-shield-2-x/

 You could probably slap smth together on a breadboard or perfboard that will work. I think you will need to have either access to a 12V source or use a step up converter to create the 12V from the 5V USB supply of your PC (like the shield does).

There is an older version of that shield that uses a transistor based step up converter instead of a single IC in a SOT23-6 package.

Let me try to find it ...

Cheers,
Florian.

//EDIT

Found the old transistor based version here: http://mightyohm.com/blog/2008/09/arduino-based-avr-high-voltage-programmer/

Probably just another hack job really. Might be okay for the occasional hobbyist fix tho.

PS: amyk - Your points are valid. I didn't think about that at all.
Thanks for bringing it up.

//EDIT 2

Well DERP! Apparently it's not a step up converter at all. Upon rereading the article I just noticed that you still have to apply 12V externally.

[GabYoung92]

Cool! Thanks!  No probs wiring up an external source.

Bummer!  I'll have to pick up some more 1k resistors at work tomorrow.  And hopefully I can use a 2n3904 instead of the 2n3903.

Readinghttp://denki.world3.net/avr_rescue.html I will make sure I connect everything up, and I'll probably make a shield.

[LEECH666]

I think that transistor is just there to switch on/off the 12V volts, so probably any small signal jelly bean NPN transistor will do. The 2N3904 seems to belong to the same family of transistor as the 2N3903, so it should be fine.

Those 1K resistors are most likely there for protection (current limit) of the connected device and the Arduino. In the later versions of the HV shield those resistors are omitted. I think he even said so in his blog. Can't be bothered to look where he wrote that tho.

In general I'd say you can omit them too or replace them with a similar value (470R to 3K or smth like that). It probably doesn't really matter.

Also take note that this is not a fully fledged programmer, it's just there to fix bad fuses. It doesn't seem to support writing to the flash memory, just the lfuse, hfuse and efuse area. I don't know if efuse memory area is included in the older version of the shield.

Cheers, Florian

[LEECH666]

I really really like this programmer because it can programm a lot of AVRs and a lot of PICs too. I plan to build it some day. But so far I haven't found the time to do so, as I plan to do my own PCB of this programmer.

http://home.arcor.de/bernhard.michelis/index.html

Cheers,
Florian

[bsiswoyo]

Dear,
I have had success using the ATmega 8 as the Handmade Arduino. However, the program can succesfully be uploaded using ISP with the Arduino IDE ver. 0.22.

Also if you make the ATmega 328 Arduino is uploaded using a USB-Serial-to-TTL in the Arduino 1.0.1 environment. You must modify the boards.txt file with nano328.upload.protocol=stk500.

The completely informations visit:
http://bsiswoyo.lecture.ub.ac.id/2012/07/arduino-1-0-1-serial-upload-using-with-handmade-board-of-atmega328/

best regard
bambang siswoyo

[GabYoung92]

Great success! 

The 16MHz crystals arrived, and now I can read the signature no problem.  I can't reprogram the chip once I've programmed it.  However, if I use avrdude to erase the chip I can reprogram the device. 

Program using arduino --> Erase using avrdude --> reprogram using arduino.   No problems!

My DSO also arrived so checking a 500Hz output pulse is spot on, and a 100KHz shows 100.038KHz on the ds1052e counter. 

[TerminalJack505]

It sounds like something is wrong with the fuse settings still since you have to erase before programming.

I just looked at the fuse settings again from your earlier post and notice something interesting.

Here's the fuse settings you seem to be using...

atmega8u.bootloader.low_fuses=0xe4
atmega8u.bootloader.high_fuses=0xc2

The CKSEL[3..0] bits are set to 0100, which selects the internal 8 MHz oscillator.  However, the CKOPT fuse is programmed (set to 0.)

The datasheet (page 30) has this to say about that particular combination...

The calibrated internal RC Oscillator provides a fixed 1.0MHz, 2.0MHz, 4.0MHz, or 8.0MHz clock. All frequencies are nominal values at 5V and 25°C. This clock may be selected as the system clock by programming the CKSEL Fuses as shown in Table 9. If selected, it will operate with no external components. The CKOPT Fuse should always be unprogrammed when using this clock option.

Take special note of that last sentence.

I wonder if that's causing the problem?

[GabYoung92]

Before the previous post, I wrote new fuse settings using avrdude which worked, and I had modified my boards.txt file to include the new fuse settings

Code: [Select]

atmega8u.name=ATmega8 - External 16MHz crystal

atmega8u.upload.protocol=arduino
atmega8u.upload.maximum_size=7168
atmega8u.upload.speed=19200

atmega8u.bootloader.low_fuses=0xFF
atmega8u.bootloader.high_fuses=0xC9
atmega8u.bootloader.path=atmega8_noxtal
atmega8u.bootloader.file=ATmegaBOOT.hex
atmega8u.bootloader.unlock_bits=0x3F
atmega8u.bootloader.lock_bits=0x0F

atmega8u.build.mcu=atmega8
atmega8u.build.f_cpu=16000000L
atmega8u.build.core=arduino
atmega8u.build.variant=standard
I was using the website to 'calculate' the fuse settings, plus I was reading up on threads where atmega8's fuse settings were the topic. 

I don't mind having to erase the chip, as once I get my pcb made, the chip will be placed in and left in.   I'm making a volt meter for a linear psu I've built. 

[TerminalJack505]

Yep, I hear you.  I'm sure you're happy to have it working again and glad you didn't completely brick the MCU.

[GabYoung92]

Yep, I hear you.  I'm sure you're happy to have it working again and glad you didn't completely brick the MCU.

Yup, this shows me how arduino has simplified microcontrollers.  Thanks for all of your help.