avr programmer to detect burned pin?

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

Hi Guys,

I have an expensive Labtool 48 XP universal programmer. (very nice programmer)

Suddenly one day a year after I purchased it, the company decided to just stop supporting the $1100 USD programmer.

No worries, it still programs a great deal of devices, but I have to use windows XP which is a big problem these days.

One thing the programmer did wonderfully was detecting a poor connection on a pin, and it would display a warning.

Then you could choose to abort, or continue.

 

Recently I had some simple code that turned on an LED. The LED would not  turn on and I was going crazy trying to figure out why.

Turns out the pin was burned, and I don't know how it happened.

Normally I would read the chip with the Labtool programmer to determine all the pins were working.

 

The burned pin was not one of the ISP pins so the avr programmed & worked well except the pin used to turn on the LED.

 

Just wondering if anyone knows a small circuit I can buy or build myself to detect a burned pin.

I am curious as to how they are determining that the pin is actually faulty while being programmed.

I am certain that some small code can be written to check each pin however I am more concerned about when it is being programmed.

Any advice, links to circuits would be greatly appreciated.

 

 

Last Edited: Mon. Feb 1, 2021 - 02:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, two thoughts.

 

It is time to dump the Win XP based programmer that is no longer supported...

 

I'd mention that an official Microchip SNAP programmer costs $25 USD, and is often on sale for 1/3 or 1/2 off.

It works with Studio and with MPLAB X, both under Windows 10.

 

Next:  In what way did the old programmer test the I/O pins?

Was the microcontroller plugged into the programmer, in a ZIF socket, for example?

I.E., was it programming and testing a stand alone chip that was NOT connected to other circuitry on a PCB?

 

That task is easy, just program the micro to turn on every pin as an ouptut and then read back 1's and 0's.

Then program the pins as inputs and read in 1's and 0's.

The program can be as sophisticated as one desires to check simple faults, or to look for sticky pins that follow the adjacent pin's level, etc.

One could even test the internal pull-up and pull-down resistors, etc.

 

If one is merely connecting the progarmming signals to a programming header on a PCB then I don't know how it would actually test every I/O pin on the micro.

Futhermore, I'm not sure I want it mucking around with driving pins that might well be connected to sensors that are driving the pin, potentially leading to a signal contention.

 

JC

 

Edit: Typo

Last Edited: Sun. Jan 31, 2021 - 12:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, on an AVR, during normal programming, all of the GPIO pins are reset to be floating inputs. Between the reset and the time that the program starts executing, the PORTx, DDIRx. and PINx registers stay in the reset state, which leaves them as floating inputs. In some debugging environments (maybe JTAG, maybe others), you MIGHT be able to write to port control registers. 

 

Jim

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

DocJC wrote:
It is time to dump the Win XP based programmer that is no longer supported...

i have stopped using the PC that runs on XP, so yes.

 

DocJC wrote:
Next:  In what way did the old programmer test the I/O pins?

Was the microcontroller plugged into the programmer, in a ZIF socket, for example?

I.E., was it programming and testing a stand alone chip that was NOT connected to other circuitry on a PCB?

 

Yes it was a pdip 28 pin atmega8, inserted into the programmers zif socket. I am 100% certain that the universal programmer

programmed the atmega in parallel mode. I guess when the atmega is in reset, all the pins are inputs.

 

What I am curious about is if the pin is burned, what state is the pin in and how does the programmer determine if there is a poor connection?

This programmer has a huge Xilinx so it can adapt to any micro controllers pin out which is why it supports hundreds of devices.

 

I would like to know if there is a way to test the chip without programming any test code into it.

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

ka7ehk wrote:

Well, on an AVR, during normal programming, all of the GPIO pins are reset to be floating inputs. Between the reset and the time that the program starts executing, the PORTx, DDIRx. and PINx registers stay in the reset state, which leaves them as floating inputs. In some debugging environments (maybe JTAG, maybe others), you MIGHT be able to write to port control registers. 

Jim

 

Yes I was thinking that the programmer may try to change the state of the port pins and then read them back, but how would the atmega respond on a working pin when it is in reset?

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

When executing its test, the programmer simply programs in a test program to test the pins.

 

When the Test is done, which perahps takes only mSec's, it hten downloads the user's program.

 

JC

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

Just wondering if anyone knows a small circuit I can buy or build myself to detect a burned pin.

The LED would not  turn on and I was going crazy trying to figure out why.  

You are on track to answer your own question laugh

 

Aside from the led detector, a few burnout types:

output always open

output never opens (no Hi-z mode)

output shorted (or semi-shorted) to Vdd

output shorted (or semi-shorted) to Gnd

output drive impedance too high (semi-open)

Input unresponsive (blown input stage)

internal "shorts" between adjacent pins

Actual level checks (outputs and input thresh)

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sun. Jan 31, 2021 - 09:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

newbie123 wrote:
I have an expensive Labtool 48 XP universal programmer. (very nice programmer)

Suddenly one day a year after I purchased it, the company decided to just stop supporting the $1100 USD programmer.

Replaced by the 48UXP?

Advantech Equipment | Production Programming of Microchip AVR® and SAM Microcontrollers

 

"Dare to be naïve." - Buckminster Fuller

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

gchapman wrote:

newbie123 wrote:
I have an expensive Labtool 48 XP universal programmer. (very nice programmer)

Suddenly one day a year after I purchased it, the company decided to just stop supporting the $1100 USD programmer.

Replaced by the 48UXP?

Advantech Equipment | Production Programming of Microchip AVR® and SAM Microcontrollers

Mine is not the "U" for USB. My programmer uses the parallel port.

They want something like $200 USD per year for support. I understand this because the unit programs so many hundreds of devices.

I first got the Labtool48 way back, then as soon as windows XP came out they dropped support,  so I went for the Labtool48XP.

Soon as windows 7 came out not even one year later I found they didn't want to support the XP version unless I paid more.

So I gave up. I am curious to know how if any of their stuff currently works with windows 10!

 

DocJC wrote:
When executing its test, the programmer simply programs in a test program to test the pins.

When the Test is done, which perahps takes only mSec's, it hten downloads the user's program. JC

I am not sure about that. Sometimes a necessary pin is burned  (like PB7) which would be necessary for parallel programming (one of the pins on the data port) 

so how does the programmer get the code in when it can't program it?

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

so how does the programmer get the code in when it can't program it?

If you know it can't be programmed by any means, then why do you need to check any other pins?  What types of pin faults are you hoping to check for?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

I would be very surprised if any universal programmer downloaded a test program to the chip in the socket. Far easier to simply hold it in reset as just externally pull each pin up and down and monitor what happens.

 

My reasoning...you can use them to program OTP parts. That's not going to work out well if you first download a test program. Ditto UV erasable parts.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Far easier to simply hold it in reset as just externally pull each pin up and down and monitor what happens.

That wouldn't seem to be much of a test, the pin driver and/or rcvr could be completely blown out & go undetected.  At least this might find shorts .

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:
If you know it can't be programmed by any means, then why do you need to check any other pins?  What types of pin faults are you hoping to check for?

I just want to know if a pin is faulty, sometimes it's not the pin, it's the programmer.

I am curious to know how the programmer checks every pin.

Last Edited: Mon. Feb 1, 2021 - 05:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just want to know if a pin is faulty

It was already pointed out there are many possible failure modes---are you including all of them?  What do you consider faulty?

 

Unless the programmer puts in code to check all pins, or possibly uses JTAG, it probably can't do a check...For example, if it is going to provide a digital signal to a pin to test it, some code AVR is needed to try to read that pinto test it.

 

Just wondering if anyone knows a small circuit I can buy or build myself 

You can hook up a bank of leds and program your avr to  light  each one up on-by one...that shows the outputs are driving independently of each other.   Once you  know some leds are working, you can supply signals to the pins one-by one & verify they are being received by the AVR, using the led as an indicator.  Instead of using leds & switches...these can be monitored & supplied by an external AVR you use as part of your tester.

If you just want to see if a HI-Z pin is shorted to either rail, you can pull it high & low, through a resistor, say 1K...it should draw no current.  If large current is detected, then that pin is shorted to a rail. 

 

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:
It was already pointed out there are many possible failure modes---are you including all of them?  What do you consider faulty?

Unless the programmer puts in code to check all pins, or possibly uses JTAG, it probably can't do a check...For example, if it is going to provide a digital signal to a pin to test it, some code AVR is needed to try to read that pinto test it. 

A faulty pin is one that can't be used, however it is faulty is regardless. Yes the programmer can do this, it is the topic of this discussion.

Here is an example of an atmega8515 with Pin 3 burned. I can program it with ISP and use it normally as long as pin 3 is not used (PB2).

Now there are those who will argue that the device is not reliable but I am not here to debate this at all.

Just wondering how the programmer discovers that the pin is burned without programming it. Pin 3 (PB2) is required for parallel programming,

therefore the programmer detected this pin is bad somehow without programming it at all.

avrcandies wrote:
 Instead of using leds & switches...these can be monitored & supplied by an external AVR you use as part of your tester.

If you just want to see if a HI-Z pin is shorted to either rail, you can pull it high & low, through a resistor, say 1K...it should draw no current.  If large current is detected, then that pin is shorted to a rail. 

This is exactly what I was thinking. I am not interested in trying to program code into the device with 30 or so LED's, and besides that would not tell me whether other pins are bad like xtal1, xtal2, ALE, etc. 

 

Again I am just curious to know how a bad pin can be detected without programming the chip with specific code, just as the programmer does.

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

Here is another example of an atmega8515 with PD0 burned. I can program it with ISP or parallel and it verifies, however PD0 is damaged internally.

here is what happens when you insert the chip upwards one slot in the zif socket:

Here is another one with pin 13 burned it can be programmed with ISP only.

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

A faulty pin is one that can't be used ...Yes the programmer can do this, it is the topic of this discussion.

NO it cannot  (poor contact is not a pin fault, nor is it inclusive of all fault types) ....you want to really check it?  Describe what you consider to be a pin fault...if you are sending a signal into an IO pin &  the AVR can't see it , perhaps due to being zapped, the only way to know that is to try reading it using AVR software (or perhaps JTAG).  You cannot tell from the outside that it can't read the pin (if the pin is shorted high, it might indeed always read as a 1---but you can't tell from the outside).

 

whether other pins are bad like xtal1, xtal2, ALE, etc.  ---yes that requires even more sophisticated testing!

how a bad pin

Once again, please list the specific defects that you want to test for....you can refer to #7 for the most common problems.  Where di you come up with this term "burned" --it is a vague failure type, like "blown"... to make a tester, you need to talk about specific failure modes.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Mon. Feb 1, 2021 - 11:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


this one?

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

yes, you can see the "48XP" is greyed out so even if I wanted to pay, I would first need to get another programmer before they will allow me to pay $200 USD per year for "support"

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

newbie123 wrote:
Again I am just curious to know how a bad pin can be detected without programming the chip with specific code, just as the programmer does.
Try the following with one of the damaged AVR :

  1. apply VCC relative to GND
  2. assert RESET
  3. diode test the I/O pin with a multimeter
  4. repeat step 3 for each I/O pin
  5. de-assert RESET
  6. remove VCC

AVR injection current is ideally limited to 1 mA (specified for megaAVR follow-on)

Proposed is current source and current sink to inject 0.5mA; confirm the pin's voltage is correct for each of three states (source, sink, tri-state)

AVR damage :

  • ESD suppressor shorts or leaks
  • bond wire opens
  • VCC shunt shorts or leaks

A "lot" more current to open a bond wire than damage an ESD suppressor.

AVR I/O multiplexers and switches can be damaged though more likely is the ESD suppressor.

 


Electrical Characteristics – TA = -40°C to 85°C | ATmega8A Data Sheet

Absolute Maximum Ratings | ATmega808/809/1608/1609 Data Sheet

Absolute Maximum Ratings | AVR® DB Family

MN36 (Extech)

[middle of middle column]

Diode Test

Test current of 0.6mA maximum, open circuit voltage 1.5V DC typical

 

edit : in retrospect, simply do only the diode test (current and voltage are limited)

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Feb 2, 2021 - 12:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

newbie123 wrote:
I am not sure about that.
That is sometimes done during PCBA manufacturing; there's process feedback to improve the process.

Low-rate PCBA production typically doesn't have high speed PCBA testing; so, a test fixture plus BIT software into the AVR.

AVR have more that adequate ESD HBM though reduced ESD MM; AVR can be damaged during PCBA manufacturing.

PCBA manufacturing equipment may be moved or partially disassembled during cleaning; one might forget to reattach a grounding strap or a static dissipator may be degraded.

 

BIT - Built-In Test

HBM - Human Body Model

MM - Machine Model

 

"Dare to be naïve." - Buckminster Fuller