I have an original Arduino UNO R3 that I bought and an Arduino Severino (S3V3) that I've built.
I have no problems uploading sketches to the UNO, but sometimes, when uploading to the Severino board, I have to hard reset it at a specific time during the upload process, when the IDE says something like this below:
avrdude: Version 5.11, compiled on Sep 2 2011 at 19:38:36
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\arduino-1.0.3\hardware/tools/avr/etc/avrdude.conf"
Using Port : \\.\COM1
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
If I don't reset it when one of the Send
messages are being displayed, I get the not in sync
message, as below:
avrdude: Recv:
avrdude: stk500_getsync(): not in sync: resp=0x00
Other times, if I'm lucky, I can upload to the Severino board without having to reset it.
So, my questions are:
Why does that happen? Why Severino needs a hard reset during upload?
Why is the problem intermitent? Why does it happen sometimes and others it doesn't?
How can I fix that problem? Is there a simple change to the Severino design that would fix that?
1 Answer 1
Why does that happen?
When the serial port is opened by either monitor, avrdude or other it toggles the DTR pin of the serial port. Which in turn is AC coupled through C4 100nF. This toggling is converted to a up and down pulse on the ATmega(CPU)'s RESET pin. The subsequent reset starts initially with the boot loader, which typically in turn waits for a avrdude's semiphore (e.i. Send: 0 [30] [20] ) and if seen then responds in turn and if not seen after a timeout period (typically 5s) it continues on with the application in flash space.
You behavior is describing either; not hearing the response. Or the reset is not getting triggered. Since it does work some times I suspect its prior, but the later.
Why Severino needs a hard reset during upload?
This statement further supports the later.
Why is the problem intermitent?
the pulse is almost long and strong enough, where the DTR toggle is in code and likely has some significant inconsistency.
How can I fix that problem?
Yes, change the value of C4 100nF and or R11 10K, to better pass the toggle. I could derive some EE explanation of what value to pick. But I would suggest some trial and error.
It should also have 5V clamping, as the RS232 levels can reach +/-12V (typically +/-9V) where the AC coupling prevents the DC and burn out. but the AC will stress it.
-
Is there a way to confirm what the problem is with a scope? maybe setting it to a single run during an upload? If so, what signals should I watch?Ricardo– Ricardo2014年02月12日 10:18:01 +00:00Commented Feb 12, 2014 at 10:18
-
1start with scoping the reset pin into the ATmega, and make sure it is below the minimum voltage for longer then the minimum specified time, as per the data sheet.mpflaga– mpflaga2014年02月12日 14:43:28 +00:00Commented Feb 12, 2014 at 14:43