Go Down

Topic: Problem with Freeduino Serial v2.0 board (Read 11782 times) previous topic - next topic


Feb 23, 2008, 11:02 am Last Edit: Feb 23, 2008, 11:04 am by mem Reason: 1
I am having intermittent problems uploading sketches to my Freeduino Serial board and was intending to build up a spare board when I came across an issue with the RS232 interface and wondered if anyone could shed some light on this.

There is a capacitor C8 which looks like it provides the negative voltage for driving the RS232 line and the correct orientation of this is not clear. It's discussed in this thread http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1177923417

But I have not seen any corrections to any of the published circuit diagrams to confirm if the positive or negative side should be grounded. There is an online circuit diagram from my supplier, nkcelectronics, here: http://mcukits.com/

I would appreciate some informed advice on the orientation for C8 before making up the new board.



your link to mcukits was not working for me now (server probably down) and I don't know the freeduino serial circuit (I think it is similar to serial double sided Arduino); but like I said and explained on http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1177923417, in Arduino Serial, the safe option is [glow]to use a bipolar electrolitic cap[/glow] (a cap without polarity). This would be necessary because the serial circuit is always connected to ATMEGA TX and RX.
But if you don't have a bipolar cap, use the polarized one with [glow]positive to GND[/glow]. The occasional inverted voltage (almost -1.4v.) will be less destructive than negative to GND (almost -11v.).

What problems do you have while uploading sketches to your freeduino?


The problem is that I can't reliably upload sketches. It's a little intermittent although short sketches (around 2k) usually work and longer sketches of around 10k usually don't.

I get the avrdude protocol error, expect=0x14, resp-0x51

Once an upload errors, even small sketches then fail to upload , and a new bootloader must be burned to cure the problem.

The problem occurs on two PCs tried, both running Windows XP sp2  connected using either a standard hardware serial port or  USB to serial converter cable.

Both machines upload to a USB freeduino perfectly!

I can wire in a couple of 10uf caps back to back in series to make an NPO but I have seen nothing about the cap being a problem from anywhere other than the that thread. All the diagrams I have seen show the cap connected with the negative to ground.

I should probably just try two caps as an NPO if only to see if that cures my issue.


The freeduino link worked now, and I can see the serial schematics and a pic of the kit. It is simlar to Arduino (in fact, almost the same). R2 value (330 ohms) seems to low, that makes power led too bright and with high current comsumption, but this doesn't affect to upload sketches.

I can see the auto reset feature too. I had problems here with auto reset in Preliminary Arduino S3v3 version, WinXP sp2, and standard PC serial cable (with pins 2, 3,4 and 5 connected), but the problem was the computer COM port speed. It was configured to 9600bps (default), causing a similar error while uploading sketches. Sometimes it works, sometimes don't. Then I changed the COM port speed to 19200bps, and it worked fine, always. I saw you said you used serial and USB, and you had problems with both, but can you check the COM port speed, just to be sure?

I'm sure the capacitor will work always, no matter if positive to GND or negative to GND. This is not causing your problem. The cap position/polarity will only damage it, but this can take a long time using it. Much longer if you use positive to GND.
There are many examples showing cap negative to GND (not correct), and I found one with positive to GND http://www.sparkfun.com/datasheets/Prototyping/RS232-Shifter-v2.pdf. The original page http://www.uchobby.com/index.php/2007/06/11/ttl-to-rs232-adaptor-explained/ explains it.
This applies to dettachable serial to TTL converters.

But Arduino (and your Freeduino) has this converter connected even when not used to Serial to TTL communications. When you don't use it, this circuit can be affected by pin1 as output (if used), causing inverted voltage on cap. Because of this I suggested to use non polarized cap. But if you need to use a polarized, again, use it with positive to GND.


Feb 23, 2008, 11:25 pm Last Edit: Feb 23, 2008, 11:26 pm by adilson Reason: 1
I forgot to say:
my computer is a bit slow, and if I run more software while running Arduino IDE, I got error messages when uploading sketches too.
So, check COM port speed, and try to run only IDE. And check if firewall is not causing the problem too. I've heard something like this in some thread...


Feb 23, 2008, 11:29 pm Last Edit: Feb 23, 2008, 11:30 pm by mem Reason: 1
Thanks Adilson, that info is much appreciated.

I think I will have a look at the waveform on the RS232  Tx line with my scope just to see what it looks like, perhaps there is something else affecting the serial data.

I will also try it with the com port set to 19200.

I don't think its the firewall because it sometimes works.


The amount of time I have spent trying to get my Arduino hardware to upload reliably is getting out of control.  I am approaching the point where this is just more trouble then its worth and I would appreciate some expert help.

The problem is intermittent. The symptoms are a failure to upload with the following being a typical avrdude error message:

Using Port            : \\.\COM1
        Using Programmer      : stk500v1
        Overriding Baud Rate  : 19200
avrdude: ser_open(): setting dtr
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv:
avrdude: stk500_getsync(): not in sync: resp=0xc8
avrdude: Send: Q [51]   [20]
avrdude: Recv:
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0xc8

avrdude done.  Thank you.

Once I get a failure then all subsequent upload attempts fail until I burn a new bootloader.
The problem occurs with either of two PCs running XP SP2 and both machines upload to a USB Arduino without problem.

I have tested the Tx circuit on the board and am getting a swing of just over plus/minus 5 volts on the RS232 Tx pin and can reliable receive test data from the Arduino on the PC. But if I try to repeat an upload of the same test sketch I am more than likely to get the avrdude error the second time.

I have double checked the construction of the board and am pretty certain its not a bad solder joint (that was my first thought) or a misplaced component.

I think I have exhausted all the usual trial end error things one does to troubleshoot an enigmatic  problem, so any help in understanding what is actually happening in the bootload process and why it seems the bootloader itself gets corrupted would be a great help.

Suggestions for an arduino code that simulates similar traffic to an upload would also be appreciated.


Did you try changing COM port speed to 19200?

When you run IDE with run.bat, right after this message (in run.bat DOS window):

Using Port            : \\.\COM1
       Using Programmer      : stk500v1
       Overriding Baud Rate  : 19200
avrdude: ser_open(): setting dtr
avrdude: Send: 0 [30]   [20]

try pressing the reset button. Probably the upload will work. It seems your auto reset is not working well.

I forgot to ask you: are you using Arduino IDE to upload sketches? and for bootload? To bootload a serial board with IDE 0010 delays 10 minutes (because of -i command).


Feb 26, 2008, 03:27 pm Last Edit: Feb 26, 2008, 03:28 pm by mem Reason: 1
Thanks for the comments

Yes I tried with the PC com port set to 19200 with similar results. I also tried it with the upload speed set to 9600 again with similar results.

Manual reset also does not seem to solve the problem, although I have tried it from the IDE, not using run.bat.

I use the IDE to upload but if there is a more reliable method I would be glad to hear of it.

A parallel port programer is used to burn bootloaders and this works flawlessly from the IDE.


Well, the only thing I can think now is to exchange the Atmega IC with the one in your USB board, to be sure that the problem is the board, the IC, or only not the IC.



Its not the ATmega IC.  After swapping ICs,  the USB board still works great, the Serial board still has flaky downloads.

Any info on debugging how the bootloader handles uploads would be much appreciated.
Does anyone have any experience with what looks like a very simple serial monitor program in the bootloader?


I have now tried a second Freeduino serial board and this has the same  'Problem uploading to board'. I have tried using non-polarised caps and swapping ATmega ICs and this makes no difference.

The problem is dependant on code uploaded.  Simple sketches upload fine, bigger sketches may or may not. And although the problem seems to be dependent on something about the sketch, my trial and error on different kinds of sketches is inclusive;  each test is very time consuming because I have to burn a new bootloader after each failure.

And this is the reason for this post. It is very frustrating finding the problem without any insight on why the upload fails. The symptoms are describe above and although I can guess that something is happening to the bootloader code so it no longer responds to the avrdude's stk500v1 protocol, I have no idea why or how to check what is going wrong.

Any help from those knowledgeable on this area on any of the following questions would be appreciated.

1. Can a sketch that does not access program memory corrupt the bootloader?

2. Is there an easy way to add code to a sketch that can check the state of the bootload code?

3. What are some possible explanations for why this problem occurs with a sketch on either of two serial boards  but not on a USB board even though  the environment the and test sketches are the same?


How are you burning the bootloader?  Are you sure you're setting the lock bits to protect the bootloader after burning it?


Thinking better, it is possible that the serial circuit of freeduino is causing the problem.
The electrolitic cap is there to be charged with negative voltage through serial pin3 (serial RX), and then supply this negative voltage to pin2 (TX) when needed.

You said you're sure this problem occurs only with larger sketches. So I'm thinking: the cap works like described above, but if TX and RX information delays (because of big sketch), the cap (with negative voltage) discharges faster than its negative charge, that makes serial circuit unable to send negative voltage at pin2 (TX), causing an error in communications.
This could explain the error.

But if this is true, I don't know if this error can corrupt the bootload.

I don't have an Atmega168 to test your sketch here.

I suggest you try a bigger electrolitic cap (perhaps 47uF or 100uF, instead of 10uF - if you don't have a bipolar, use positive to GND). Or solder other(s) in parallel, to increase capacitance. And perhaps (if cap solution doesn't work) a bigger resistor too (that one between cap and transistor, 4k7). You can use 10k.


Mar 03, 2008, 05:15 am Last Edit: Mar 03, 2008, 05:20 am by mem Reason: 1
David, I use the burn bootloader parallel port ISP option from the version 010 IDE. The board is set to Diecimila and as far as I know, everything in boards.txt has the default value. The lock bit settings are:

Is there any code I can add to a test sketch that can check if the lock bits are set correctly? Indeed, any code that would help to determine if the bootloader was healthy or otherwise would help me track down this problem

Adilson. In my recent testing I have noticed that sketch length alone is not the trigger for the problem. Failures usually occur on bigger sketches but some big sketches always seem to load reliably. I am now thinking that the problem may have something to do with the actual sketch code. But because the problem is intermittent and I still don't know why or how the bootloader is failing I am not really clear on if it's a hardware or software problem (or both).

My uncertainty is heightened because one of my two serial boards is much more robust than the other, but sending seems reliable on both boards when the sketch is running. Its only in the upload process that a problem occurs. And the problem is always in the initial handshake waiting for a response to:  Send: 0 [30]   [20]

Go Up