Go Down

Topic: Restore Feather M0 USB Serial after sleep (Read 2989 times) previous topic - next topic



This is a recurring discussion topic, but despite reading everything I have found here and elsewhere I cannot find a working solution.

I am using a Feather M0 datalogger board. To save power between readings I want to put the board to deep sleep and wake it on interrupt. My problem is that after waking the board, I cannot restore the (USB) Serial connection to see Serial.print() debugging messages.

Most of the solutions I've seen are from 2015. Is it possible that newer releases have invalidated those solutions? I am using the most recent software - Arduino IDE 1.8.1, Arduino SAMD 1.6.12, Adafruit SAMD 1.0.13.

Here is some annotated code, based on SimpleSleepUSB.ino from the Feather-M0-Adalogger-master library at https://github.com/cavemoa/Feather-M0-Adalogger. I have tried the combinations indicated, and many others based on other online sources, without success. The LEDs do flash to indicate that the board has returned from sleep, but the final Serial.println() never appears.

Code: [Select]

void loop()
  Serial.end();                        // some sketches include this
  USBDevice.detach();            // some sketches include this

  delay(500);                         // wait for detachment (?)
  rtc.standbyMode();              // .. or similar method of putting to sleep

  // Flash LED to indicate board is now awake - this works
  digitalWrite(13, HIGH);   
  digitalWrite(13, LOW);   
  digitalWrite(13, HIGH);   
  digitalWrite(13, LOW);   

  USBDevice.attach();            // if USBDevice.detach used above
  delay(1000);                       // make serial more reliable (?)
  Serial.begin(9600);              // included if Serial.end() used above

  while (! Serial);                   // wait until Serial is ready
  Serial.println("Awake");       //  .. I've never seen this

Any help gratefully received.


HUm, USB stack is a bit tricky to deal with. I have the same issue in a different setup, but still haven't found a workaround...
Try  USBDevice.init(); before the attach function maybe.


Thanks AloyseTech, but no cigar. No change in outcome.


doctor-sparks, did you ever find a solution to this? Dealing with the same problem...thanks!


Hello!!!, Any solution of this issued?? I have confronted the same problem for a week now.

NVIC_SystemReset();    won't resume USB too after sleep. or need to connect the hardware to this pin to force reset


I know this is really old, but what worked for me was just calling USBDevice.standby() and NOT calling USBDevice.detach(), or USBDevice.attach() on wake up.

I just figured I'd share in case someone else lands here in their search.

It seems like the attach() and detach() methods might be only for when using USB as host? I dunno..


New to this setup (but doing computers since the late '60s) and have been fighting this and similar issues with the M0 core.

It appears NOT to be the uP as much as it is an interaction with the USB stack at the host machine.  Ports that come and go do funny things, different funny things depending on the opsys (I use linux..) - when the Arduino IDE is involved, even the JRE chosen matters as to what will happen if a USB port device comes and goes again - my experience so far is that whatever talks to USB drivers in the JRE is the worst actor.
For example, on linux, something like GTKterm has pretty much no issues.
Everything has issues when a burn/reboot happens, the PC USB stack loses it's mind in some way it seems, even when /dev/serial/by-id still shows the same interface; the linux way is far superior to COM ports in windows that may change their number when a device comes and goes - but still not perfect for this case.  (Linux ttyUSB# and ttyACM# and other designations that are mapped from real ID's have the same set of issues - they increment the number when something comes and goes "just in case", like windows will do)

That good way of finding USB devices, however, isn't used by the JRE the IDE runs on, so....you're on your own.

In other words, the poster above might well have had the serial line come out  - but by then his host machine simply wasn't listening, as I've seen that here and not only in sleep type situations.  Anything that glitches that USB port and most host software loses it - even if it says it still sees it there.

Go Up