About to give up using TQFP atmega's, they just don't work!

Hi. I think I've been able to use an atmega328p TQFP one time, but I've failed numerous times, I just can't upload any code to them! I've previously uploaded the bootloader by just holding the chip down to the pads on a custom made arduino shield, while this worked, I'm afraid that it's too easy for the wrong pins to get a connection to the wrong pads. I could hardly get any of my chips to work in-system so I figured that I broke them all when I uploaded the bootloader (even though it said it was successful). This time around I used one of those TQFP adapters, but it still doesn't work! Uploading the bootloader went smoothly, it's after I've soldered the chip to the board that the problems occur. My PCB was flawless, I didn't find any short anywhere. I soldered the TQFP (with a bootloader) to the board, checked every single pin for a short (there was none), soldered a 16Mhz crystal, 22pF crystal caps, 10kOhm RST pull-up and a 470uF decoupling cap. I drew short wires from RST, RX, TX, +V and GND to my arduino board and tried to upload, but nada. I get this "not in sync" when trying to upload a code. I have no clue what so ever on what to do, I think I might have to give up TQFP's for good and make sure I can fit a huge and bulky DIP chip on every design in the future :@

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

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?

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

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.

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.

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.


Just add some jumpers to connect 10-pin header to AVR ISP programming header.

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?

Plecto:
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 :slight_smile:

//Basel

The adapter lets you install the bootloader without having a header or access to programming pins.
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.

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 Prototyping small embedded projects with Arduino | David Crocker's Solutions blog 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?

The adapter lets you install the bootloader without having a header or access to programming pins.
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?

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 Prototyping small embedded projects with Arduino | David Crocker's Solutions blog 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?

I uploaded the bootloader using one of these: http://www.ebay.com/itm/Flap-QFP32-TQFP32-PQFP32-TO-DIP32-Programmer-Socket-Adapter-Conveter-IC51-D0090-/130834643503?pt=LH_DefaultDomain_0&hash=item1e765a3a2f

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 :frowning:

Plecto:
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.

Plecto:
I uploaded the bootloader using one of these: http://www.ebay.com/itm/Flap-QFP32-TQFP32-PQFP32-TO-DIP32-Programmer-Socket-Adapter-Conveter-IC51-D0090-/130834643503?pt=LH_DefaultDomain_0&hash=item1e765a3a2f

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.)

Plecto:
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.

Plecto:
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.

Plecto:
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.

Plecto:
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.

Plecto:
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 :frowning:

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.

Thanks for a great reply SirNickity, I'll try to be a little more specific when explaining.

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.

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 :slight_smile: 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 :frowning:

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 :frowning: I have been looking at C3 (the crystal cap) and thinking it was the 470nF cap :frowning: 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).

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

Plecto:
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.

Thanks, that's much better -- OK, let's see:

Plecto:
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?

No, not quite. With a pull-up, if there's no overriding input, the RST pin will be high, but as soon as there's another signal with lower impedance, it will win. Not pulse, just stay at the level supplied. So a low-impedance DTR LOW signal should hold the pin low until it is removed. The only time it wouldn't is if 1) there's already a cap in your programmer cable, so it pulses instead of holding low; or 2) the DTR pin has an impedance close to, or more than, your pull-up resistor.

Plecto:
You assumption is right :slight_smile: .... I'm not sure what else to tell :frowning:

That's perfect, thanks.

Plecto:
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

Looks good, except there should be a 10uF - 100uF cap somewhere (not so important where physically, so long as it's across Vcc and Gnd), plus your ceramic decoupling caps at Vcc, Avcc, and Aref (if you're using analog inputs anyway). Your regulator will be happiest if there are caps on its input and output as well, which you're doing with C1/C2, so that's good. Their placement is fine. (Assuming the regulator pins are, in order, Gnd, Output, Input.)

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

This one's going to take a bit of time to chew through. More on that in a bit.

Plecto:
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

I guess that depends on the timescale of your scope, but I would think a couple blips would be evident. You might miss it on a DMM, but a scope should reveal something is happening. If you have an edge trigger mode, that should tell you for sure.

If I understand all your posts correctly, you've never had any trouble with ICSP nor serial via your breadboard setup, right? It's only when you move to the PCB you have problems? OK, looking through the layout, but I don't have the TQFP pins memorized, so I have to do some stare-and-compare with the datasheet.

I see some problems...

Pin 21 (the 4th down on the right side) is Gnd, but you haven't connected it.
Pin 20 (the 5th down, just below 21) is Aref and should have a 0.1uF to Gnd if you intend to use analog inputs.

It looks like you're tying SHDN on the MCP4231 to Vcc, which makes it pretty useless. (Edit: Oops, no, it's active LOW, nevermind.) Why is R7 there, on the clock inputs between the two MCPs? You're grounding WP on the right one, and not on the left one. Is that intentional? There's a (weak) pull-up on that pin, so the grounded one will not accept changes but the other should.

I haven't gotten a whole lot farther than that... Without knowing what other parts of this circuit do, and having the pinout for the LCD, I can't check it 100%. Do you have a schematic? It would make it easier to spot errors. Already though, I fear there are enough mistakes to make this PCB design suspect. (Sorry. Happens to all of us.)

No, not quite. With a pull-up, if there's no overriding input, the RST pin will be high, but as soon as there's another signal with lower impedance, it will win. Not pulse, just stay at the level supplied. So a low-impedance DTR LOW signal should hold the pin low until it is removed. The only time it wouldn't is if 1) there's already a cap in your programmer cable, so it pulses instead of holding low; or 2) the DTR pin has an impedance close to, or more than, your pull-up resistor.

Not sure why I have such a difficulty understanding this :frowning: Isn't the RST pin tied to GND during the uploading? If there's just a short pulse on the RST pin, how does the MCU know when to stop downloading code and start running the program? When scoping the RST pin, it is kept HIGH so it's not tied to ground constantly by the programmer. I will try and scope it again to look for that pulse. If you take a look at the "how-to upload bootloader" and the "arduino standalone" schematics and tutorials, there is no mention of this cap so I can only assume that it's already on the arduino board.

I see some problems...

Pin 21 (the 4th down on the right side) is Gnd, but you haven't connected it.
Pin 20 (the 5th down, just below 21) is Aref and should have a 0.1uF to Gnd if you intend to use analog inputs.

It looks like you're tying SHDN on the MCP4231 to Vcc, which makes it pretty useless. (Edit: Oops, no, it's active LOW, nevermind.) Why is R7 there, on the clock inputs between the two MCPs? You're grounding WP on the right one, and not on the left one. Is that intentional? There's a (weak) pull-up on that pin, so the grounded one will not accept changes but the other should.

I haven't gotten a whole lot farther than that... Without knowing what other parts of this circuit do, and having the pinout for the LCD, I can't check it 100%. Do you have a schematic? It would make it easier to spot errors. Already though, I fear there are enough mistakes to make this PCB design suspect. (Sorry. Happens to all of us.)

I know what a pain it it so reverse engineer a schematic from the board layout alone, you have my respect :smiley: My Eagle cad has marked Pin 21 as "AGND" so I thought it was for the gnd for the A/D which is why I didn't connect it :frowning: The datasheet has just marked the pin as "GND" so I'm not sure. Why does the atmega328 TQFP have three GND pins and two VCC pins excluding the ones for the ADC? It's not like the MCU uses so much current that a single pin can't handle it? What purpose does the different GND and VCC pins have?

R7 is a 0Ohm jumper resistor. WP is simply a "NC" on these chips so one of them is grounded because it was the only path for the GND trace. I can post the schematic if you want, but the only components that has been soldered to the board are the ones in the schematic I previously linked, the majority of the pins of the MCU goes nowhere.

Ehm... it seems like connecting pin21 to GND did the trick, I feel a little bit foolish :(. I've now soldered the LCD to the board and it's still uploading code :smiley: I still have a strong feeling that something will fuck up as I solder more and more components to the board though, I believe I know Murphy pretty well and he isn't giving up without a fight. I'll just keep my fingers crossed :slight_smile:

Plecto:
Not sure why I have such a difficulty understanding this :frowning: Isn't the RST pin tied to GND during the uploading? If there's just a short pulse on the RST pin, how does the MCU know when to stop downloading code and start running the program?

Been here before.

Referring to downloading a sketch, this is done by the bootloader. The bootloader itself is a program running on the Arduino, it has to run which it clearly cannot do whilst in reset. The purpose of the reset is - to start execution of the bootloader which has a certain initial period during which it waits for synchronisation of the download process, failing which it jumps to start the sketch itself.

This should not be confused with ICP (ISP) programming, which is indeed a special mode initiated by holding the chip in reset whilst it is clocked by the ISP lines.

Plecto:
If you take a look at the "how-to upload bootloader" and the "arduino standalone" schematics and tutorials, there is no mention of this cap so I can only assume that it's already on the Arduino board.

And indeed that is an essential part of the Arduino design for each board apart from the Leonardo types, as you will find looking at the schematics.

Uploading a bootloader must be done as ISP, so of course, no capacitor. The "standalone" schematics must show the capacitor only if they anticipate auto-reset to start the bootloader, otherwise they will necessarily describe a manual reset,