Atmega 32 Chip not responding

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

Hello, i made the stupid mistake to write flash with a low voltage (4.2v) supply (4.5v si minimum for atmega32), the write failed and after that chip is not responding any more, i tried to fix the chip with the “fusebit doctor“(it worked in the past for other bricked chips) but no luck here... Any ideas?

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

For parallel programming Vcc should be 5V +/- 10%

But serial programming should work for Vcc is 2V7 to 5V5.

 

I don't know how tight your budget is, but a Mega32 is about $2.25 from Ali/Ebay in dip package and < $1 in smd.

How much time are you willing to spend on that?

https://www.aliexpress.com/whole...

 

I it completely dead?

Can you still read the signature bytes etc.

Maybe you just made a silly mistake and your Vcc has nothing to do with it.

Check wiring etc. and try every programming method you have.

But don't spend too much time on it. There are far more intersting things to do with AVR's than trying to revive a single dead chip.

 

 

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

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

Yep completely dead, no signature no data exchange no nothing... And i'm 100% shure that HW is ok and the problem came from low vcc while programing. Now the bricked chip is in 40 DIP package, and i have a few chips in QFP, so i wanted to try some way to fix the chip before doing an adapter board for QFP to DIP, buying a chip in 40DIP it might take about 2 weeks here... All this is just the development board hence 40DIP

Last Edited: Fri. Jan 12, 2018 - 04:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Even with a non-L Mega32, I find it hard to believe that 4.2V during ISP would cause such dire results.  8.2V, maybe.

 

I suppose the "log" is gone.  If "write flash" failed, then wouldn't the ISP sequence stop?  And not continue on to fuses?  And what mega32 fuse combination would cause the symptoms?  SPIEN is not available via ISP, is it?

 

If the chip is that damaged, then what makes you think that HVPP will help?

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

well the board has a 5 v regulator so there was no way higher voltage than 5v. So the board was powered by a discharged 2cell lipo ( battery had 6,2v and  2v drop-out for 5v regulator, hence 4,2v vcc ) every thing was measured after "incident". Now i may mislead you a bit the programer (usb_asp) did write flash (only flash, i selected write only flash, no fuses) but then verify failed and that was concluded as a write failed and tried again and chip did not respond. So this is why i think because of low voltage something was messed up in there  and HVPP might revert the chip back....but something is still odd, after that happened, with same battery, i programmed another board with an atmega32 but in QFP package and it worked well... 

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

Mihai_F wrote:
(only flash, i selected write only flash, no fuses) but then verify failed and that was concluded as a write failed and tried again and chip did not respond.

IMO/IME a flash write at 4.2V would not be a problem, and almost surely could not have caused your dead chip.  Was it dead before the "write flash"?  Did the ISP sequence first do a Read Signature, which completed?  Then an Erase Chip, which completed?

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 i remember it was all green until the verify failed, so: chip found atmega 32, erase, erase successful, write flash, write successful, verify , verifying failed and after that bricked chip..., the chip was successfully programmed a day before brick event,  with no HW changes only minor SW changes (some variables added) when tried after a day resulted in dead chip...

one thing to note chip was about 2 yeas old and had probably more than 700 writes/erase cycles on it, yet still far from 10000 writes/erase cycles.

this is a bummer, only because the time needed to make the board work again.  

Last Edited: Fri. Jan 12, 2018 - 09:16 PM