retrolefty:
Well the Uno in rev2 and the present rev3 did add a 1K ohm pull-down resistor on the DTR output pin from the 16U2 chip that the older arduino 2009 board did not use on the FTDI DTR output. I wonder if that pull-down resistor keeps the 328p reset pin low long enough after initial power-up to cause a true pin1 external reset condition and thus activation the bootloader wait period to be active?Lefty
Interesting. That's a pretty hefty pull down.
From m328 spec:
tRST is 2.5us
So if the combination of the pull-down, 100nf auto-reset cap, and 10k pullup
does hold it down for 2.5us before the the 16U2 can turn its
output to high after power up, then an external reset will occur.
HardwareSetup() is called first thing in main() but 2.5us is only 40 instructions at 16Mhz
and a lot of stuff gets done (way more than 40 instructions)
before the pin driving the AVR reset line is initialized.
Plus the 100nf cap has to charge up using the 10k resistor to VCC.
If my math is correct using an RC network of 10k with a .1uf and voltage rising to 4.5 volts
(MAX/worst-case of .9Vcc for reset threshold voltage) That means the RC network
can hold reset down for 2.3ms (milliseconds not microseconds).
Did I get that right?
If so, an extern reset on powerup seems inevitable.
I wonder if these R3 boards ever see a powerup reset?
It would be interesting to see a scope picture of the AVR RESET pin during power.
That auto reset circuitry on the Rev3 board seems like a mess.
Given there is total control over the 16u output line controlling the RESET on the AVR,
I would switch it over to using CTS instead of DTR (1 line change to the 16u2 firmware)
to avoid the need to create an output pulse based on a single transition of a DTR, which creates
so many issues. Avrdude and IDE now already create the needed pulse by driving CTS low then high again.
Then I'd use a single pullup on the AVR reset line and use protection diodes on the 16U2
and RESET header pin inputs.
--- bill