Dead ATTINY841 processor?

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

Hello - I built a simple ATTINY841 board with a 14.7456MHz crystal (bypassed by 39pF caps).  The processor is a virgin out of the package from Digikey, so I assume there are no fuses set yet.  I'm powering the processor from a 3.3V supply.  I'm running AS 7.0, using an genuine Atmel ICE programmer over 6-pin ISP.  I have a 10k pullup on the RESET line.

 

When I try to either erase the processor or program fuses, I get "Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool"

 

I tried to see the oscillator running with an o'scope, but pins 2 & 3 are deader than Julius Caesar.  The 1st 2 LEDs are lit on the programmer, but not the 3rd (guess that means "Target is stopped").

 

I checked the pinout of the 6-pin ISP connector,  it matches a board I bought that works.

 

Anybody got any ideas? much thanks, paul

Attachment(s): 

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

This can mean several things.

 

You have the connections wrong.(Very possible)

 

You have your ISP clock set too high(Most likely)

 

YOu do not have power to the board.

 

The XTAL will not oscillate until you program the AVR fuses to use an external oscillator.  Check your wiring, then Lower your ISP clock to about 10k and try again.  If it still fails check your wiring AGAIN. 

 

I have not looked at teh datasheet but I am not so sure the Tiny can run 14Mhz at 3.3v.  For now though lets get the thing talking to you programmer

 

Jim

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

Please Read: Code-of-Conduct

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

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

Thanks Jim, will do - paul

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

paulofelora wrote:
so I assume there are no fuses set yet.

Think about that for a moment.  What value would a "not yet set" fuse have?  Each fuse bit must be either 0 or 1, right?

 

Anyway, the datasheet will have nice charts and lists and discussions about "default fuse values".  In particular, look at the discussion of "default clock source".

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

Ahah - I assumed (make an ass of you & me)that just because another Attiny841 was running at 14MHz at 3.3 that MINE would - hah! Jim was right - the processor isn't rated at 14MHz till you get to 4.5V.

 

I will post an update when I get my 5V regulator hooked up, then we'll see - thanks all, paul

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

paulofelora wrote:
I will post an update when I get my 5V regulator hooked up, then we'll see

I doubt you will see anything.  If the AVR is out of the box It usually means that the internal clock is running at 1Mhz.  The factory default clock is the internal oscillator, and the DIV8 fuse programed so that knocks it down to 1Mhz.  Therefor you will not see anything on the XTAL pins because they have not been enabled.  Thats why I said to recheck your connections, and/or slow down your ISP clock on the Atmel ICE.

 

Jim

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

Please Read: Code-of-Conduct

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

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

Well, I got my 5V regulator hooked up and it didn't solve my problem.  In AS7, using the Atmel ICE programmer, I can read the target voltage = 5.0V.  But as soon as I click on "Fuses" (or "Erase now" under Memories), I get the error "Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool)" - see the screen print I got.

 

I checked the programmer connections.  They match exactly those from DrAzzy (which works just fine), and are as follows:

 

debugWIRE signal      '841 pin

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

MISO                          8

Vcc                             1

SCK                            9

MOSI                          7

/Reset                        4

GND                           14

 

I have a 10K pullup from /Reset to Vcc.

 

Any ideas? much thanks

Attachment(s): 

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

Forgot to mention - I was running the ISP clock at its lowest possible setting, I think 8kHz

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

Check the datasheet. You might have the programmer connected to the alternate SPI pins instead of the default

Jim

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

Please Read: Code-of-Conduct

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

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

paulofelora wrote:

...bypassed by 39pF caps...

 

Seems a bit high, 18-22pF would be more 'normal'.

pragmatic - dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

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

That's the symptom I usually get when I put the 6-pin ISP connector the wrong way.

274,207,281-1 The largest known Mersenne Prime

In that awkward stage between preschool and death

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

Torby wrote:
That's the symptom I usually get when I put the 6-pin ISP connector the wrong way.

 

Which I brought up earlier.  THere must be something silly being missed.

 

JIm

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

Please Read: Code-of-Conduct

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

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

Dumb question:  You do have the PDIP SOIC version of the t841, yes?  The VQFN package has a different pinout.

"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."

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

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

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

 

Last Edited: Tue. Aug 9, 2016 - 11:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

Dumb question:  You do have the PDIP version of the t841, yes?  The VQFN package has a different pinout.

OK, I'll bite:  Where did you get a Tiny841 in DIP? ;)

 

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

Sorry, not PDIP.  SOIC.

"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."

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

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

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

 

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

Mine is an SOIC but I will double check the pilot- thanks folks

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

Thats pinout

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

Jim of jgmdesign helped me sort it out.  I had bad solder connections on the processor (SOIC) - getting too old for surface mount soldering, evidently! Thanks 10^6 Jim!

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

More than welcome

Jim

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

Please Read: Code-of-Conduct

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

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

I have a really similar problem - same error message, but I have successfully programmed the part several times.  The board is sitting there running the last code I burned into the attiny841, but I can't seem to burn new code into it.  This all worked a few weeks ago.  I have tried both my original AVR Dragon and an Olimex STK500 clone.  They each have their own cables, so that's not the problem.  I have couple copies of the board and they both behave the same.

 

The board uses the I2C function on the pins used by the programmer, but the reset at the start of programming should fix that, right?

 

I tried to do just a chip erase in case the lock bit was set somehow.

 

Unfortunately WinAVR/AvrDude don't support the 841 (yet), so I can't try that.

 

I wonder if some recent automatic upgrage to AVRStudio broke something.

 

Any other ideas?

 

Thanks,

 

Keith

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

kpayea wrote:
The board uses the I2C function on the pins used by the programmer, but the reset at the start of programming should fix that, right?

What do you mean by "fix it"?

 

Indeed, when the AVR is in reset, then I/O pins are floating inputs.

 

However, don't you think that typical I2C 4k7 or stronger pullups to Vcc might affect ISP operations?

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

Unfortunately WinAVR/AvrDude don't support the 841 (yet),

winAvr will never support it as it is not maintained.

I wonder if some recent automatic upgrage to AVRStudio broke something.

So are you saying that you are using AS7? Why mention winAvr then?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I meant as you suggested, that when the programmer yanks on reset to start the programming process that would override anything I did regarding pin function.

I hadn't thought of the I2C pullups.  I'll try programming with them removed.  I've concentrated on things I could think of that changed since the last time I did this a few weeks back, but it's time to question the things I thought were unchanged....

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

I was hoping to try something other than AS7 to program the part as a way to untangle this.  AvrDude was the first alternative I thought of, having used it in the past.  But it's a dead end for this part as you said.

 

Thanks,

 

Keith

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

kpayea wrote:
But it's a dead end for this part as you said.
You are mixing your utilities. avrdude (programming software) is alive and kicking and being actively maintained to have new parts added from time to time (in fact for a lot of parts the end user can do this anyway simply by editing avrdude.conf - which was kind of the whole point of putting most of the device details in a user editable file).

 

What is no longer maintained is WinAVR. The last release was in January 2010 so it has support for all the AVRs up to that release date but has not (and never will have) support to compile code for later models.

 

For a couple of years after 2010 it was still the "best choice" for anyone who want to use avr-gcc in Windows as Atmel (who temporarily employed Eric who has created WinAVR!) did not initially have the first idea about how to make an avr-gcc that actually worked. But they have now had 7+ years of practice and are actually getting pretty good at it. As a consequence they have:

 

Windows: http://www.atmel.com/tools/atmel...

Linux: http://www.atmel.com/tools/atmel...

 

The Windows one of these is just a "broken out" copy of the same avr-gcc they package with AS7. So if you are using Windows but can think of some reason not to simply install the complete AS7 (I can't!) then you can get "Atmel Toolchain for Windows" which is very similar to the WinAVR of old.

 

What Atmel's package does not do however is package "other useful things" alongside the core compiler and library. It doesn't include an up to date copy of avrdude and it does not contain all the gnuwin32 utilitues (basically all the common Linux utilities built for windos: grep, find, sed, etc etc). So there is still an argument to say go ahead and install the 2010 WinAVR first so you get these additional things, then install the Atmel package for a more up to date compiler/library. However things like the avrdude in WinAVR are now also 7+ years old so it might be better to seek out more up to date alternatives.

 

One thing to note is that the GNU Free Software Foundation still hold the "core" copy of GCC and the AVR variant within it - but then Atmel have their own "private" copy of this. The Atmel one "leads" the core one by about 1..2 years. So if you are looking for support for a very recent AVR you need to use the one from Atmel (who are slowly working towards aligning their local one with GNU). If the AVR you are looking to support is an established one you can also get your avr-gcc for Windows from a site such as:

 

http://gnutoolchains.com/download/

 

I was able to get an avr-gcc 5.3.0 from there LONG before Atmel finally brought out the 5.4.0 they now have available.

 

However that site is now actually "behind" Atmel again - but is worth bookmarking if you want a site that *may* have a more up to date (but reduced device support) avr-gcc than the one Atmel offer.

 

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

Thanks for all of that history, but what I'm really trying to do is figure out why I can't program an attiny841 using an AVR dragon.  The part did program a month or so ago, but not today.  I'm using the same setup and I have multiple boards all exhibiting the same symptoms.

 

I only investigated avrDude as another thing to try.  I searched to find the latest version, but when I downloaded and installed it, there was not support for the '841.  I know that I could modify the file to make it support the '841, but I took one look at it and decided my chances of success in any reasonable amount of time were about nil.

 

I have also tried using an Olimex STK500 clone to no avail.

 

So the real question is "what did I break in the last few weeks?"  Did an update to AS7 do it?  Did I clobber a setting accidentally?

 

Regards,

 

Keith

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

kpayea wrote:
So the real question is "what did I break in the last few weeks?"

Time for the ISP "checklist":  http://www.avrfreaks.net/comment... and links therein

-- Does your AVR have the proper supply voltage on ALL Vcc and AVcc pins? (Don't just say "yes"; check each.)
-- Does your AVR have ALL Gnd pins hooked up? (Don't just say "yes"; check each.)
-- When you do a serial ISP Read Signature, does /RESET drop? Nice clean signal, not overly rounded? If not, find out why.
-- Trigger 'scope on that falling edge of /RESET, and put the second probe on SCK. Do you see activity with nice square edges during the Read Signature?
-- Repeat with PDI (which is NOT MOSI or MISO). If OK,
-- Repeat with PDO (which is NOT MOSI or MISO).

If all of the above is good, and still no results, either your AVR has no clock source, or is fried. Was this a new AVR? Do you think you've mucked with the fuses? If so, inject an appropriate clock signal of about 1MHz (you can get it right on your STK500) into XTAL1 and try again.

Given the '128 target, what devices are hanging on the ISP pins? In particular, a comms transceiver (MAX232, MAX485, etc.) connected on USART0 can cause problems.

As your app is running, we indeed know that there is at least some supply voltage, and some clock.  Do you know the clock speed of the AVR?  Could your bit rate be too

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

RSTDISBL fuse could cause your symptoms.  Does your app stop when you pull /RESET low manually?

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

As well as the DW fuse but unlikely if this happens on multiple boards unless all of them had the DW programmed by accident.

 

Can you try and start a debug session on one of the boards? If this works that means the fuses were set wrong.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly