You are not logged in.
Looks like i found how to make it work - See Below. Not looking for any further troubleshooting
I am leaving the post as is for reference
I am building an external circuit which connects to the PC with USB. This circuit, among other stuff, got to wake up the PC from sleep when an external signal is received
The sleep state wanted at the PC is the least deep sleep state possible, where the fan can go off and no appreciable heat is generated, and will take the shortest time to resume. The purpose is to cut down the main bulk of power consumption in an AC powered application. There is no need in any deeper sleep states, or in saving additional tiny amounts of power by more advanced actions
In any case, right now i have on a breadboard a Microchip MCP2221A connected to the PC. The MCP2221A supports the following :
1.6.2.4 Remote Wake-up Capability
The MCP2221A offers a mechanism for triggering a remote wake-up event for the USB host. The remote wake-up trigger works only with the external interrupt detector. In order to use this capability, GP1 must be designated for interrupt detection operation. Before the USB host goes into Sleep/Standby mode, the interrupt detector must be set up for detecting positive edges, negative edges or both; also, the detector flag must be cleared. After these conditions are met, the USB host can go into Sleep/Standby mode and it will be awakened whenever an external signal on GP1 triggers the interrupt detector.
Datasheet of MCP2221A :
https://ww1.microchip.com/downloads/aem … 05565E.pdf
I have configured the PC (Arch, KDE) to sleep in 1 minute, and am poking the signal on the breadboard to generate the wake up event
The problem :
If i generate the signal within the first few seconds from the PC fan stopping, the PC indeed wakes up as expected
If i generate the signal later, the PC won't wake up anymore
- The USB is still powered
- The PC does wake up when i press a key on the keyboard (USB keyboard or laptop keyboard) anytime
Tested on 2 PCs (one is a laptop) with same results
Tested with 2 MCP2221A chips, with the wakeup function disabled in the 2nd one. (This is to verify that the wakeup that works, within the 1st few seconds, is indeed generated by the wakeup feature of the chip and not just by "any" USB traffic). Indeed, only when the function is enabled in the chip, the wakeup will work at all
(i use EasyMCP2221 to edit/flash the settings of the chip)
I tried to edit /etc/systemd/sleep.conf :
Initially (as came with the system) it was all commented out
Currently it is :
[Sleep]
AllowSuspend=yes
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no
SuspendState=mem
This have not changed anything
Nothing interesting in BIOS setup in any of the PCs. (Wake on USB is enabled, but there is nothing else that seems related)
What does happen with the system in the next few seconds after the fan off, and how to make it stay in a state where it will accept the wakeup signal ?
________________
After some more tinkering i figured that the problem only happens when the MCP2221A is configured to wakeup on the falling edge of the external signal (Which is how i set it up initially)
Setting it to wakeup on the rising edge seems to work every time, even several minutes after the PC entered sleep
But why the difference ?
The GP1 pin of MCP2221A is next to the Reset pin (Reset is active low). The pulse i put on GP1 might have capacitively coupled to the Reset pin (which i left floating - it does have an internal pull up in the chip), so when the falling edge arrives, the chip might have been resetting before it had a chance to transmit any data to the PC. The large metal clips inside the breadboard might be adding to the capacitance
Putting a fairly low resistor between VDD and Reset have not solved the problem for falling edge. So it might not be the capacitance after all
And neither of this explains why it does work in the first few seconds....
In any case, changing to positive edge works for me - I am not looking further for now
Last edited by TwilightAsh (2025-05-18 19:32:30)
Offline