Hate the AVR

[magvitron]

Hi,
I have accidentally set the internal clock of AT mega 128 RFA1 to an unknown state and now that is not working, 4 IC's are not responding!! hate this thing.. hate the ISP disable bit now I'm more based toward PIC.

 

[kubeek]

So, did you crew the clock or the isp disable fuse? Can you try jtag programmer?

 

[magvitron]

Tried with that, HVP everything the thing doesn't budge.

 

[Semaphöre]

If even HVP doesn't work then it sounds like you burnt the chip. I found a good way to kill AVRs was to power it from 3.3V and then feed it 5V signals. In the data sheet they quietly mention that the voltage on any pin has to be within 0.6V of Vcc. Otherwise I've found them to be pretty resilient in my experience.

 

[kubeek]

If even HVP doesn't work then it sounds like you burnt the chip. I found a good way to kill AVRs was to power it from 3.3V and then feed it 5V signals. In the data sheet they quietly mention that the voltage on any pin has to be within 0.6V of Vcc. Otherwise I've found them to be pretty resilient in my experience.

The main problem with that is that when you feed 5V into the inputs, the protection diodes will clamp it to your 3.3V rail, and because you use series pass regulation then your 3.3V will rise to about 4.3V and most likely kill the rest of the components on the 3.3V rail.

 

[Semaphöre]

The main problem with that is that when you feed 5V into the inputs, the protection diodes will clamp it to your 3.3V rail, and because you use series pass regulation then your 3.3V will rise to about 4.3V and most likely kill the rest of the components on the 3.3V rail.

Does the AVR even have protection diodes? I was powering a Mega328 from 3.3V and programming it with my STK500 running at 5V. The Mega328 died, but STK500 was ok. I added Zener diodes to the ISP lines and it was fine afterwards. Then I finally found the line in the datasheet that I mentioned above

 

[kubeek]

Yes they have them, any CMOS-process chip has them in order to prevent SCR latchup.
But if you have light load on the 3.3V rail and the voltage source attached to the input can supply more current than the load needs, then it will rise the rail to whatever it wants and destroy anything that doesn´t like such overvoltage.
See here for reference: http://www.atmel.com/images/atmel-8159-8-bit-avr-microcontroller-atmega8a_datasheet.pdf page 49

 

[Semaphöre]

Yes they have them, any CMOS-process chip has them in order to prevent SCR latchup.
But if you have light load on the 3.3V rail and the voltage source attached to the input can supply more current than the load needs, then it will rise the rail to whatever it wants and destroy anything that doesn´t like such overvoltage.
See here for reference: http://www.atmel.com/images/atmel-8159-8-bit-avr-microcontroller-atmega8a_datasheet.pdf page 49

Thanks for the link...I think I was looking at the wrong thing. So the 5V input pin forward-biases one of those diodes with respect to the 3.3V supply rail and you end up with 5-Vd as your supply instead. Gotcha. If the diode fails short or doesn't fail open fast enough it won't bode well for the other 3.3V devices in your system for sure.

In my experience the AVR didn't fare any better; I don't know if it was just that pin that blew or the whole chip, but I needed that pin for programming so I was SOL either way.

Anyways, maybe it's related to the OP's problem.

 

[magvitron]

the thing that i tested was a board I bought from spark fun I have downloaded the bit cloud for AVR and tried to burn it on the WSN demo (IEEE 801.15.4). I sniffed the packets with a TI packet sniffer and everything went well for about 15 minutes . Then the end device failed, then the co coordinator, I had some RFA1 left, so replaced it (it was QFN 64 pretty difficult to hand solder, but done it ) . the thing did exactly the same. worked for 15 minutes and then failed, then if I try to burn , avr dude shows sync failure. That's it I'm fed up with the god forsaken thing. Now I ordered a CC debugger and a couple of CC2530 s.
mmmhmmmpp T.. I... (homer).