changing clocks and bricking MCU

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

I am sure this question has been asked a zillion times, but I am going to ask it again.  apologies in advance. 

 

I had an ATmega328P running with an external TTL clock.  I changed the clock fuse to run on the internal 8MHz clock (at least I think I did) so I could use the MCU on a different project without a crystal, and it bricked the device.  Should this have worked, and I did something wrong, or is it a bad idea?  I don't want to try it again if it is a bad idea and brick another chip.  If it is not a bad idea, then I must have chosen the wrong fuse option, or the chip was flakey in some way.  It seems like I should be able to do this, but the one bad experience has me wondering.

 

Thanks in advance.

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

You should be able to switch back and forth between any valid clock sources. Perhaps you reconfigured the fuses, but then didn't "write" the new configuration? Can you simply put the micro back in the board with the external clock source and see if it comes back to life? Cliff has a full tutorial, in the tutorial sub-forum, on unbricking Micros
JC

Last Edited: Thu. Sep 28, 2017 - 06:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you perform a chip erase before-hand (or at the same time as)?

 

If not, did the existing app code tickle the system clock prescaler via CLKPR or clock_prescale_set()?

 

If so, then whatever prescaling your app initiated will now be prescaling from an 8 MHz clock source.  What was the external clock running at?  If, say, you were running a 16 MHz TTL clock, and prescaling by /16 for a 1 MHz system clock, then now you'll have 8/16 = 500 kHz clock.  This can be relevant when programming because the programming clock must be <1/4 of the system clock.

 

and it bricked the device.

How have you determined this?  Show the console output of your attempt.

"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

I always confirm I have the correct fuse settings by going here before I change them:  http://www.engbedded.com/fusecalc/

 

Jim

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

I thought I should be able to go back and forth.  I will try it again with a new chip.  I threw the old one away.  For $1.50 it was hardly worth messing with.  I had no prescalar set.  I tested the chip by pushing the reset button, which should have blinked the LED twice, but I got nothing.  It would have blinked slower going from 16MHz to 8MHz.  I will try it again with some simple code.  I was surprised when it didn't work.  I thought it should have.  The chip was still in the board with the TTL clock wired to XTAL1 when I changed the fuse.  I thought it would ignore the clock input.  I set all ports and pins to input with internal pullup resistor enabled first thing

 

Thanks for the input.

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

MarkThomas wrote:

I am sure this question has been asked a zillion times, but I am going to ask it again.  apologies in advance. 

Apologies accepted ;-), but how can you (member for 6 years) have missed that similar questions surface here more or less on a weekly basis?!?

 


 

Are you aware that Cliff has written a tutorial on the subject, and how to try to resurrect the "bricked" AVR?

 


 

+1 on the check-and-double-check advice by Jim above. Be meticulous not to mix up the low, high and (if applicable) extended fuse bytes. Different software, documentation and web-pages show them in different order. My "generic" model of thought is "extended, high, low" simply because that maps to a high byte being more significant and is "to the left" in that sense. So that is the way I write them down in my notes (digital, paper-based or neurological). Point is: Get a consitent way of thinking about fuses, and stick to it!

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

MarkThomas wrote:
I tested the chip by pushing the reset button, which should have blinked the LED twice, but I got nothing.

 

What blinks the LED?  Bootloader?   Did you erase the chip (and bootloader) when you changed the fuses?  

 

It would be helpful to know what the fuse settings were and to what they were changed too.

 

Jim

 

 

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

One thing easy to forget. If you port the code to a new app while the first version was running on an external signal source and the new on internal, you MUST change the fuses while you still have that external source connected. Otherwise, nothing will get programmed.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

main() blinks the LED first thing on startup and reset. 

 

I did not erase anything.  I just changed the fuse from external clock to internal rc oscillator while the MCU was in its socket on the board with the TTL clock.  After I changed and programmed the new fuse value the LED did not blink on reset or power down/up..  I did not remove it from the board.  I just pushed the reset button and nothing happened.  The LED "on" time is done with a timer in CTC mode, so should have been on twice as long as the code has F_CPU = 16000000L.  

 

I use Atmel Studio to set the fuse values.  I just check the box of the fuse I want set and uncheck the box for the fuse I don't want set.  Some are active low and some are active high.  I don't worry about that and let AS do the work, being lazy.

 

JohanEkdahl wrote:
but how can you (member for 6 years) have missed that similar questions surface here more or less on a weekly basis?!?

I only recently started reading AVRFreaks on a daily basis.  I used to only come here if I had a question.  Lately I have been reading more of the posts, and have actually learned some things by surprise.  I might have read about this in the distant past, which is why I was surprised when the chip bricked when it did.  It is possible I set the fuse to the wrong value by mistake.  That is the most likely scenario.

 

So everyone agrees if have the chip in the board running some program when I plug in my AVRISP mkII, and change the fuse value from external clock to internal rc oscillator, everything should work at half speed without removing the MCU from the board.  Of course UART wont work with the wrong clock speed, but the LED blink should.

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

Some are active low and some are active high

None are active high.  All are active low.

 

That said, AS should 'get it right'.

 

but the LED blink should

Yup.  Possible that there was a communications error while changing fuses (perhaps due to bad wiring), and an uncommanded action occurred.  Such actions could include an incorrect fuse being programmed, or anything else for that matter.

"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

I guess I will have to try it again.  Who knows what might have happened with my USB.  I blew out one port playing with high voltage and setting parameters via UART. 

 

I wonder if USB ports can be changed out inside my laptop.  Now I am using a hub that cost me $6.50 on Amazon.  I think I should have gone for the more expensive one.  Every time I plug something new into it it has to go out and find drivers for everything plugged into it and for the hub too.  Sort of annoying.

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

JohanEkdahl wrote:
Are you aware that Cliff has written a tutorial on the subject, and how to try to resurrect the "bricked" AVR?

Does Cliff's tutorial remind you to make sure you have the chip oriented correctly in the socket.  I changed the fuse on an ATmega328P and it didn't work when I plugged it into it's new home, just like last time.  Then I noticed I had the chip in the socket backwards.  I do that sometimes being sort of ADD and not paying attention.