USB Serial Communications Problem

Projects Programming
1

Arduino Hardware: Ruggeduino SE (directly compatible with Arduino UNO)
Host Hardware: AMD Ryzen 7 1700 / ASRock Taichi
Host OS: Windows 10 Pro

My project is for the Arduino to read serial data sent from a Windows 10 system over serial connection to drive console LEDs indicating system status at a glance.

My project consists of three major parts:

  1. A cmd file running on Windows, in a continuous loop, sending serial data to the Arduino via USB. The data sent is in sets of 6 characters, with about 4 seconds elapsing between sets.
  2. The Arduino running a sketch to receive and interpret this data to operate 10 LEDs
  3. The array of 10 LEDs

After weeks of painstaking work of getting everything running just the way I wanted it, which I did accomplish, it suddenly won't work any more.

What's happening is that the Arduino is now receiving something else over COM3, something that I am NOT sending (i.e., my cmd file is NOT running). When it was running correctly, the "Rx" light on the Arduino blinked every four seconds, consistent with the cmd file's output to COM3.

Now, it is blinking three times quickly, then a slight pause, then a fourth time, then it repeats. This data is coming from something else that I cannot identify. Windows Process Explorer shows NOTHING using COM3.

I've tried uninstalling and reinstalling the Arduino software and drivers. In device manager, I've uninstalled the device with the "Delete the driver software for this device" option checked, but when I plug the USB cable back in, it reloads the same drivers (how can that be if it "deleted the driver software?").

I managed to upload a stub sketch to the Arduino that does nothing (thinking that maybe my sketch had become corrupted), but the behavior remains. What is strange is that the on-board LED (Pin 13) is blinking. The sketch does nothing with Pin 13.

Now I can't upload anything to the Arduino - it errors out with various sync errors or COM3 is not available, etc.

The driver showing in device manager for "Ports (Com & LPT)" is:
Silicon Labs CP210x USB to UART Bridge (COM3)
Driver file details:
C:\Windows\System32\DRIVERS\silabser.sys
C:\Windows\System32\WdfCoinstaller01009.dll

I'm at a complete loss now to understand what is happening. Nothing I do seems to make any difference. I just keep getting this steady stream of mystery serial data.

Do you think that the Arduino has failed? I could haul another system down to my basement computer room and see if I can get it working again with it, but would like to see if I'm missing something obvious first.

I need some help. Thank you!

2

Did you double check the buads? Do they match?

I'd open up the Ruggeduino and see if any of the chips/regulators are fried. Also, can you post a schematic and your Arduino code?

3

Power_Broker,

Thanks.

The issue is that something from the host Windows system is apparently sending a stream of serial data as evidenced by the blinking of the "Rx" light. There is no process that I can identify that is running on the host that would be doing this. I've tried different USB ports and cables.

I replaced my big (and somewhat ugly) sketch on the Arduino with just a stub to eliminate the possibility that my sketch was causing this somehow. So, what the Arduino is running now is just this (called "BareMinimum"):

void setup() {

  • // put your setup code here, to run once:*
    }
    void loop() {
  • // put your main code here, to run repeatedly:*
    }

But still, the "Rx" and pin13 LEDs blink when I connect the USB cable to the host.

There is nothing connected to the Arduino at this point except for the USB cable.

Since there are no serial communication statements in this stub, matching baud rates do not apply.

I examined the Ruggeduino closely with a magnifying glass and I can't see any physical issues.

4

MossyRock:
So, what the Arduino is running now is just this (called "BareMinimum"):

Wow, you came off as quite snarky there. Not sure if that was intentional.

MossyRock:
Since there is no serial communication statements in this stub, matching baud rates do not apply.

But it does for the sketch you will eventually use. I was referring to the fact that you may have accidentally mismatched the baud rates in the original code - causing the underlying problem of your system not working in the first place.

MossyRock:
I examined the Ruggeduino closely with a magnifying glass and I can't see any physical issues.

Ok, good to know.

You still haven't posted a schematic.

To check if your Arduino is busted, I'd load up different basic sketches to test your Arduino. If those test sketches don't run right either, then it's time to buy a new Arduino.

5

While I can't for the life of me see how that statement could be regarded as snarky, rest assured that I had absolutely no intentions of snarkiness, LOL!

Regarding baud rates, they've always been set to default values on both sides, and the original code worked fine until the serial stream began coming from somewhere else.

Do you mean a schematic of the Ruggeduino itself? This link is from their website:

https://static1.squarespace.com/static/529a48e1e4b09eb80191621d/t/529b7dd3e4b0c971f8fa4dcb/1385922003469/am010.pdf

I'll set everything up on another system tomorrow and start from square one to see if the Arduino has failed. I have a feeling that I will find that the problem is with the Windows 10 host.

6

MossyRock:
Do you mean a schematic of the Ruggeduino itself? This link is from their website:

No. I meant the LED, Arduino, and power source schematic

7

You know the COM ports aren't fixed? If something happened with COM3 and then you plugged in the Arduino again, it will create a new COM port number.

Which Tx LED are you looking at? If it's not matching the pattern of data you're sending, then it's not connected to that data. It may be the bootloader looking for an upload pattern.

The schematic required is "how did you hook everything together?"

8

Thank you all for your questions.

MorganS:
You know the COM ports aren't fixed? If something happened with COM3 and then you plugged in the Arduino again, it will create a new COM port number.

Can you elaborate on "it will create a new COM port number"? What will create a new COM port number, the host? In that it will go from COM3 to COM4? Device manager is still showing COM3.

Thinking back more carefully, everything went into a ditch after I moved the USB connector from one USB port to another on the computer and Windows rebooted after a Windows update. I've moved the USB connection countless times with this Arduino and never had an ill effect. It may be just a coincidence, maybe not.

MorganS:
Which Tx LED are you looking at? If it's not matching the pattern of data you're sending, then it's not connected to that data. It may be the bootloader looking for an upload pattern.

It is not the "Tx" LED, it is the "Rx" LED, on the board itself. I'm not sending any data from anything I've written. Can you elaborate on what this means: "the bootloader looking for an upload pattern"? If this has anything to do with the Arduino IDE, it was not up during most of the testing.

MorganS:
The schematic required is "how did you hook everything together?"

Nothing is connected to it at this time, except the USB cable. It is being powered by the USB connection. The Arduino is only running a stub sketch for barebones diagnostics, and is doing no serial reading or writing.

9

Yes, but you had LEDs in a circuit connected to the Arduino when it initially crashed. Please provide the schematic requested.

10

Power_Broker:
Yes, but you had LEDs in a circuit connected to the Arduino when it initially crashed. Please provide the schematic requested.

Ok, I will need to draw it out and scan it. I hope hand-drawn will be ok.

11

Here is the schematic.

I have a pair of screw shields attached to my Ruggeduino so that the wiring is permanently attached.

The schematic makes reference to the terminals on the screw shields.

Note: The Ruggeduino provides on-board, built-in resistance on each pin via 220-ohm resettable PTC fuses. As stated on their website, "you can connect LED’s directly to Ruggeduino digital outputs without any resistors and not worry about destroying them due to excessive current."

That's why there are no resistors in my circuits.

Arduino_Console_LED_Controller.pdf (196 KB)

12

One additional test can be to power the 'Arduino' using a cellphone charger or other external power supply; if it still exhibits the behaviour, it's the board and has nothing to do with the PC

13

@MossyRock, you don't seem to have posted the program that is running on your Arduino. Without that it's hard to know what may be happening.

Have a look at the examples in Serial Input Basics - simple reliable ways to receive data.

...R

14

Thanks for the schematic, everything looks ok.

Did you try running test codes to see if the Arudino is still ok?

15

After working on this all day, I've come to these conclusions:

  1. It works fine on my Windows 7 AMD FX-8350 system. No issues after an initial rocky start as something was hosed in the Ruggeduino, probably from my Windows 10 system. An upload of a sketch cleared the problem.

  2. It doesn't work on my Windows 10 Ryzen 7 1700 system after a reboot of the system - the stream of unknown serial data over COM3 returns and never stops, and I can't access the Ruggeduino.

Both systems are using the same COM drivers as shown in Device Manager.

At this point, I'm going to get an Arduino to replace this Ruggeduino to see if the problem goes away.

Thank you, everybody, for your help on this.

16

MossyRock:
At this point, I'm going to get an Arduino to replace this Ruggeduino to see if the problem goes away.

Don't forget the resistors for the leds in that case :wink:

17

sterretje,

Yes, I have that covered.

Thank you - I appreciate your attention to detail!

18

Hi all. I had this same problem, where something is using COM3 and messing up the execution on the Uno. All i have to do after uploading is to unplug the USB cable, and all is well (sketch runs as expected). However, it's unreliable to get the upload to work. If it succeeds, the program runs after unplugging the cable. Before unplugging, timing is badly messed up, with the Rx LED blinking. BTW, on a different machine (also Windows 10), no problems like this. The board I'm using is an OSEPP Uno R3 Plus.

Update: uninstalling the COM3 driver (USB Serial Port), and then rebooting, fixed this problem. The correct driver was loaded automatically upon reboot. it's working perfectly now.