AVR won't exit reset -- Zapped?

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

AVR won't exit reset -- Zapped?

Hardware: ATMEGA128RFR2, mounted on a custom board (no socket).

My colleague programmed a board (ISP) and verified the load. He then disconnected the board (power cable, comms cable, programmer cable) and carried the board (mounted on a plate) across the room for further testing. When he got to his other bench, he plugged in power and comms. Upon application of power, the microcontroller entered reset mode - and did not exit.

Note, the ATMEGA128RFR2 has a pin that indicates when it is in reset mode (pin 13 = rston). We have a current limited LED connected to this pin that lets me know when the chip is in reset mode. We have verified that the actual reset pin (pin 12) is high (i.e., NOT commanding the chip to enter reset mode).

As unlikely as it seems, I suspect some kind of ESD event - simply because I can't think of another reason why the chip would stop functioning over the course of 30 or so seconds.

It is possible he unplugged the programmer (AVRISP mk2) while the board was powered. Could that have had some permanent negative impact on the chip?

The chip is configured to use an external crystal. If the crystal somehow got damaged, and stopped oscillating, would that force the chip into reset mode?

Science is not consensus. Science is numbers.

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

stupid idea,
but can it be that the fuses are programmed wrongly?
did you check that when the programmer is re-attached you can talk to the chip?

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

Not a dumb question at all. I can definitely NOT talk to the chip when the programmer is re-attached. I cannot even read the signature.

I do not believe he changed the fuses. While I wasn't present monitoring him, he claims he just followed the normal program procedure. As he was using the gui in AS 6.1, he likely programmed the ELF file (not the hex file directly), but he does not know how to program the production ELF file (which, even if he did, I have the fuses configured correctly). Furthermore, he is [fairly] confident that, after programming the board, he power cycled it, and verified he got an expected status message out of the uart port.

However, if he DID accidentally change them -- i.e., told the chip to look for a ceramic resonator (rather than the actual crystal that is there), I would still not expect the chip to hold itself in reset mode. Is this true, or does the chip have a sophisticated clock detection (or missing detection) circuit? I could not find anything in the data sheet regarding it.

Science is not consensus. Science is numbers.

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

The AVR is most likely clock-less, and therefor clue-less :)

Inject 1 MHz or so into Xtal1-pin. No need to remove the crystal. Then you can check the fuses and re-program them.

PS Xmega's are more sophisticated, mega's *can* become clockless

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

Plons -- just to make sure I understand. If the chip IS clockless, would it go into reset mode?

Is this due to the other fuses (i.e., that tell it how many [non-existent] clock cycles to wait before releasing the chip?

Science is not consensus. Science is numbers.

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

It will never get out of reset-mode without a clock. Apart from the SUT-fuses, it's also the reset circuitry itself that needs a few clock periods.

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

So the CLKI pin on the ATMEGA128RFR2 is not the XTAL1 pin.

CLKI = Pin 33
XTAL1 = Pin 57

Being the good designer I am, I followed the instructions in the data sheet, and connected the unused CLI pin to DVSS (see section 3.3 on page 7 of the data sheet). If I try to force a clock signal in on that pin, I will short out whatever is driving the signal. In this scenario, am I correct in assuming that driving a signal into XTAL1 won't help me?

Science is not consensus. Science is numbers.

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

Never used the ATMEGA128RFR2 so far. I'll have a look at the datasheet, but in the meantime: where is your crystal connected to ? Or post the schematic ..

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

A quick peek reveiled that inserting 1MHz into Xtal1 should do. No need to mess with CLI.
And if you're worried about possible damage to the AVR, (there is no reason for worries btw), put a 470R resistor in series with the temporary clock-supplier. Most of the time the easiest is to use an AVR for that purpose. But a frequency generator with TTL-out is on most workbenches.

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

Schematic attached (net names cut out).

Out of curiosity, why do you say that injecting a signal on the XTAL1 pin will still work with this chip (not doubting -- just want to learn)?

Attachment(s): 

Science is not consensus. Science is numbers.

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

U10B is having these problems, I presume ?

Xtal1 is the input of the clock circuitry inside the AVR. Xtal2 is the output, so that cannot be used for "injection"
Now, there is a possible issue here: if the fuses have been set for external clock on CLKI pin, then you must (temporarily) free that pin from ground in order te set the fuses correct.

edit: if fuses are set for external crystal, external resonator or external RC oscillator, you can safely inject that 1MHz into the Xtal1 pin.

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

Not easily done w/ a QFN!

If this is a fuse problem, what else could it be other than the CLKI pin?

Internal crystal would work. External crystal would work (assuming it isn't a damaged crystal).

Anyhow, I'll give it a shot injecting on XTAL1

Science is not consensus. Science is numbers.

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

First answer my question

Quote:
U10B is having these problems, I presume ?

There is no escape from reading the datasheet. I had to do that as well, and it's even not my problem.

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

I am not sure I understand your last statement.

Yes, it is U10 - that is the [only] AVR.

I am not trying to avoid reading the data sheet. ON the contrary, I have actually read the data sheet. I was merely pointing out that all of the clock sources should be present (except for a signal on CLI) - unless the crystal somehow got damaged.

Science is not consensus. Science is numbers.

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

Just now I notice that, for clarity, (good thinking) that one AVR is shown in two parts.

The crystal being present doesn't guarantee it's oscillating.

I looked at page 176 of the datasheet. Fuses define how the Clock Multiplexer is set.

Also checkout pages 87 and 88. The 30pF (C28 and C29) may be too high

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

Page 555: 20pF is recommended as load capacitor for Xtal.

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

That is merely a suggestion. The actual capacitor value depends far more on the crystal more than the MCU. This circuit works very well on 10 boards.

It WAS working on this one. It is possible the fuses were flipped. It is also possible that either the crystal or the MCU got zapped.

Almost ready to test the XTAL1 pin...

Science is not consensus. Science is numbers.

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

Does the manufacturer of the Xtal recommend 30pF ?

Note that with the AVR's internal trim capacitors you can only decrease the frequency !

Did the injection work ?

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

Edited:

Page 555/556 is quite clear on the maximum loadcapacitance.
From the datasheet:

Quote:
CEXT32= 2·(CLOAD32– CPAR32– CPAR_PCB) = max 20pF

See also page 541

You may have a short between one crystal-leg and the crystal housing. Even injection fails then !

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

O crap ... those specs are for the 32768 crystal. Sorry for that.

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

Page 541:

CX1, CX2 16MHz crystal load
capacitor
12 pF AVX <<<<===========================
Murata
06035A120JA
GRP1886C1H120JA01
COG
(0603)
5% 50V

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

Take a look at this application note, specifically the section at the top of page 3:

http://www.ecsxtal.com/store/pdf/quar_des.pdf

The crystal I am using is from this vendor, and expects a 20pF load.

Science is not consensus. Science is numbers.

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

Yet it contradicts with what Atmel writes in their datasheet.
Btw, I (would) never use 30pF for C28~29. The internal oscillator circuitry may have difficulties starting with such a load. Learned that from the datasheet.

Any luck with injecting a clock ?

Almost midnight here.
You could ask ka7ehk (Jim Wagner) for advice.

cheers

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

Alas, my colleague is in a different office, and gone for the night. I have everything set up for him to test in the morning (i.e., code for a different board).

The 30pF Capacitor is not the true load as seen by the MCU. Besides I have 9 other identical boards, plus 4 similar boards (with an identical crystal/capacitor schematic), all of which function exactly as expected w/ regards to clock frequency.

I will post results of the injection test in the morning here.

Science is not consensus. Science is numbers.

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

Results: negative.

Tried the injection test this morning to no avail. Don't really want to do an injection on CLKI, as that entails cutting a trace on the board. At this point, it will be cheaper to just replace both the MCU and the Crystal.

Science is not consensus. Science is numbers.

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

What a pitty. So we will never know what went wrong :(

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

Unfortunate, at best. However, not really worth the resources to truly study it.

Science is not consensus. Science is numbers.