ATTiny85-20PU (0548) (avrdude Invalid device signature 0xffffff) maybe Fake or?

Go To Last Post
58 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I just bought 5pcs of ATTiny85-20PU and unfortunately none of them are working.
 

Error message appears while identifying the MCUs ID: Invalid device signature 0xffffff
 

I got this message from avrdude using USBtinyISP Programmer (CMD output).

 

avrdude -c usbtiny -p t85 -F

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0xffffff
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATtiny85 is 1E 93 0B

avrdude: safemode: Fuses OK (E:FF, H:DF, L:62)

avrdude done.  Thank you.

Here is my setup and it's working with different ATTiny85 MCUs:

 

 

Do you think they were electrically shocked due inappropriate seller packaging or?

Last Edited: Sat. Jul 2, 2016 - 11:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

whats the power source?  

That foam does not look like the type that is static safe!

Where did you get them? ebay? 

 

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not an avrdude person but from many similar threads...

 

-- IIRC 'dude users say "don't use -F"...isn't that an override of some sort?

-- Have you slowed down the 'dude clock appropriately?

-- Is the target chip powered?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The power source is from the USB programmer itself...

it's not the programmer issue, it's working fine.

If you make a close look you will see that my programmer is also using the same MCU but from different manufacturer which was also programmed by me.

Nah, not from eBay, it's from AliExpress, but I ordered before from that site, and those MCUs are driving my programmer and my other projects.

But you can see on my programmer that the values/text not so readable like what I just bought!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would start by tracing out all six signals from programmer to target IC pins.

David (aka frog_jr)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, but neither that you proposed. :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I put from different manufacturer then it's all working just fine!

What you see on the picture, those 4pcs on the desk and that 1pcs in the programmer extension board, those have some issues and they are all brand new, not used ones!

Last Edited: Fri. Jul 1, 2016 - 08:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, just to clarify, there is two different AVR:

1. from left (the first), what I just bought 5pcs of them, new, empty and not recognized by avrdude.

2. from right (the second) bought about 4-5 moths ago 5pcs also, new, empty and it's recognized just fine by avrdude!

 

 

Avrdude CMD output for the secod AVR chip (which is just fine):

avrdude -c usbtiny -p t85 -F

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e930b

avrdude: safemode: Fuses OK (E:FF, H:DF, L:62)

avrdude done.  Thank you.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So the 11 year old Tinys do not work. The RHS chip does not show the Date Code but do work.
.
NEVER use the -F switch. (unless you understand what you are doing)
.
If the 11 year old chips have only just come onto Ebay, they probably have some history.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The USBTINY design used a Tiny2313. Your "programmer" seems to have a DIP8 chip. Yes, an ATTINY45 would be capable of running the programmer but needs some modifications to the firmware.
.
David

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
So the 11 year old Tinys do not work.

Yes, I guess so it's says 0548...

 

david.prentice wrote:
The RHS chip does not show the Date Code but do work.
 

It has a date code, but it's barely readable, it's 1501, and yes, they are working just fine.

 

david.prentice wrote:
NEVER use the -F switch. (unless you understand what you are doing)
 

I just used it to force the readout, nothing else.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
The USBTINY design used a Tiny2313. Your "programmer" seems to have a DIP8 chip. Yes, an ATTINY45 would be capable of running the programmer but needs some modifications to the firmware. . David

My programmer is doing just fine, I have programmed more than 50+ ATTINY85 whit it...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And here is the Verbose output from avrdude:

 

avrdude -p t85 -c usbtiny -v

avrdude: usbdev_open(): Found USBtinyISP, bus:device: bus-0:\\.\libusb0-0001--0x1781-0x0c9f

         Using Port                    : usb
         Using Programmer              : usbtiny
         AVR Part                      : ATtiny85
         Chip Erase delay              : 4500 us
         PAGEL                         : P00
         BS2                           : P00
         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        512    4      0  4000  4500 0xff 0xff
           flash         65     6    32    0 yes      8192   64    128  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 : USBtiny
         Description     : USBtiny simple USB programmer, http://www.ladyada.net/make/usbtinyisp/

avrdude: Using SCK period of 10 usec
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.02s

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


avrdude done.  Thank you.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My guess is they are faulty or fake. 

 

David

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe, but how that come that I can read out the fusebits with -F and they are correct?

 

avrdude: safemode: Fuses OK (E:FF, H:DF, L:62)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First off.   Do you really understand what -F does ?

 

Since you have some useless chips,  you could try clearing the lockbits by erasing the chip,  and see what happens.

avrdude -c usbtiny -p t85 -F -e

I have never seen a USBTINY on a DIP8 chip.   Who knows what firmware is present?   Do you have a link to where you bought it?

 

Have you ever wondered why 11 year old chips appear on Ebay?

 

David.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

First off.   Do you really understand what -F does ?

 

Forcing maybe?! ;)

 

david.prentice wrote:

I have never seen a USBTINY on a DIP8 chip.

Who knows what firmware is present?

Do you have a link to where you bought it?

 

It's my own build, I developed it, the whole thing and it's just working fine!

 

david.prentice wrote:

Have you ever wondered why 11 year old chips appear on Ebay?

 

No clue, and I didn't bought them on eBay! (Read the entire post)

 

Kind regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well,  Aliexpress is more suited to real Chinese companies rather than Ebay which favours individuals selling from their bedroom or shed.

 

All the same,   a company or an individual could buy surplus inventory from a company that has ceased production.    11 year old chips should be just fine.    OTOH,  they could have been damaged by radiation,  static, ...

 

The vendor has probably bought these components at a knockdown price.    If the punters do not complain,  it is sheer profit.    Even after refunding the punters that do complain,  they have only lost money on the shipping costs.    It is still worthwhile selling QC failures,  damaged or counterfeit components.

 

Regarding your USBTINY.   Why did you not just say that it is your own design?

This implies that you do actually know what -F means.   And you know how to rebuild the USBTINY source code for a different AVR.

 

This puts you in a totally different position.    And invites more technical replies.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

Well,  Aliexpress is more suited to real Chinese companies rather than Ebay which favours individuals selling from their bedroom or shed.

 

All the same, a company or an individual could buy surplus inventory from a company that has ceased production.

11 year old chips should be just fine.

OTOH,  they could have been damaged by radiation, static, ...

 

The vendor has probably bought these components at a knockdown price.

If the punters do not complain,  it is sheer profit.

Even after refunding the punters that do complain, they have only lost money on the shipping costs.

It is still worthwhile selling QC failures,  damaged or counterfeit components.

 

Yes, maybe you are right about all of that, and now the seller wants to ship me another round to close him the dispute! :D

 

btw...I bought a lot of ATTiny85, ATmega8 and ATmega328 from AliExpress more times and they were all ok.

 

david.prentice wrote:

Regarding your USBTINY.

Why did you not just say that it is your own design?

 

You can clearly see that is hand made, no? Or you just missed it? Or my work is that good, maybe?! ;)

 

david.prentice wrote:

This implies that you do actually know what -F means.

 

I'm not an AVR guru, but I know how to read the help and a faq documentation.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

Since you have some useless chips,  you could try clearing the lockbits by erasing the chip,  and see what happens.

avrdude -c usbtiny -p t85 -F -e

 

Here is the Verbose output:

 

avrdude -c usbtiny -p t85 -F -e -v


avrdude: usbdev_open(): Found USBtinyISP, bus:device: bus-0:\\.\libusb0-0001--0x1781-0x0c9f

         Using Port                    : usb
         Using Programmer              : usbtiny
         AVR Part                      : ATtiny85
         Chip Erase delay              : 4500 us
         PAGEL                         : P00
         BS2                           : P00
         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        512    4      0  4000  4500 0xff 0xff
           flash         65     6    32    0 yes      8192   64    128  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 : USBtiny
         Description     : USBtiny simple USB programmer, http://www.ladyada.net/make/usbtinyisp/

avrdude: programmer operation not supported

avrdude: Using SCK period of 10 usec
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0xffffff
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATtiny85 is 1E 93 0B
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: erasing chip
avrdude: Using SCK period of 10 usec

avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK (E:FF, H:DF, L:62)

avrdude done.  Thank you.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

beic wrote:
david.prentice wrote: So the 11 year old Tinys do not work. Yes, I guess so it's says 0548...

I guess it is possible...

 

...but unlikely IMO that these sat around as NOS for that long.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A Google search gave this anecdotal mention in a thread close to this one:  problems with Tiny85 with 0548 date code...

http://forum.arduino.cc/index.ph...

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am a little sceptical about the datasheet revisions.   They don't say what was "corrected" in the "5. Updated “Serial Programming Instruction set” on page 157."

 

I am even more sceptical about an empty Signature Row.   Of course there are plenty of other things that can go wrong in Silicon.    Somehow the Signature would be spotted immediately.

 

I don't see any reference to 0548 chips in your link.   I remember the thread about epoxy packages with copper slugs inside.    I always thought it was apocryphal.

 

What would be more interesting?   Whether the chips read with a commercial programmer.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I don't see any reference to 0548 chips in your link.

My link?  Just a mention but I thought it was "interesting" that OP here and that thread participant had similar symptoms with same AVR model and same data code.

L. DaVinci:
I just tried the other chip(0612) and it worked even though I tried programming it before!!
The blink sketch is working perfectly on it. I put back the (0548) chip and still it is not working,

david.prentice wrote:
I remember the thread about epoxy packages with copper slugs inside. I always thought it was apocryphal.

Sparkfun dug into it.  If you haven't done it, the investigation is a good read ...

 

https://www.sparkfun.com/news/350

https://www.sparkfun.com/news/364

https://www.sparkfun.com/news/395

 

The trip to Atmel to deconstruct

https://www.sparkfun.com/news/384

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah-ha.   I missed that daVinci had a (0548) chip.

 

It seems good fortune from Atmel's point of view.   If the (0548) production omitted to program the Signature Row,   there would be chips all over the world.    And a lot of whingeing hobbyists.    After all,  commercial customers would not be using DIP-8 chips.    They could recall batches from Distributors but quite honestly,   I do not see how bad Signature could get through Quality Control.

 

Whereas reels could leave a Factory,   an employee trying to leave with tubes full of DIP-8 chips seems unlikely.

 

David. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

A Google search gave this anecdotal mention in a thread close to this one:  problems with Tiny85 with 0548 date code...

http://forum.arduino.cc/index.ph...

 

Thank you, I read it all and it's almost the same issue appears there or maybe it's exactly the same issue?!

 

Nerveless, I tried to erase the cips with HVP too, nothing changed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyway,...I just don't understand this...

 

It has a bad signature, but read out of the fuses are OK?!?!?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you program the Flash?

Can you program the EEPROM?

 

Can you read anything from the Signature Row?

 

As I said in the previous post,  an awful lot of hobbyists would have whinged.    And Lee has been on this Forum since before the Ark.   

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On more thing,...

 

If I change the fusebits, it will change the device signature?!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please stop playing games.

 

If you can write your own firmware,  use HVPP, ... then you clearly have a good knowledge about AVRs.

 

Why not try reading every area of the chip?   You understand how to configure avrdude.

 

You can already ask for replacements / refund.   You have nothing to lose.   i.e. try reading lockbits,  changing fuses, ...    . 

But if you want advice,   report back with the results,   and not a silly question that you already know the answer to.

 

David.

Last Edited: Sat. Jul 2, 2016 - 04:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

Please stop playing games.

 

I'm not playing any games here!

Why so much hate?!

 

david.prentice wrote:

If you can write your own firmware,  use HVPP, ... 

 

It's my own build too, the HVSP! wink

 

david.prentice wrote:

You can already ask for replacements / refund. 

 

Already did that before 1-2 hours ago.

 

david.prentice wrote:

i.e. try reading lockbits,  changing fuses, ...

But if you want advice,   report back with the results,   and not a silly question that you already know the answer to.

 

Yes, I changed the fusebits from factory default L:62 H:DF E:FF to L:64 H:DF E:FF and the device signature changed to 160000 (0xffff75) from 0xffffff

 

What the hell, now I can't even read out the fusebits back, neither HVSP can reset it!

 

LUL laugh

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is no "hate".   I just felt that you were trying to appear unknowledgable when you clearly know a lot about ISP, HVSP, ...

 

No,  I would not expect you to lose everything when you go from a 1MHz RC to a 16kHz RC.   You do need to drop SCK down to < 4kHz.

 

Hey-ho,   doing anything with -F is inherently risky.    Even if they are not write commands.    I am sorry if I have ruined one of your chips,  but it was unusable to start with.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

There is no "hate".

I just felt that you were trying to appear unknowledgable when you clearly know a lot about ISP, HVSP, ...

 

I feel you David, but...! wink

Nah, I'm really a n00b for MCUs, but I know the basics and I love to develop and build things!

 

david.prentice wrote:

No,  I would not expect you to lose everything when you go from a 1MHz RC to a 16kHz RC.

You do need to drop SCK down to < 4kHz.

 

I can't do it anymore, the MCU is not responding.

 

david.prentice wrote:

Hey-ho,   doing anything with -F is inherently risky.

Even if they are not write commands.

 

Without -F command I will get nothing to the output only this "Unknown signature ffffff(retrying)" message and nothing else.

 

david.prentice wrote:

I am sorry if I have ruined one of your chips,  but it was unusable to start with.

 

They are broken anyway! laugh

Last Edited: Sat. Jul 2, 2016 - 09:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're the one who selected CKSEL[3:0]=0b0100, while leaving CKDIV8 programmed. This will result in a system clock speed of 16 kHz, as David has mentioned. It will require an ISP programming clock < 4 kHz. With too high a clock ISP won't work, not even reading the signature.
HVSP will be unaffected. If that doesn't work, you're not doing it right.

 

EDIT: typo

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Mon. Jul 4, 2016 - 02:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

You're the one who selected CKSEL[3:0]=0b0100, while leaving CKDIV8 programmed. This will result in a system clock speed of 16 kHz, as David has mentioned. I will require an ISP programming clock < 4 kHz. With too high a clock ISP won't work, not even reading the signature.
HVSP will be unaffected. If that doesn't work, you're not doing it right.

 

Yeah, tried -B 250, but without any luck, but the Device signature is changed again....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

beic wrote:
the Device signature is changed again....

Now, I'd have to study the entire thread again.  But I don't remember seeing where you >>ever<< got a verified signature read.

 

AFAIK, when you use the -F override you do not know what you are getting.  It could be just like a politician's aide:  telling you what you want to hear.

 

If you cannot repeatedly and reliably read the signature with a serial ISP setup, then other serial ISP commands are most likely to fail.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using -F is risky. As Lee says, it's a crap shoot. The risk is that you may be issuing commands you don't intend. There are undocumented ISP commands which can have very undesireable effects, such as changing the calibration bytes, or even the signature. The short answer is NEVER USE -F!!

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 

so essentially what everyone is saying is that the OP is "-F-ed".....

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

beic wrote:
the Device signature is changed again....

Now, I'd have to study the entire thread again.  But I don't remember seeing where you >>ever<< got a verified signature read.

 

AFAIK, when you use the -F override you do not know what you are getting.  It could be just like a politician's aide:  telling you what you want to hear.

 

If you cannot repeatedly and reliably read the signature with a serial ISP setup, then other serial ISP commands are most likely to fail.

 

I never got the correct signature from the very beginning...

 

Avrdude can't autodectect/identify the chip from the start (I just pressed 5 times the "Detect" button to make shore....).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
Using -F is risky. As Lee says, it's a crap shoot. The risk is that you may be issuing commands you don't intend. There are undocumented ISP commands which can have very undesireable effects, such as changing the calibration bytes, or even the signature. The short answer is NEVER USE -F!!

 

I know that, but in this case without -F I got only this message "Unknown signature fffff(retrying)"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

so essentially what everyone is saying is that the OP is "-F-ed".....

 

So true!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am sure that your Tiny85 chips are faulty.

 

I would be a lot happier if you revealed what firmware you are running on your "usbtiny".

After all, it is obviously not the public ATtiny2313 source code.    Have you just "built" for a Tiny45 or changed the functionality as well?

 

It would also be better to use a standard command line avrdude.

Then we would have confidence in the report.    Anything that involves a GUI makes me suspicious.

 

I presume that you own a regular Atmel STK500 or other official Atmel programmer.

In which case,  it would be useful to see their response.    Yes,  I know that they are not as configurable as avrdude.    But at least we would know you have tried the recommended Tools.

 

I do not want to criticize your private programmer hardware or firmware in any way.   I am impressed that you have built these things.    I have written my own firmware too.   I have also written unusual bugs that are not discovered for months i.e. until some special combination of events occurs.

 

I also suspect that you own a Logic Analyser.   This will reveal any strange behaviour or differences between the good Tiny85 and the bad Tiny85.   It is easy to watch the "connect" process when the AVR responds to the 0xAC53.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

I am sure that your Tiny85 chips are faulty.

 

Yeah, me too!

 

david.prentice wrote:

I would be a lot happier if you revealed what firmware you are running on your "usbtiny".

After all, it is obviously not the public ATtiny2313 source code.    Have you just "built" for a Tiny45 or changed the functionality as well?

 

I tried with 2 different programmers but with same results!

 

USBTinyISP

 

USBasp

david.prentice wrote:

It would also be better to use a standard command line avrdude.

Then we would have confidence in the report.

Anything that involves a GUI makes me suspicious.

 

Tried that too, you can see a few post above the cmd output.

 

david.prentice wrote:

I presume that you own a regular Atmel STK500 or other official Atmel programmer.

In which case,  it would be useful to see their response.

Yes, I know that they are not as configurable as avrdude.

But at least we would know you have tried the recommended Tools.

 

Unfortunately I don't own STK500, but I will buy one!

 

david.prentice wrote:

I do not want to criticize your private programmer hardware or firmware in any way.

I am impressed that you have built these things.

I have written my own firmware too.

I have also written unusual bugs that are not discovered for months i.e. until some special combination of events occurs.

 

Yes, but don't worry about my firmware, it's working with all of my ARV MCUs, I have here about 5-6 types, from ATTiny to ATmega.

 

david.prentice wrote:

I also suspect that you own a Logic Analyser.

This will reveal any strange behavior or differences between the good Tiny85 and the bad Tiny85.

It is easy to watch the "connect" process when the AVR responds to the 0xAC53.

 

Logic Analyser is on the way, I will get it this week, so I will try that too!

 

And that you for trying to help me out! wink

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I never got the correct signature from the very beginning...

Then how can you say this?:

Yes, I changed the fusebits from factory default L:62 H:DF E:FF to L:64 H:DF E:FF and the device signature changed to 160000 (0xffff75) from 0xffffff

If you never, not ever, got the correct signature even from your very first try, then you have succeeded in changing nothing.

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

I never got the correct signature from the very beginning...

Then how can you say this?:

Yes, I changed the fusebits from factory default L:62 H:DF E:FF to L:64 H:DF E:FF and the device signature changed to 160000 (0xffff75) from 0xffffff

If you never, not ever, got the correct signature even from your very first try, then you have succeeded in changing nothing.

 

Just verify my first post CMD output and you will see, it had a correct fusebit read out, but with a wrong signature!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just verify my first post CMD output and you will see, it had a correct fusebit read out, but with a wrong signature!

Irrelevant.  The signature check is a sanity check.  If that fails, all bets are off.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

Irrelevant.  The signature check is a sanity check.  If that fails, all bets are off.

 

So, to sum it up, all bought 5pcs are defective!

If I'm correct!?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

beic wrote:
So, to sum it up, all bought 5pcs are defective!
Well, again I'd need to review the thread in detail.  I don't remember whether your ISP rig works with [known] "good" chips or not.  I don't know whether you tested all of the batch, with an appropriately slow ISP clock speed to cover a variety of AVR clock speeds. 

 

But the early date code along with the anecdotal mention of nearly identical symptoms with the same date code would lead me to make a first guess that they aren't genuine.

 

If you want to go further, flip over your "good" chips, and these problem ones.  Copy everything printed on the bottom side.  Forward to Atmel support for deciphering.  For example, when I was your age the last letter on the second line was the die revision.  If that letter indicates a revision later than 2005 -- you make the conclusion.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

beic wrote:

So, to sum it up, all bought 5pcs are defective!

 

Well, again I'd need to review the thread in detail.  I don't remember whether your ISP rig works with [known] "good" chips or not.  I don't know whether you tested all of the batch, with an appropriately slow ISP clock speed to cover a variety of AVR clock speeds. 

 

But the early date code along with the anecdotal mention of nearly identical symptoms with the same date code would lead me to make a first guess that they aren't genuine.

 

If you want to go further, flip over your "good" chips, and these problem ones.  Copy everything printed on the bottom side.  Forward to Atmel support for deciphering.  For example, when I was your age the last letter on the second line was the die revision.  If that letter indicates a revision later than 2005 -- you make the conclusion.

 

So, what would be the conclusion for this one?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As mentioned, that is a job for Atmel support.  Not for us mere mortals, that just buy and use chips.

 

https://www.avrfreaks.net/comment... and similar

https://www.avrfreaks.net/forum/f...

https://www.avrfreaks.net/forum/e...

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Mon. Jul 4, 2016 - 09:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

As mentioned, that is a job for Atmel support.  Not for us mere mortals, that just buy and use chips.

 

https://www.avrfreaks.net/comment... and similar

 

Yes, thank you, I sent to Atmel about 5 mins ago!

I will report you back, if I will get any answer from them!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This may not be the problem you have, but I did have a similar experience with some aliexpress attiny13a chips a while back.  None would respond to to the programmer with anything but 0xFFFFFF, just like you're seeing.  After playing with them for a while I realized the pins were doing something when powered...they just weren't responding to a reset like I expected.  Hooked them up to HVSP and the problem became immediately obvious: the chips were already programmed with reset disabled and lock bits enabled.  So I just reset the fuses to default on all of them with an HVSP programmer and they behaved just fine after that.  A little annoying, but meh...I think I paid like 30 cents each for them.

 

It's worth checking out at least, just in case.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rezer wrote:

This may not be the problem you have, but I did have a similar experience with some aliexpress attiny13a chips a while back.  None would respond to to the programmer with anything but 0xFFFFFF, just like you're seeing.  After playing with them for a while I realized the pins were doing something when powered...they just weren't responding to a reset like I expected.  Hooked them up to HVSP and the problem became immediately obvious: the chips were already programmed with reset disabled and lock bits enabled.  So I just reset the fuses to default on all of them with an HVSP programmer and they behaved just fine after that.  A little annoying, but meh...I think I paid like 30 cents each for them.

 

It's worth checking out at least, just in case.

 

I have already tried HVSP, but it's no go! sad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think rezer meant HVPP

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oops, I see it now...missed it when I was going through the replies, too far down and I started skimming :p

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
I think rezer meant HVPP Jim

 

Ohh, then I need to build one!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The t85 (as with other low-pin-count tinies) supports only HVSP, not HVPP.  Either way, if HV programming doesn't work, the chips are duff, or not actually AVR.

See here:

https://www.google.ca/search?q=sparkfun+fake+avr

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

The t85 (as with other low-pin-count tinies) supports only HVSP, not HVPP.  Either way, if HV programming doesn't work, the chips are duff, or not actually AVR.

See here:

https://www.google.ca/search?q=sparkfun+fake+avr

 

I think they are fakes, but I will keep them for later studies!

And, yes, I already read those links.

Thank you Joey