This is a real head-scratcher. Thanks for any thoughts on this.
I wrote a C# app that merely opens the USB/COM port, sends a character command to the UNO every second, and the UNO then grabs a sample from an analog pin and does a Serial.println() to send the time, value pair via USB to the C# app. And it works great.
However, when I close the C# app, then restart it (which of course re-opens the COM port and re-sends the command every second) the UNO becomes non-responsive. And the way to fix it is to either press the reset button on the Arduino, or cycle the power feeding my Arduino (the USB hub has an on/off switch for each port). Then everything is fine.
I crossed a possible SRAM memory overflow problem off the list, since it's just storing a single time, value pair.
And I close the USB port prior to closing the C# app, for what it's worth.
The only thing I can think of is maybe since the Arduino is in the "void loop()" function waiting for a command, after the app shuts down maybe it can't reconnect or something?
I'd post code but I'm not even sure where to start. I assume it's an Arduino issue, but not sure where to look.
At the end of the day it's no big deal since all I need to remember is to cycle the USB port before using, but I'd still like to figure out what might be the culprit.
I have several ESP32's scattered throughout the property that connect to a MQTT Broker. If I reset the server the broker is on the ESP32's have to be reset to reestablish a connection. I have ESP32's under the house, up in the attic, and out in the yard.
What I did was to send a OK MQTT message with the date time as the payload once a second. On the ESP32's, one of the running task's counts seconds, if the task gets to count X then the ESP32 reboots, which reestablishes the connection. The OK message from the MQTT Broker sets the count to 0.
Thanks. I guess I'm less about finding a solution than I am about understanding the cause. Cuz honestly just pushing a button to cycle power to the Arduino is no big deal. I just can't see why it wouldn't just pick up where it left off and continue sending data when requested.
The token is no longer valid that the ESP32 is using to ID it's self with the MQTT Broker is why the need for a client reset, to get a new valid token. MQTT has a protocol. USB has a protocol.
Thanks, but my challenge is that if my C# app closes, I can't be sending messages to my Arduino, unless maybe I have a second app running whose sole job is to somehow keep contact with the Arduino, every second, 24/7? And I'm not sure your token issue with MQTT correlates to USB, does it?
The PC app "Windows side" is connected to the enumerated device "Arduino"; so, if the PC app goes away, the OS pipes are lost, the port goes stale. Closing and restarting the app should reconnect but sounds to me that the C# disconnect is not properly closing the port - thus reset on the Arduino forces a new enumeration. Kind of Alt-Ctl-Del for the USB.
Like I said, I make sure to close the COM port in my C# app prior to exiting the app, and I even do a C# function that is "while(port.isopen)" and do an endless loop until the port actually closes, then exit the application.
Thanks, but as I said initially, the fix is merely to push the button on my USB hub to cycle power to the Arduino, so rebooting the computer is quite a bit of overkill.
Was not suggesting you reboot the computer ... just showing where even Microsoft does not have a "reasonable" solution. You seek to understand the reason, but with Windows the answer maynot be clearcut.
I think that's a different issue. They were talking about Windows XP Professional and Server 2003, which I don't think even exist anymore. And their primary solution was to do a scan for hardware changes in Device Manager. I tried that and it didn't work. Like I said, when I restart my C# app it successfully opens the port, so I'm guessing it's an Arduino issue, not Windows.
Again, I'm not looking for solutions, just trying to understand the problem. Sure, I suppose I could add some more code to my sketch and when it receives commands from the C# app it resets the timer, and if it fails to get a command it times out and resets the Arduino, but that causes other issues. Like constantly resetting the Arduino when the C# app isn't active. And like I said, it's so much easier just to reach over and press the button on the USB hub, or better yet just keep the hub turned off when I'm not using the Arduino, and start it fresh when I need to use it. And just remember not to restart the C# app without resetting the Arduino.
Anyway, does anyone know what's causing the problem?
Windows has security thingies that try to prevent baddies. Such as opening a USB session with a security token after a device has been determined to be OK, then unplugging the OK USB thingy and then plugging in a not so OK USB thingy blah balh blah..