Shop OBEX P1 Docs P2 Docs Learn Events
usb - rs232 long term usage and debugging — Parallax Forums

usb - rs232 long term usage and debugging

Erik FriesenErik Friesen Posts: 1,071
edited 2010-11-06 18:13 in General Discussion
The software I have been working on here is still a work in progress - aercon.net/index.html

This forum seems to have a number of people who have done this type of thing. The target framework for the software is dotnet 2.0.

I have a win 7 64bit computer running the software , and using a Cables to go usb - serial adapter, that has to have the program shut down and restarted periodically, because there seems to be some miscommunication somewhere. The communication does not stop, but seems corrupted. Has anyone run into any issues using the dotnet serial port or usb-serial adapters that are similar to this? The problem shows up 2-3 times a week.

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2010-07-17 17:31
    I would try a different manufacturer's USB to serial adapter (and its driver). It could be a hardware problem in the adapter or a software problem in the driver with extended periods of operation. Theoretically, it could be a problem with DotNet. Changing USB to serial adapters will eliminate several possible issues quickly.
  • Erik FriesenErik Friesen Posts: 1,071
    edited 2010-07-17 18:54
    Actually, I am in the process of testing a different brand as you have mentioned. We are using quite a few of the ftdi within the maxstream radio's and so far they haven't exhibited this problem. I have been using a gigaware converter on my test machine (64 bit win 7) for days without a hitch.

    I have also been puzzling to figure out a way to properly log problems like these on customers machines.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-07-18 09:01
    How annoying.

    Hmm, is it the cable or vb.net?

    One answer might be to log all the bytes with a serial port sniffer. If you go to my webpage www.smarthome.viviti.com/propeller near the bottom just above the last two photos is a link 1) to a serial port sniffer program.

    I could not have built half the propeller things I've build without this.

    At least then you could see if the data is corrupted by the USB to serial device, or whether it is corrupted in .net

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
  • TubularTubular Posts: 4,717
    edited 2010-07-18 20:56
    Eric,

    I've seen something similar after streaming constant data at 115200 bps for several hours into VB. Only worse - I get a blue screen of death (windows XP). I put up with it as it doesn't happen every time. I suspect its due to having too many applications & drivers etc running, but haven't had a chance to try a clean installation.

    All I could suggest is trying a different family of converter IC. There are devices based on FTDI and also devices based on Silabs CP2102 and maybe Prolific PL2303. 4D systems sell TTL converters based on the first two, but you'd still need a MAX3232 or similar if you need true rs232. I have tried a different USB-RS232 dongle with same results, but suspect it just has the same chip inside.
  • Erik FriesenErik Friesen Posts: 1,071
    edited 2010-07-18 21:12
    The cables to go uses the prolific chip. I have found a little information that would suggest the prolific and 64bit haven't always got along the best.

    A lot of the blue screen of deaths that I have heard about are attributed to a defect in the .net framework and the serial port, basically because it keeps trying to read from a port when it gets removed. the "legacy unhandled exception" xml bit takes care of that one, with unknown side effects.(exceptions that should be handled are not?)

    I am not streaming data at it, but I am using it at 115200.

    One thing I have contemplated is to close and reopen the port periodically, or close and dispose the serial port, and start over. A person has to be careful though, or you create a new problem, or don't really figure out the problem in the first place.

    I'd be a little interested to see what type of code and what type of serial port you used to get this to happen (the BSOD)
  • wjsteelewjsteele Posts: 697
    edited 2010-07-19 01:33
    I'd be interested in it too, becuase the .NET Framework is managed code which shouldn't be able to produce a blue screen. Generally Blue Screens result in one of two things, bad hardware/driver or memory corruption. In 7 and Vista, the memory management was significantly better than XP, so you should see a lot less on them than you would on XP, but in either case a blue screen creates a dump file that you can analyze to see exactly where the corruption occured. In fact, on the blue screen itself, you should see the reason code.

    If you can get me either, I can analyze it and tell you what is going wrong. I can tell you that it would never be because your are running too many apps or drivers... you'd get an out of memory or just plain poor performance due to that, but never a blue screen.

    BTW... I work for Microsoft, not in technical support, but I'm a developer and know quite a bit about the framework, etc.

    Bill
  • TubularTubular Posts: 4,717
    edited 2010-07-24 00:09
    Sorry for the delay, just caught up with this thread

    The application I have just spools data from a big file out to the serial port at 115200. But it uses VB98, not .NET, so I realise this is the likely cause. I can dig up the code if anyones interested, but I figure I should porobably try VB .Net first.

    Bill I have another Prop/VB questions you may be well placed to answer, I'll PM you regarding it
  • Erik FriesenErik Friesen Posts: 1,071
    edited 2010-11-06 18:13
    Turns out it was the prolific adapter. Changed to a different brand, and fixed it. I plan to do some extended testing, and maybe send some info to prolific, if I can get around to it.
Sign In or Register to comment.