AVR Freaks

I'm not sure I understood that, but I tried it again this time by bridging the JP1 (only jumper on board) and then ran the second command from my previous post. It couldn't find the USBasp device. If I wanted to upgrade the firmware I would require another programmer?

I figured it was, I bought it off eBay relatively cheap. I'm have a new chip coming in a few days hopefully that'll work. If not I'll probably get a left one. Alright well thanks a lot bud.

C:\>avrdude -c usbasp -P usb -p t2313 -v

avrdude: Version 5.10, compiled on Jun 18 2011 at 21:58:59
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf"

         Using Port                    : usb
         Using Programmer              : usbasp
         AVR Part                      : ATtiny2313
         Chip Erase delay              : 9000 us
         PAGEL                         : PD4
         BS2                           : PD6
         RESET disposition             : possible i/o
         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        65     6     4    0 no        128    4      0  4000  4500 0xff 0xff
           flash         65     6    32    0 yes      2048   32     64  4500  4500 0xff 0xff
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           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
           calibration    0     0     0    0 no          2    0      0     0     0 0x00 0x00

         Programmer Type : usbasp
         Description     : USBasp, http://www.fischl.de/usbasp/

avrdude: auto set sck period (because given equals null)
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e910a
avrdude: safemode: lfuse reads as 24
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF

avrdude: safemode: lfuse reads as 24
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

==============================================================================================

Could you tell me what kind of connections did you use? I keep getting errors about no response from the chip

1. check each wire with a DMM.

2. ...

Quote:

I've never used one, but a brief look at the product page suggests that it is a 'real programmer'

Let's say it is indeed a "real" programmer. Let's run down, then, the standard checklist for ISP problems. Starting with: Does it work with another "real" programmer?!? https://www.avrfreaks.net/index.p...

Quote:

I've been involved in many many AVR new board designs over the years. Occasionally, this situation comes up on first prototypes--unable to "contact" the board with ISP. I guess the first thing to consider is hard shorts of some kind. Turn the current way down on the power supply, and/or meter the current draw. Higher than 10-20mA? Hmmm--better shut things down and examine... These could be e.g. solder globs, or a design/routing error. Next step is to check the levels on all supply and ground pins. From there, I wouldn't want to tackle this situation without a 'scope. Preferably 2-channel. If you slow the ISP waaay down, to like 10kHz or something, even the soundcard 'scopes might suffice perhaps. (Are they dual-channel?) Set up the ISP at a slow speed and set up for Read Signature operations. If you can't do Read Signature reliably and repeatedly, then you won't have much luck with other ISP operations. Once you >>can<< do that then other ISP operations with probably work. (NB--the Read Signature sequence is a short query and short response, so a ratty signal can allow that operation but other operations with bigger packets might fail.) Now set up your 'scope with a good appropriate ground. In all of the below, READ THE SIGNAL RIGHT ON THE AVR PINS. Indeed, those will be harder to get at than the ISP header. But looking at the ISP header won't tell you what the AVR is seeing. All set up? Put the 'scope onto the AVR's /RESET. It should be riding high, and drop during the Read Signature operation. Drops, comes back up, and looks clean? Good. Now the SCK pin. A short burst during the Read Signature? Clean? Good. Here is where two channels start to come in. Once satisfied with SCK, then I tie one channel to SCK and use that as the trigger channel. In turn, put the second channel on /RESET, MOSI, and MISO and look at the waveforms w.r.t. the SCK. The /RESET is kind of the sanity check, and the width of the whole pulse indicates the entire transaction time. MOSI should wiggle during the first part of the transaction and MISO during the latter part. If all of the above is good and the MISO response is getting back to the ISP, then wtf--it should be working. If there is no MISO response, then the AVR is dead. Or maybe the ISP bit rate is too fast. Or, perhaps, is there other circuitry on the ISP pins? In particular, other SPI devices? Could they be interfering? Cut them loose if you have to--the objective here is to do ISP. In the worst hair-pulling situations, start with a bare board and little app circuitry--only enough to do ISP. The Read Signature sequence is short enough that if you have to you can decode the bits manually off the 'scope. A logic analyzer usually has many channels and allows the whole sequence and all the signals above to be done at the same time and would simplify the decode. Perhaps starting with the LA versus the 'scope is "better". (I have the 'scope ready on my bench and have to dig out the LA; and it usually doesn't get that far down the chain of tests above.) Quote: are you sure the oscillator module is working too? Of course the AVR needs a clock for ISP. If these are indeed "virgin" then the AVR should be running off the default internal clock.

Note that the sequence starts with the assumption of proper voltage level at the Vcc pin(s), proper Gnd connection(s), and proper bypass caps. https://www.avrfreaks.net/index.p...

Quote:

Quote: I connected them to my STK500 and found out that they respond fine to chip erase and fuse settings, Given that you go on to say that they don't respond correctly to Read Signature, they don't in fact "respond fine" to the operations you mentioned. The ISP program is reading >>a<< "response"--the state of the MISO line. It could be complete garbage. Quote: I wonder, could this be hardware damage for example due to static electricity? Certainly. Quote: Can the AVR be damaged physically so that only the flash memory fails? As suggested above, your situation very probably has no relationship to flash memory. Work on Read Signature first. If you can do that, other ISP operations are probably going to work OK. If you cannot, then other operations will probably fail. You start your diagnosis as with any other ISP problem: -- Does the AVR have power? Vcc and AVcc? Proper levels? All Gnd hooked up and properly decoupled? -- Does the AVR have a clock source? -- Does /RESET wiggle when you do a Read Signature? -- When /RESET is pulled low, what do you see on SCK? -- When /RESET is pulled low, what do you see on MOSI? -- When /RESET is pulled low, what do you see on MISO?

If I wanted to upgrade the firmware I would require another programmer?