jandirks wrote:My first design lacked the center pad and my beta tester couldn't get his mlf32 programmed. Luckily, there was a via that was connected to ground under the mlf32 and he soldered a very thin wire through this via in a way that it made contact with the center pad on the mlf32. After adding that wire, he could program his mlf32.
Okay, good to hear you are moving forwards. As for the ground
problem, I wonder if the other three ground pads were not making
good contact? I would expect the center pad to be internally
connected to the AVR's GND pins (3,5,21).
You can check this with a DMM on ohms, or send a question
to Atmel to confirm (the data sheet is really foggy...).
The only problem after this was that he only could burn the bootloader once. A second try wouldn't work. We are investigating now if this could have to do with fuses... suggestions welcome!
Two things come to mind. Both are known 'gotchas' with AVRs.
(1) The ADC function is shared with part of PortC, the rest of
PortC is connected to the digital supply. AVCC (Pin 18) must
be connected to Vcc externally for the full PortC to operate.
If the ADC is used the AVCC pin should be connected to VCC
with a low pass filter (to keep supply noise out of the ADC).
If by chance the AVCC pin was not connected (due to the
second touchdown on your fixture) the AVR may not work.
(2) The internal fuses select several functions and options.
If you are using ISP serial programing and internal RC Osc.
it's important that you don't accidently set the clock to Ext.
The AVR will freeze. It is possible to reverse the fuses (they
are called fuses but are really EEPROM bits). It is also
possible to drive an external clock into the AVR and reset
the fuses to int RC Osc.
Any AVR chip that programs once and not a second time
could be a victim of lost (external) clocks. There are also
security modes that are set with fuses to prevent the
code from being read out and also to prevent the AVR
from reprogramming. (i.e. You only get one chance).
I have 'burned out' a few AVRs with faulty ISP on prototypes,
but been able to reset the fuses with parallel programming
and external clock using the STK500 demo board.
Finally, when you are programming with ISP for the first
time make sure the ISP clock rate (not the AVR clock)
is very low. If the ISP clock get out of step it can result
in the AVR fuses changing to "one time only" programming.
jandirks wrote:Could you please explain what you mean with 'building up' pads?
Sure. The PCB will have HAL (Hot Air Level) of the plating
over the copper traces and pads. These are masked by the
solder mask which has a thin but finite thickness. It is possible
that your physical contact from trace/pad to MLF/pad is lost
due to these weak or open electrical contacts.
To reduce this risk you can "build up' the pads by adding
solder to the MLF pads on your carrier PCB. That way there
are small bumps of solder above the solder mask. These
can contact the MLF pads on the AVR chip.
Because the solder is soft the tops of the bumps may be
damaged by the MLF, and you might have to reset them.
I'd think that solder paste would be a good start, and
possibly using a flux pen and reheating the solder with
hot air will get you back to nice even bumps.