Go Down

### Topic: About to give up using TQFP atmega's, they just don't work! (Read 9839 times)previous topic - next topic

#### mrburnette

#1
##### Oct 23, 2013, 04:05 pm
Quote
I soldered the TQFP (with a bootloader) to the board, checked every single pin for a short (there was none)

Oh, my... I really wished you had not done that.  Many Volt/Ohm meters have dangerous potential on the probe during resistance measurements... just checking my Metex and it has 3.2V in the mode that is used to check shorts/diodes.  My Fluke produces 2.75V.   It is possible that you fried you chip during the test if there was enough capacitance in test circuit.

Ray

#### Plecto

#2
##### Oct 23, 2013, 04:52 pm
I have never thought of this. If there is one thing I do different when using a TQFP is that i check every connection. I measured my DMM's voltage to 3V, but how can this fry my mcu by giving it 3V? And it's not like my DMM outputs a very high current, does it?

#### mrburnette

#3
##### Oct 23, 2013, 05:14 pm
Quote
I measured my DMM's voltage to 3V

Yes, but measurement of voltage typically implies the creation of a current in the measuring device and then reading the voltage across that known resistance!  So, if you are reading 3V, it really is probably more in open-circuit.  Voltage and current measurements are black-arts and like the Uncertainty Principal in physics, when we try to measure something (or observe it) we interact with the system to change the true nature.

The other issue with DMM is that there may be a capacitance  other than the lead length which is charged to the open-circuit value, typically this will be greater than 3V.  Just playing around with a 10X probe (higher impedance) on my oscilloscope, I observed spikes off the 5V scale just by clicking the scope tip to the DMM on the Ohm scale.

While the uC has internal clamping diodes for static charges, it is uncertain (to me) what the implication would be for continued probing with a DMM producing > 150uA (My Metex in Ohms feeding the Extech on the 200uA scale.

Ray

#### SirNickity

#4
##### Oct 23, 2013, 11:05 pm
Do you have ICSP headers on your finished board?  (If you don't, you should.  Make that standard practice.  At least bare pads you can probe with something.)

I ask because obviously you've gotten ICSP to work on the TQFP ICs.  Your current problem appears to be getting TTL serial to work.  There could be several reasons for that...  Are you providing power?  (Sorry, have to ask.)  Is the board grounded to the TTL serial interface?  Are you sending a reset pulse to the TQFP's reset pin?  (DTR -> 100nF cap -> Reset pin, on the pin-side of the pull-up resistor.)  Is the serial baud rate set appropriately for the bootloader?

For finished products, I've given up using serial -- it's easier to keep using ICSP and forego the bootloader entirely.  That said, I had a couple hours of troubleshooting recently with similar results... I could burn fuses, and even the flash program, but it wouldn't run.  Turns out I had compiled an Intel .hex format file and was telling avrdude to expect a raw binary image.  Oops!

Don't give up on the TQFP package.  If you've communicated via ICSP, the chip is alive and breathing.  That's well over half the challenge.

#### john1993

#5
##### Oct 24, 2013, 05:25 am
pretty much impossible to "fry" an avr with a meter. simply not enough current.

one glaring oversight is using an electrolytic for bypass instead of the proper monolithic type. even a tantalum would be better. replace the 470uf with ,1mfd ceramic disc or chip cap. and as mentioned another .1mfd its absolutely necessary between the ftdi and the 10k pull up for auto-reset to work. you might try manual reset as a diagnostic.

in any case there is no electrical difference between dip and qfp. ive programmed hundreds of them by pressing hard down onto the adapter with a strong alligator clip. by far biggest issue is making sure all the pins are in line and making contact. even chips straight from the factory sometimes need straightening.

#6
##### Oct 24, 2013, 05:31 am
Program the part on board using the ICSP pins, whether broken out to a header or not.

Or, get a TQFP programming adapter like this, which just presses down on top of the board.

http://www.hobbyking.com/hobbyking/store/__46316__Atmel_Atmega_Socket_Firmware_Flashing_Tool_USA_Warehouse_.html

Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

#### Plecto

#7
##### Oct 24, 2013, 06:39 pm
Sorry for the late reply. The pcb is powered from my arduino so it's the same ground. I have pads connected to TX, RX and RST with a hole through them, wires are soldered to these pads and connected directly to my arduino. I don't have a rst cap, but I've honestly never had a problem with this before (my DIP chips don't need them at least).

A TQFP programming adapter looks really nice, but why would I need this exactly?

#### baselsw

#8
##### Oct 24, 2013, 06:56 pm

Sorry for the late reply. The pcb is powered from my arduino so it's the same ground. I have pads connected to TX, RX and RST with a hole through them, wires are soldered to these pads and connected directly to my arduino. I don't have a rst cap, but I've honestly never had a problem with this before (my DIP chips don't need them at least)..

You need the reset cap.. without it the mcu will stay in the reset state (because serial is pulling the reset low while it is open! )... The cap will allow the the reset pin to go low for a brief moment (until it is charged via the 10K resistor connected to Vcc and rst) before it gets charged and goes high..

Try this to test if the missing cap is the problem: disconnect the DTR pin and manually reset the mcu before uploading.. did it work? In that case put the cap where it belongs

//Basel

#9
##### Oct 24, 2013, 11:24 pm
I may have been a little confused over whether you needed that, or if you had done that already (including fuses) and just needed serial interfacing help.
0.1uF cap from DTR to reset, and 10K pullup on reset are usually needed for software autoreset during downloads.  Otherwise, you need a manual reset when the IDE shows "Compiled xxx of 32xxx bytes" or similar.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

#### dc42

#10
##### Oct 25, 2013, 11:17 pmLast Edit: Oct 25, 2013, 11:20 pm by dc42 Reason: 1
How did you get the bootloader on the TQFP chip? Did you set the fuses to use a 16MHz crystal as well as burning the bootloader?

The standard approach when building your own atmega-based system is to include an ICSP header on your board, use an un-programmed chip (no bootloader needed), then set the fuses and upload the sketch using ICSP. See http://miscsolutions.wordpress.com/2011/08/09/prototyping-small-embedded-projects-with-arduino/ for an overview.

Also:

1. Did you include a 0.1uF ceramic decoupling capacitor close to the chip, as well as the 470uF one that you mentioned?

2. You said connected TxD and RxD from your board to the corresponding pins on the Arduino. How did you ensure that the Arduino was not driving the TxD pin?
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

#### Plecto

#11
##### Nov 01, 2013, 01:52 pmLast Edit: Nov 01, 2013, 01:54 pm by Plecto Reason: 1
Quote
I may have been a little confused over whether you needed that, or if you had done that already (including fuses) and just needed serial interfacing help.
0.1uF cap from DTR to reset, and 10K pullup on reset are usually needed for software autoreset during downloads.  Otherwise, you need a manual reset when the IDE shows "Compiled xxx of 32xxx bytes" or similar.

I'm not quite following here. If a RST cap is essential, how come I never have any issues with the DIP atmega328's?

Quote
How did you get the bootloader on the TQFP chip? Did you set the fuses to use a 16MHz crystal as well as burning the bootloader?

The standard approach when building your own atmega-based system is to include an ICSP header on your board, use an un-programmed chip (no bootloader needed), then set the fuses and upload the sketch using ICSP. See http://miscsolutions.wordpress.com/2011/08/09/prototyping-small-embedded-projects-with-arduino/ for an overview.

Also:

1. Did you include a 0.1uF ceramic decoupling capacitor close to the chip, as well as the 470uF one that you mentioned?

2. You said connected TxD and RxD from your board to the corresponding pins on the Arduino. How did you ensure that the Arduino was not driving the TxD pin?

This went down without any issue. I later reconnected it (with the MCU still inside the socket) to see if I could program it using RX and TX and I had no problems with that either. I simply uploaded the Arduino ISP scetch and the pressed "burn uploader". Never had an issue with this in the past.

Why isn't using a bootloader standard? I often develop my code while I'm programming so I need to be able to get data from it using the UART. If I'm going to program it using SPI and the UART it would mean a total of eight cables instead of five. Shouldn't it be just as viable to pre-burn the bootloader using the socket I linked, and then program it just like the arduino is meant to be programmed?

1. I meant to say 470nF, I appologize. It is close to the power pins, or some of the pins at least (there are several GND and VCC pins, not sure why). This could be an issue though, not sure, perhaps I need a bigger electrolytic as well? Then again, a small ceramic cap close to the power pins has always worked for me in the past.

2. Not sure if I understand the question. All I checked was to see if there was a connected between the arduino and my TQFP chip (and there was). I also tried to scope both RST, RX and TX, but I didn't see anything (just a constant HIGH).

I am really tempted to just replaced the chip, but that's what I've done in the past without any luck where the result has just been me burning through chips

#### SirNickity

#12
##### Nov 01, 2013, 08:15 pm
I'm not quite following here. If a RST cap is essential, how come I never have any issues with the DIP atmega328's?

If you're programming via serial, and the DTR (or whatever) pin is constantly low, and that is connected to the RST pin of your ATmega, it shouldn't work.  Ever.  TQFP or DIP, doesn't matter.  You're holding RST low, which should keep the chip in a coma.  The 0.1uf series cap is absolutely necessary to turn that constant DC low into a low pulse.

OK, that's how you physically broke out the pins, but you didn't explain the process you used to get the bootloader onto the TQFP.  DIP adapter in a breadboard with its own crystal, caps, and reset resistor -- ICSP to Arduino running Arduino-as-ISP sketch?  (This is what I'm assuming based on your description, but you're leaving out some detail.)

This went down without any issue. I later reconnected it (with the MCU still inside the socket) to see if I could program it using RX and TX and I had no problems with that either. I simply uploaded the Arduino ISP scetch and the pressed "burn uploader". Never had an issue with this in the past.

A lot of holes in that process as well.  Not that you didn't do it correctly, just that we can't determine that for ourselves based on the explanation.  Since most mistakes are a nagging little detail here or there, it helps to pick those nits.

Why isn't using a bootloader standard? I often develop my code while I'm programming so I need to be able to get data from it using the UART. If I'm going to program it using SPI and the UART it would mean a total of eight cables instead of five. Shouldn't it be just as viable to pre-burn the bootloader using the socket I linked, and then program it just like the arduino is meant to be programmed?

Depends what you mean by "standard".  Arduino != ATmega328P, so remember the Arduino bootloader is an Arduino thing, not an AVR thing.  It's standard for Arduino, not standard for AVR.  The bare chips are not Arduinos yet, they're just AVRs.

This could be an issue though, not sure, perhaps I need a bigger electrolytic as well? Then again, a small ceramic cap close to the power pins has always worked for me in the past.

Sounds like we need to start over.  Can you explain exactly how you have everything wired?  Photos help.  Also, if your PCB is involved in this, the schematic and an image of the board layout will help as well.  I'm taking from your description that you do not have an electrolytic cap anywhere?  You should.  The 470nF (odd value BTW, but OK...) ceramic decoupling cap will shunt noise, but it doesn't do much for bulk storage.  That is likely to cause power starvation, which is precisely what you don't want for stable operation.

Not sure if I understand the question. All I checked was to see if there was a connected between the arduino and my TQFP chip (and there was). I also tried to scope both RST, RX and TX, but I didn't see anything (just a constant HIGH).

You have a scope?  Good.  Do you also have a logic analyzer?  Are you saying all three -- Reset, TX and RX -- were HIGH at all times?  Yeah, that would certainly make it not work.  There's absolutely a bad part or wiring error(s) there.

I am really tempted to just replaced the chip, but that's what I've done in the past without any luck where the result has just been me burning through chips

Throwing parts at it does not help.  More often than not, the problem is not a bad part.  It does happen, but IME, it's usually something more mundane.  Find and solve the real problem.  If you find it's a bad part, then replace it.

#### Plecto

#13
##### Nov 01, 2013, 09:04 pm
Thanks for a great reply SirNickity, I'll try to be a little more specific when explaining.

Quote
If you're programming via serial, and the DTR (or whatever) pin is constantly low, and that is connected to the RST pin of your ATmega, it shouldn't work.  Ever.  TQFP or DIP, doesn't matter.  You're holding RST low, which should keep the chip in a coma.  The 0.1uf series cap is absolutely necessary to turn that constant DC low into a low pulse.

I can see that it wouldn't work if the RST pin was constantly LOW, but I have a 10k pull-up that forces it HIGH. The programmer (my arduino) or a simple button will force it LOW thus resetting it or making it capable of being programmed, won't it? But as I said, I've made due without a cap in every other design (perhaps 20 different designs) without any problems with the uploading.

Quote
OK, that's how you physically broke out the pins, but you didn't explain the process you used to get the bootloader onto the TQFP.  DIP adapter in a breadboard with its own crystal, caps, and reset resistor -- ICSP to Arduino running Arduino-as-ISP sketch?  (This is what I'm assuming based on your description, but you're leaving out some detail.)

You assumption is right Breadboard, 16Mhz crystal, 10k pull-up, caps and then jumper wires from the breadboard to the arduino board. I then removed the DIP atmega from my arduino (the one with the ISP scetch on it), rewired the jumper cables so that they went from RX and TX instead and then uploaded the blink example (with AVR ISP), that went fine and I later tested with my DMM that the code was working correctly. I'm not sure what else to tell

Quote
Sounds like we need to start over.  Can you explain exactly how you have everything wired?  Photos help.  Also, if your PCB is involved in this, the schematic and an image of the board layout will help as well.  I'm taking from your description that you do not have an electrolytic cap anywhere?  You should.  The 470nF (odd value BTW, but OK...) ceramic decoupling cap will shunt noise, but it doesn't do much for bulk storage.  That is likely to cause power starvation, which is precisely what you don't want for stable operation.

Add a 470nF ceramic cap across the rails to this schematic and you have it: http://www.open-electronics.org/wp-content/uploads/2012/03/Arduino_standalone_minimal.jpg

Here's the board layout: http://i42.tinypic.com/2qakbdg.png

The blue wires are jumper wires, not actual traces. You can see the pads right nest to RST, RX and TX that I soldered the wires going to the arduino to. The power SMD package you can see on the left is a regulator, it is not present and Vin and Vout are simply shorted together. The 470nF decoupling cap is C2 and I actually see now that it's kind of close-ish to the GND pin of the MCU, but not that close to the +V pin I have been looking at C3 (the crystal cap) and thinking it was the 470nF cap Anyway, the 10k RST pull-up is R1 and +V and GND is connected to SV2 in the upper right (R11 is a 0Ohm jumper resistor).

Quote
You have a scope?  Good.  Do you also have a logic analyzer?  Are you saying all three -- Reset, TX and RX -- were HIGH at all times?  Yeah, that would certainly make it not work.  There's absolutely a bad part or wiring error(s) there.

I don't have a logic analyzer. I don't see anything when scoping, but that might just be because things are happening very fast. I don't know how the actual uploading is happening, but I can assume that it's some communication back and forth? If the programmer isn't receiving an acknowledge after the first package, it might just sit there waiting? I've assumed that this first package is transferred too fast for me to pick it up on the scope

#### dc42

#14
##### Nov 01, 2013, 09:12 pm

Why isn't using a bootloader standard?

Because the standard way of programming an atmega328 or similar microcontroller - except sometimes when prototyping - is via ICSP, not with a bootloader and serial port. You should always include an ICSP header when you build a standalone atmega board.

Programming via ICSP does not prevent you from debugging via a serial port, or using the serial port to communicate with a computer.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Go Up