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 to use a bipolar electrolitic cap (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 positive to GND. 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 TTL to RS232 adaptor Explained – uCHobby 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.
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...
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:
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.
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).
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.
Can a sketch that does not access program memory corrupt the bootloader?
Is there an easy way to add code to a sketch that can check the state of the bootload code?
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?
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.
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:
diecimila.bootloader.unlock_bits=0x3F
diecimila.bootloader.lock_bits=0x0F
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]
I understand and agree about the possibility of not beeing a hardware problem. I just thought hardware was a possibility...
And reading your last message, I think you must try to bootload with board type "NG or older with Atmega168" instead of "Diecimila". I think there are differences on how they handle TX and RX Atmega pins (I think Diecimila bootloader turns on pull up resistors), and other differences too. Can you try to bootload it with "NG or older w/Atmega168" and test it again?
I also thought this is a hardware problem because all the sketches that fail on the serial board consistently upload on the USB board!
The supplier, nkcelectronics is aware of my problem and has not mentioned trying an older bootloader with the serial board. But I will ask them see what they say.
Thanks for the suggestion, I hope that's all that is needed to get the serial boards to work.
Update: I discovered that I can upload even the problem sketches if I do a manual reset. Most sketches will upload without the reset but the ones that were having errors seem to upload ok if I reset a few seconds after starting the upload.
The board does have the 0.1uf capacitor connecting the DTR (RS232 pin 4) to ICSP reset (pin 5) and seems to work intermittently when relying on the auto reset.
I am still looking at why the auto-reset is intermittent and why one of my boards seems much more reliable than the other
try pressing the reset button. Probably the upload will work. It seems your auto reset is not working well.
Open windows;
change COM port speed to 19200;
Run only IDE (close all non used programs);
Bootload using NG or older/168 configuration;
Try to upload sketch.
Adilson, I have been testing with the com port set to 19200 for a few days now. It did not seem to make any difference.
The background CPU activity of the tasks open when I am testing is around 3%. I would be surprised if shutting everying down made a difference but I will try anyway.
I am still waiting to hear from NKCelectronics about the correct bootloader for my board.
Again, many thanks for taking the time post the suggestions.