NEW: Learning electronics? Ask your questions on the new Electronics Questions & Answers site hosted by CircuitLab.
Microcontroller Programming » Serial Data Corruption...
January 03, 2012 by JimFrederickson |
This is not a 'huge problem', but it is a 'huge annoyance'. After all I wouldn't want to show someone the Project and have them see the Corruption only for me to say, 'Yeah, that happens'... It is something that I would like to get remedied. For my mind I am down to 4 things left to try that could be the problem. I would be grateful for any input regarding whether there are other or better things to try. I have a Project Running. One of the things that the project does is output data VIA the Serial Port. From time-to-time there is 'data corruption' on the Serial Output Data Stream. The corruption can be a couple of characters, or it can be dozens of characters. I am using the Nerdkits Prolific USB-Serial 5v Adapter... The project is running on a board I soldered together. I have an AC-DC Adapter that outputs 12v. (I am not close to maxing it's output. I have a 100uc Capacitor on the power bus. 1 - I initially thought that maybe it was a bad solder joint.
I don't think this anymore because I resoldered those joints
and I have NOT had any issues with anything else attached to the
Micrcontroller. (Since the other things connected have MANY 2 - Serial Terminal Emulation was 'Tera Term', now it's PuTTY.
(I think it was 'Tera Term'.)
At first when I used 'Tera Term' got 'confused' every so often.
3 - Is it 'Baud Rate'? When I was 'testing'
4 - I thought maybe a bad serial ground.
I was 'grounding the Prolific USB-Serial Adapter to the 14v DC
Input. After thinking about it, I thought maybe I should
ground it on the board I have so I did that.
Now to the 4 possibilities... 1 - Maybe the 12v DC in is not constant. I thought about setting up another Microcontroller to monitor that, but I haven't done that yet. (I seemed to have misplaced my old 'TOIT'...)
2 - I am using an even 16mhz Crystal. So things aren't dividing evenly. Could that account for it?
3 - I don't have any capacitors on the crystal? 4 - What about pull-downs on the Serial Txd from the Microcontroller? P.S. I have NO IDEA why 1 and 2 didn't indent right... I thought the 'tab trick' was guaranteed... Are there more things, or better things, to try? |
---|---|
January 03, 2012 by pcbolt |
Hi Jim - I read somewhere the reason the 14.7456 Mhz crystal is used is due to the fact that all baud rates are even divisors of that rate. Doing the math that seems right. I would try that option before any others. |
January 04, 2012 by Rick_S |
The replacement of the crystal could definately be your issue. Your margin of error is zero with the 14.7456MHz crystal just as pcbolt stated. Because it is evenly divisable by standard baud rates. 16MHz is not and as a result you will see errors. These may be more obvious on different hardware and at different baud rates. With a 16MHz crystal, your error is anywhere from about -3.5% to 2.1% depending on baud at baud rates of 2400 to 115200bps. With the 14.7456MHz crystal the error is zero. If you need additional speed, your best bet would be to go to an 18.432MHz crystal, it is the next fastest with a zero margin of error with standard baud rates. If you want to see the error charts, they are in the datasheets (Table 19-12 on the revision of the sheet I have) If you are programming the part the standard NK way, are you swapping crystals after program transfer? If not, I'm surprised your program would even make it over to the chip. Rick |
January 04, 2012 by hevans (NerdKits Staff) |
Hi pcbolt, If you are using a 16Mhz crystal I am quite surprised you are getting any data at all across the serial port. Timings on the serial protocol are pretty sensitive. Humberto |
January 04, 2012 by pcbolt |
Hi Humberto, I think you wanted to respond to Jim. I haven't advanced yet to building my own PCB's...yet. |
January 04, 2012 by hevans (NerdKits Staff) |
Ooops, sorry pcbolt. I meant to give you credit for mentioning a good idea =). Humberto |
January 04, 2012 by pcbolt |
Actually Humberto I think I read about that idea from a post either you or Mike put up some time ago. |
January 04, 2012 by JimFrederickson |
Hello Everyone... I really can't take credit for the Circuit Board. (I did solder it, and some of the circuit is custom.) I purchased the board, and it had a 'breadboard portion' that I have used as well. I do, however; plan to get some boards made once I get a better idea of what I would like. I am not loading the program VIA the 'Standard Nerdkits Way'. I am using an Atmel AVRISP MK-II Programmer. The Crystal doesn't seem to have an impact on this problem. I put the original Nerd Kits Crystal back in and the problem does still exist. (I am only using the Baudrates of 9600, 19200, 38400, 57600. Mostly I stick with 38400 or 19200. But I have tested all of the ones I have listed, and the problem is mostly the same.) I had looked at the Tables for the UART UBRRn Settings for Commonly Used Oscillator Frequencies. I do think there is some sort of 'interference in the signal though'. One thing I was able to do, is I put in a 'gap between each character sent on the Serial Interface'. With the 'gap there' the error rate goes down dramatically. Now I know that the 'bit rate within the transmitted frame' is pretty much 'accurate' because the Microcontroller Generates that. (If it doesn't divide evenly that doesn't really affect the 'bit rate' it only 'affects how well the bit rate matches with perfection for a given Baudrate'.) I am pretty sure that the Prolific USB-Serial Interface 'uses the baudrate settings' as what is 'expected' but then 'oversamples the incoming bits' which would probably take care of any minor deviations. (The AVR Microcontroller itslef has built in 2x Serial bit oversampling.) I did put in a BIG CAPACITOR on the incoming 12vdc prior to the 5vdc regulator on my circuit board... The BIG CAPACITOR is large enough to run the board for a good 10seconds without power. I think that effectively puts to rest the idea that it may be a 12vdc power problem from the AC/DC Adapter. One additional thing came to mind earlier today? The AVR Microcontroller has an 'aggregate limit' on how much power it can source. (Is that right? Or is it sink? I think it's source in this context. In any case...) I am going to alter my code to shutdown all non-necessary pins during the Serial Communications and see if that has any affect. (By 'non-necessary' I mean 'pings not necessary/required for serial communications'...) |
January 05, 2012 by Rick_S |
Does your F_CPU define, UBBR Value, and Crystal speed all match? I've sent data at 115200bps and not noticed any garbage data. Have you tried a different serial adapter - maybe one based on the FTDI chipset? Does your PC have a hardware serial port you could test with - you can add a small circuit to communicate with a "real" RS232 port. Do you have a different PC you could test it on? |
January 11, 2012 by JimFrederickson |
Rick, Are there any other 5v Serial Interfaces that you have used that work? the only one(s) that I have are the Prolific USB-to-Serial Interfaces. |
January 11, 2012 by Rick_S |
I've used the ones listed in my prior post as well as a max232 to a true pc serial port. |
January 11, 2012 by JimFrederickson |
I am intending this to be the "closing post for me on this thread"... I have come to the conclusion that the 5v Serial Interface on the Microcontroller is NOT the problem. The 5v Serial Interface on the Microcontroller is "rock solid" as it is configured for my circuit. I was only, initially, pursuing the Micrcontroller angle since "I made it and programmed it". So my initial thoughts were, "that the Microcntroller was the most likely source of the problem(s)". That was why I focused on that angle to begin with. Since the first post, and hundreds of megabytes of transfers, I have found out all that I think I need to find out on this. What did I find out? These things have, or can, affect Serial Error Rates for me on Windows x64... 1 - Serial PC-Microcontroller Ground is very important for stable Serial Transfers. (I knew this, and that wasn't my problem, but I thought I would throw it in...) 2 - Plugging the Computer and the Microcontroller into "different AC Sources" can be a problem. (Well not really "different AC Sources", but I couldn't think of a better way to phrase it. I have had some problem(s) if the Computer was plugged into a UPS and/or Surge Protector when the Microcontroller power supply was plugged directly to the AC Outlet.) 3 - In Windows 7 x64 under the 'Advanced Power Management' there is a USB Option for 'USB Selective Suspend Setting'. This setting hould be "disabled". 4 - For me on the laptop there is a difference between the USB v1.0 and the USB v2.0 Ports. USB v2.0 works much better 'over a period of time', but it has 'streaks of errors that are longer than the USB v1.0 ports'. 5 - I have 3 Powered USB Hubs. ALL of them either increase the error rate or essentially make the Prolific USB-to-Serial Adapter unusable. 6 - Rebooting the laptop with the Prolific USB-to-Serial Adapter plugged into the laptop as well as the Microcontroller helps significantly in reducing the error rates. (On my 2 desktops it makes no noticeable repeatable difference.) 7 - Adding an 'inter-character gap' in my Serial Data helped considerably on the laptop. It helped a little on the desktop. (There was not very much change in the error rates based on Baud Rates I have been using.) My Final Worst Case Error Rate Averages are: __ "Errors/1000 ASCII Characters" "Errors/1000 ASCII Lines" ___ (NOTE: For these purposes ASCII Lines are about 20 bytes line each.) Laptop USB v1.0 __"43"__"14" Laptop USB v2.0 __"<1"__"7" Desktop(s) USB v2.0 ___"<1" "5"___ P.S.
All of my timing values in the Code are set appropriately. There was no noticeable difference in errors rates for me between the "standard Nerd Kits Supplied Crystal vs my 16mhz Crystal". (Of course the 'timing values had to be changed appropriately for both' to function at all.) I am pretty confident now that the issue(s) are on the PC side of things somewhere.
Exactly where? I am not sure exactly where the problem(s) are, and since I am pretty satisfied with the current errors rates for now I don't see any need in delving further into this for me. (I would PREFER 0 error rate, but what I have is usable for now.) I have used 3 different Terminal Programs. Eventually I switched to a Java Program using the RxTx Library and ".dll's" that I created. (Mainly for learning and flexibility reasons...) All of the Terminal Programs I used seemed to be about the same, as far as error rates go, except for Tera-Term. That didn't work well for me at all. |
January 15, 2012 by BobaMosfet |
Using the 'AVRISP MK-II Programmer' you can talk with the ATMEGA168 via it's ISP pinout, and you should have error-free communication up to 2Mbps, under Windows 7, 64-Bit, using WinAVR. I've also used it (same rate) under 32-bit Windows XP. If you are having a communication problem, I strongly recommend (because this is a known issue) that there is a driver conflict, or corruption. BM |
Please log in to post a reply.
Did you know that our kits have shipped to hobbyists in 40 countries? Learn more...
|