Go Down

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

SirNickity

#15
Nov 01, 2013, 11:58 pm Last Edit: Nov 02, 2013, 12:07 am by SirNickity Reason: 1
Thanks, that's much better -- OK, let's see:

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.

You assumption is right :) .... I'm not sure what else to tell :(


That's perfect, thanks.

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

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.

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.

SirNickity

#16
Nov 02, 2013, 12:31 am Last Edit: Nov 02, 2013, 12:35 am by SirNickity Reason: 1
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.)

Plecto

Quote
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 :( 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.

Quote
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 :D 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 :( 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.

Plecto

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 :D 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 :)

Paul__B


Not sure why I have such a difficulty understanding this :( 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.


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,

john1993

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?


ground pins on this chip are effectively shorted together (less than an ohm or two) so im surprised to hear hooking up pin 21 fixed your problem. for many of my quick programming adapters only one gnd is used and i never saw a problem. special pain to connect all gnd on chips like m2560 when wiring dead bug style. i do connect avcc to vcc on the other hand because it also powers some io. i suspect there are other issues with your circuit involving bypass caps like i mentioned earlier.

btw its not always necessary to use a series cap and pu on the reset line. only needed for "ill behaved" os like windows that sometimes are unable to wiggle handshake bits in a timely fashion. in many cases reset can be connect directly to dtr. the other handshake output (rts) is more problematic here and best avoided in any case.

SirNickity

I don't know the story behind Windows' abilities re: comm ports, but for that matter, why would a DTR signal need to be "wiggled in a timely fasion" at all?  Even if it took two and a half hours to assert and release DTR, that would still be a "pulse", technically, and sufficient to properly reset the chip.  (Albeit, at the expense of the operator's sanity.)

Based on MSDN documentation, it looks fairly easy to assume control over DTR via the Win32 API.  It looks like you can open the port with DTR either HIGH or LOW, or you can let the driver handle setting DTR based on buffer status (handshake mode).  If you do not use handshake mode, you can toggle DTR with a call to EscapeCommFunction to update the hardware status at any time.

The only potential catch with the above is that, if you want to maintain DTR manually, you have to set it one way or another when you open the port.  Still, all you have to do is read the port status into a device control block before you open it, and just leave the fDtrControl field alone as you specify all your other settings.  That way you still technically "set" DTR, but it doesn't change from what it was already set to.  Not a big deal really.

Sure Windows' serial port driver API could be a little more flexible, but overall, it seems to be more than capable of using DTR as a pulse generator, so I don't quite understand the problem.  :~  It seems more like applications (such as avrdude perhaps) could better manage the driver.  Until then, that DTR cap is required.

As for the power and ground pin discussion ---  I was not aware the AVR connected these internally.  It seems to defeat the point somewhat if this is true.  AFAIK, the whole motivation for separate analog pins was to be able to isolate digital and analog power rails, including the grounds, at least back to some common star ground point.  If the grounds are connected internally, you don't really have that option anymore.  If they're connected internally, I don't know why they are separate pins, except maybe better fault tolerance and internal current sharing.  It seems leaving any of them disconnected is probably not a great habit to get into regardless though.

Now, to be frank, the power distribution on the PCB is not great.  I assume the OP let Eagle auto-route all the connections?  For ground especially, it's probably better to do those by hand -- particularly with thick traces (if not ground planes!), the shortest possible distance back to the main ground terminal, and attempts to use dedicated home-runs from high-current or noisy components.

Paul__B


As for the power and ground pin discussion ---  I was not aware the AVR connected these internally.  It seems to defeat the point somewhat if this is true.  AFAIK, the whole motivation for separate analog pins was to be able to isolate digital and analog power rails, including the grounds, at least back to some common star ground point.  If the grounds are connected internally, you don't really have that option anymore.  If they're connected internally, I don't know why they are separate pins, except maybe better fault tolerance and internal current sharing.  It seems leaving any of them disconnected is probably not a great habit to get into regardless though.


Reference to the manual indicates that the two ground connections are in fact, one and the same and should have negligible measurable resistance between.  This makes absolute sense; the ground is likely to carry more current than any other pin and in fact, the sum of current in any number of other pins other than Vcc.  Since good design practice is to use outputs as pull-downs in preference to pull-ups you generally do not expect the Vcc pin to carry as much current either.  And since ground is the primary reference point including for analog measurements, you want its internal resistance to be as low as possible; it is only a matter of sheer economy not to have more ground pins.

AVcc on the other hand, is not Vcc and is not connected internally at all.  It is what it says it is - the ADC supply.  The manual suggests it should be a decoupled Vcc (decoupled to ground that is) by a low pass filter for best performance.

As to the behaviour of the IDE to the serial ports, it does exactly as it should - opens the port, issues the download, and closes it again (so that another program such as the serial monitor, can then use it).  DTR reflects this operation - correctly.  That you can use this as a reset signal - using the capacitor - is a convenience, but no justification to have the signal behave in anything other than in a standard manner.  There is nothing to criticise about this behaviour.

john1993


why would a DTR signal need to be "wiggled in a timely fasion" at all?  Even if it took two and a half hours to assert and release DTR, that would still be a "pulse", technically, and sufficient to properly reset the chip.


not quite. bootloaders have a limited timeout and anything more than a few seconds (milliseconds with modern loaders like opti) will not work. also note that sometimes pulse is generated on software high rather than low so pulse goes out on trailing not leading edge. ive seen cases where poorly written drivers took a minutes or two to reset the chip. NOT good.

as far as gnd/vcc paul said it better than i ever could. so while i often only connect one of each for quick hacks and flash adapters, in final applications ALL gnd and vcc pins should be used.

SirNickity

I guess you're right about the Gnd... the datasheet doesn't actually refer to "AGnd" in the pinout -- that seems to be an Arduinoism.  Too much time looking at DAC datasheets recently perhaps.  ;)  Thanks for setting me straight.

As to the behaviour of the IDE to the serial ports, it does exactly as it should - opens the port, issues the download, and closes it again (so that another program such as the serial monitor, can then use it).  DTR reflects this operation - correctly.  That you can use this as a reset signal - using the capacitor - is a convenience, but no justification to have the signal behave in anything other than in a standard manner.  There is nothing to criticise about this behaviour.


I disagree with this.  DTR is one of a few ways for RS-232 devices to handle flow-control.  You can't even count on RS-232 devices all requiring or using the various control signals the same way, much less things that aren't even RS-232, but TTL instead.  avrdude isn't meant to communicate with a modem or terminal, it's designed for ICSP.  DTR could justifiably be re-purposed for the (essential!) reset function, and a UART that complies with Windows' driver API would have no problem with this.  Function calls (like EscapeCommFunction) exist precisely for this kind of purpose in fact.  I see no evidence anywhere that this would be some kind of perversion of the standard.

As to the IDE, I never picked a quarrel with how it operates.  Sometimes the DTR toggling can be inconvenient (by undesirably resetting the board if all you wanted to do was monitor the serial output), but it could also be argued that it works in favor of newbies, by presenting them with the output of their sketch from the beginning, rather than risk missing any messages sent during setup() because they opened the terminal window after the sketch began executing.  As it stands, the cap is required since the IDE will hold the signal LOW, but again -- we're talking about software designed for a specific purpose.  There's no reason the IDE couldn't or shouldn't behave in favor of a proprietary hardware design rather than traditional RS-232.  Again, no one uses the IDE to dial their favorite BBS....

not quite. bootloaders have a limited timeout and anything more than a few seconds (milliseconds with modern loaders like opti) will not work.


Yes.  I understand, but that should be plenty of time.  I meant reset can (obviously) be held indefinitely with no ill effect.  Provided the driver can begin communication within ms of bringing DTR high, it doesn't matter how long it takes to toggle it LOW, then HIGH again.  If the driver can't do this, then it's seriously flawed anyway, because it would practically guarantee lost data when used as a flow-control signal between RS-232 devices.  DTR is always managed by software, even when it's the driver monitoring the FIFO and twiddling it accordingly.  For that reason alone, changes to the control signals would need to be agile.  Whatever the case where you saw chip resets taking minutes to complete, the bottleneck shouldn't be Win32's ability to toggle DTR.

also note that sometimes pulse is generated on software high rather than low so pulse goes out on trailing not leading edge. ive seen cases where poorly written drivers took a minutes or two to reset the chip. NOT good.


I don't understand what you're saying here.  What do you mean pulse is generated on software high?  The Win32 API seems to be pretty clear on what happens based on the constants in the DCB, or the parameter sent to EscapeCommFunction.  I don't think it's likely to be inverted.  If it is, that's a bug in the driver.

john1993

#25
Nov 06, 2013, 05:49 am Last Edit: Nov 06, 2013, 05:56 am by john1993 Reason: 1

I don't understand what you're saying here.  What do you mean pulse is generated on software high?  The Win32 API seems to be pretty clear on what happens based on the constants in the DCB, or the parameter sent to EscapeCommFunction.  I don't think it's likely to be inverted.  If it is, that's a bug in the driver.


no, its a hardware issue. the original pc rs232 (12v) ports were active high while these days so called "ttl" ports are active low. ie older ports used 1488/1489 inverting drivers usually not present in modern serial usb adapters. ie totally opposite polarities so software written for one will behave completely different from the other. ie one resets on leading edge while other does so on trailing. so in YOUR (unlikely but possible) scenario of two and a half hour delay the bootload can fail.

p.s. note that use of the term "ttl" is totally misleading as level has little to do with serial io issues. its POLARITY, not level, which cause many noobs (and apparently some experts) to chase their tail.

Go Up