I'm using a Elegoo Mega 2560 with a Dell E5450 laptop as the host PC (windows 7 OS). If I put the laptop to sleep while the Mega is attached, the laptop does not go into sleep mode properly. After a hard shut down (power button for 5 seconds) and reboot, Windows puts up a special screen explaining that it was not shut down properly and can be rebooted. The driver associated with the Mega is the Arduino-supplied V 1.2.3.0, dated 2015, "usbser.sys". This problem happens both with the board powered from the USB line and also when powered from the board connector. I think the problem doesn't care what sketch is loaded (I need to double check that claim). I've searched the forum and Google without success.
I have a different instrument based on a different Arduino architecture, and it does not suffer this problem, but the driver associated with it is the FTDI VCP driver. The Mega does not use the FTDI chip; so I assume I can't just re-associate the mega to the FTDI driver...
So... what's the trick to being able to let the host PC go to sleep without crashing?
Thanks.
Update:
I've confirmed that the problem happens regardless of what sketch was uploaded and running when the laptop goes to sleep.
Also, the same crash happens if the laptop is set to hibernate. (A full shutdown works just fine.)
I have a genuine Arduino Micro board on hand, and that board also exhibits the same crash behavior when the laptop goes to sleep. The driver for that board is also the Arduino-supplied V 1.2.3.0, dated 2015, "usbser.sys".
Some laptops turn off the USB and it's 5 volts when going to sleep. Is this what you are experiencing? Also happens on some when the screen saver takes over.
Nope. It happens just the same when the boards are running on the USB power or when they are powered by the power jack. It's the laptop that fails to go into sleep properly. As far as I can see, the board continues to run OK. That makes me think there is something about the driver that should be letting the laptop know something, and that is not happening.... The one Arduino device I have that runs on the FTDI driver does not crash the laptop. Both devices using the V1.2.3.0 driver hang the laptop when it tries to go to sleep.
Are your drivers up to date?
They are as set up by Windows during Arduino install: V 1.2.3.0 dated 2015, "usbser.sys". Is there a newer version? Every time I have asked Windows to look for a newer version it says this is the latest.
The sleep/hibernate methodology has evolved with Windows and with Windows drivers; old drivers may not follow the current Microsoft spec.
ahem... (as mentioned in the first post) the laptop fails to enter sleep even if the board is powered by the power connector instead of the USB line. The board continues to function fine; it's the laptop that crashes. That will be unacceptable when the host computer is running a lot of other laboratory equipment which all functions fine if the host computer goes to sleep, but cannot function if the host has to be rebooted after failing to enter sleep properly..
Is there a newer driver? Where would I find it? Driver Properties is showing me that the board is associated with driver version 1.2.3.0 dated 2015.
That did not miss my attention. Driver software can easily cause the OS to crash... one of the reasons that drivers are generally digitally signed and certified independently.
USB device class drivers included in Windows - Windows drivers | Microsoft Docs
You could (perhaps) use a quality USB-serial adapter:
Guide to Selecting a USB to Serial Adapter (usbgear.com)
I have no idea what serial "chip" the Elegoo clone uses.
Be sure your Dell E5450 is fully patched and also the OS.
Ah HA! You got me. I thought the Mega board was native in that it does not use an external USB to serial chip to feed the mega 2560. My bad. There is an Atmel mega 16U2 serial chip sitting there. So I will work on the assumption that it needs a different driver. However, the problem now branches: I had tested the genuine Arduino "Micro" board which has no external serial chip, and gotten the same bad behavior from the same V1.2.3.0 2015 "usbser.sys" driver. So what driver should that board be using? Can anyone provide a link/pointer to the proper drivers for these two boards (Mega 2560 and Micro)?
Related, how do I re-associate a new driver to the boards? I tried uninstalling the present driver. That greyed-out the option to update that driver, and Windows then automatically puts the same driver back in without letting me choose a new version. When I try just updating the driver and pointing to a folder with a different driver version, Windows tells me the current driver is the latest.
Being that you are running a long outdated OS, you may not find a suitable solution.
You may find also find that the most current drivers are actually causing you issues.
I cannot say for certain in this case, but I have seen it happen many times over the years.
I have a Windows 10 version of the same laptop, and the same driver is associated with both boards on that machine also. (I have not tried putting that one to sleep yet; it has a bunch of other open stuff running on it that I would rather not disturb, but I may have to bite the bullet there.) I have assumed that it would behave no better given that it is the same driver.
So any pointers to drivers that actually work for these boards?
(It could also be a Dell thing. I have had trouble with STMicro CPU's resetting periodically, and the conclusion was that the reset was due to some (unspecified) thing Dell was doing to the USB port.)
I have an Arduino Uno-based instrument that behaves just fine on the WIn-7 machine. It uses an FTDI driver. Again though, I have not been able to re-associate drivers to these Mega and Micro boards. I would like to try and associate the the FTDI driver to them. Anyone know how I over ride the existing association?
Well, you haven't yet tested the drivers on a currently supported OS.
Save your files and test it on the Windows 10 machine before you knock the drivers.
But that may not be worth it either as the laptop that you mentioned was EOL with Windows 8. So, the current drivers with Windows 10, on that laptop may still have issues that have nothing to do with Arduino or the associated drivers.
Well, OK then. I assumed wrong again.
Mega 2560 on Dell E5450 running Windows 10 works with Arduino as-installed driver V 1.2.3.0 "usbser.sys" dated 2015. The laptop can be put to sleep while attached to USB. Same Mega 2560 board on the Windows 7 version of the E5450 laptop using the same driver cannot be successfully put to sleep and recover.
Arduino genuine Micro board also allowed Windows 10 version of E5450 to go to sleep and recover without failure. (not sure why, but on the first attempt, I got a blue screen a minute after I plugged the Micro into the USB. After recovering from that restart, things appear to be stable.)
On the Windows 7 version of the E5450 laptop: I have not found a solution yet that allows the laptop to be put to sleep successfully, but I have not exhausted the search yet either.
The trick to re-associating drivers to the boards is to use the "Update Driver" button, select "Browse my Computer for Driver" option in the first dialog, then select the "Let me pick from a list of device drivers on my computer", and then use the "Have Disk" button to navigate to the driver folder you want to force Windows to use. This way you can force Windows to use something it thinks might not be right or might be outdated.
What I do not know is if the Elegoo 16U2 uses the official Arduino firmware ... it could be modified and still use the official driver. The Windows 7 Plug'n'Play system would load the driver matching the inf file.
Drivers for Windows have evolved over the past decade. PC hardware has also gotten better with PnP driver associations.
IMO, just disable sleep and hibernate; these battery saving tools have no place with critical logging software running.
Ray
(The workaround I am exploring for Windows 7 machines is to use the Arduino as-installed driver V 1.2.3.0 "usbser.sys" dated 2015 to do the programming development, and once uploaded with a stable version of the code, then switch the driver to some less-capable driver version that will still manage the proper serial comms, but will not be able to talk to the programmer.) This approach is moot for me at this point because my laboratory work will be on Windows 10 machines, but the workaround might still be useful for others.
IMO, not a good approach; I go as far as stating it is an awful approach as you are adding another layer of potential problems to the driver+OS stack.
Ray
Fair enough. The lab machines are all rack machines anyway and don't really need to sleep or hibernate. Disabling sleep would be Ok until some dummy (i.e. me) forgets and does it manually.
Some Dell BIOS settings permit disabling sleep under Power Management.
Thank you all for guiding me this far. Being able to develop on the Windows 7 platform without sleep, and deploying to the windows 10 platform knowing that sleep, if executed, won't crash my systems gets me far enough along that I will divert to other problems.
I will update if I find anything more useful for Windows 7 platforms....
.-.-.