In the annuals of strange things happening with ones Nerdkit.

I have been modifying the tempsensor code trying to get a stable reading so I have probable programed my ATmega328P micro 7 - 10 times today maybe even more.

It was working fine and then it started reporting the "programmer was not found" this was after successfully programing it all morning.

Now this might have been caused by a zif socket wiggling loose. I sometimes use 28 pin zif sockets when I am programming so that I can easily switch mcus.

So this "might" have been the reason.

I moved the micro over to another breadboard and successfully loaded the program a couple of times then I just left it running.

Now here is the part where it hurts, after maybe half a hour I looked back at the LCD and I have the two black bars.

The programming switch is still in run mode.

I tried other micros (caution I have found that is not necessarily a good idea, but I always forget) and they got the two black bars in run mode also.

Then I went back to the original breadboard and found the loose zif.

The two replacement micros run and program fine but the original one still would not program or run.

So I fired up my windows machine so that I could run AVR Studio to check the micro's fuses.

First thing I always do is to read the Signature, this failed.

Then I looked at the fuses and they were/are all blown 0xFF.

So another one bites the dust.

I do not know if it was the wobbly zif socket that caused this or what. The device had worked successfully after switching breadboards after the wobbly zif.

Once the Signature is gone there is no recovery route.

Now you know why my hair is turning grey.

Ralph

So the 0xFF just means the chip is not responding? Maybe the reset pin is or the serial programming somehow became disabled?

I built a high voltage programmer and was finally able to recover my entire bag of chips that I have been saving. Fortunately all of them were still ok and just had bad fuse settings.

The only two I have completely ruined actually smoked when I accidently put 12v on Vcc. So I would think your chips are ok and all you need is a HV programmer to set them straight again.

I am using my ATmel Dragon in High Voltage programming mode.

The fuses can not be be changed even with High Voltage since the Signature is not correct!

The Signature is also reported as 0xFF 0xFF 0xFF.

I have never seen the magic smoke, only once do I know I put 15volts across the rails blowing the mcu and the LCD.

That of course was a different mcu.

I have probable 10 -12 mcus that I have accumulated over the year that no longer have the correct Signature so they are unusable.

I sure would like to recover them but nothing I have found so far has done it.

I've though of making a true parallel port high voltage programmer possible that might work.

Ralph

Oh, then you have a HV programmer and they are reading 0xFF. Yep, they're toast.

It doesn't matter how the HV programmer interfaces to your PC, serial or parallel, to program the chip using high voltage so you wouldn't get additional benifit from building one that connected via the parallel port. I didn't do that either, I emulated AVR910 with a usb/serial interface but instead of programming via SPI it uses HV. It works fine with avrdude just like an ISP programmer.

I have not had the best of experiences using programmers.

Actually the best I had was a unnamed beta isp programmer that has never been mentioned again.

You outlined a programmer in another thread that duplicated what the beta ISP programmer I had did.

I have never been able to get ISP to work with the Dragon in fact I have a STK600 that I can not get to work with ISP again only HVPP works.

I just got some mcus that have a CAN bus so I will breakout the STK600 again to see if I can get it to work using ISP. I want to play around with OBD-II.

I would also like to follow Rick's tutorial on programming the bootloader someday.

Right now I just load the foodloader.hex file directly using AVR Studio when I have some blank mcus.

Ralph

You're in good shape if you can put the bootloader on new chips. I wouldn't worry about SPI until you decide you don't want to use the bootloader for some project.

What mcu's did you get that have a CAN buss? That would be fun to experiment with but my toyota is older than the CAN buss so it's out. But maybe my 97 ford diesel has one.

I did implement a nerdkit spi programmer similar to what I outlined in the other thread. I'm on my 3rd version of the code which I recently cleaned up and added support for 4 simultaneously connected target avr's. It's working pretty good but now I want to change the byte at a time eeprom load to page at a time because I've found by implementing page at a time in the HV programmer that it is much faster. I want to post my nerdkit spi programmer at some point when I am sure it is problem free and no further enhancements are needed. Probably in another month or so.

I got some MEGA64M1 mcu's. They have a CAN bus and a LIN bus plus channels for Qtouch.

I want to do some touch screen work so I purchased the micros and the STK600 Routing board and Socket board so that I could do some development. Of course I have to get the SDK600 working.

I doubt my 1999 Ford Ranger uses the CAN bus so I probable should have looked into it further but the CAN bus has a lot of interest.

Plus my Digital Analyzer now has a CAN Decode library to view CAN bus activity and I can setup the analyzer to output a CAN data stream for testing.

I can easily setup a CAN environment on my desktop.

It was also suggested that I should get some CAN Transceviers so I have some of those also.

I really have to learn Eagle and make up some PCB's as very few chips are DIP any longer.

Now what about the "circumstances" of my blowing the mcu doesn't anyone have anything to say about that?

Or is it just a normal everyday event to be expected.

Ralph

Blowing your fuses is not a normal everyday event. I haven't blown any outside the two I fried with 12v on vcc. Perhaps the voltage regulator for your protoboard is not working so good. Or there is a transient short on your protoboard that occasionally dumps 12v onto vcc if the board is bumped or otherwise disturbed. If not a power related problem then what about a static shock taking out the mpu. Do you have carpet under your workstation? Are your GND's good? Maybe wear a wrist band that is grounded when handling?

Ralph,

Try slowing your comm speed way down. See if you can read the fuses at 112Khz rate. It's worth a shot. If you can, then fix the settings and up the speed.

Also, now that you have a scope, try putting the 'bad' mcu in your circuit, adding power, and then put your scope on the clock out pin- see if you get an 8MHz square wave. See what clock rate you get off a crystal. You can learn a lot just by testing its pins to see if it's "alive" at all.

As for the programmer you can't use, think about it. You have a tool now (scope), you know how to wire the circuit. Use your scope to troubleshoot. Perhaps, your pull-up resistor on pin one (if it uses one) is too high, or too low, preventing the programmer from being able to put the MCU into programming mode. Put your scope on pin one and turnt he programmer on and off, and see what the signal does- the voltage level will tell you whether or not it's trying to control the chip and what happens.

There is so much you can learn by testing and checking :P

Good luck! BM