wake from sleep with and without debugger

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On my ATSAMD21 Xplained Pro board, I have a relatively simple program that drives the RTC from the OSCULP32K and does the following:

  1. sets the RTC COMPARE register for 1 second in the future, enables COMP interrupts
  2. sleeps
  3. upon waking, toggles the LED
  4. repeat

 

What I observe:

  • Running under the EDBG debugger, the LED toggles once a second.
  • Running without the debugger, the LED doesn't toggle BUT the code is getting called (see below)

 

Question: Any ideas on what could cause this?

 

Details:

  • Hardware is ATSAMD21 Xplained Pro
  • Firmware generated under Atmel START via Atmel Studio 7 (7.0.1931)
  • Clock configuration:
    • OSC8M => GCLK0 (NOT run in standby) => [CPU, USART_0]
    • OSCULP32K => GCLK3 (run in standby) => [EXT IRQ, RTC]

 

What's especially puzzling is that -- as far as I can tell -- the LED toggling code IS getting called: I added a software call counter that gets incremented every time the LED is toggled.  When I start the program NOT under the debugger, the LED doesn't visibly toggle, but if I subsequently attach the debugger to the running process, I can see that the call counter has been incremented from the start.

 

It's almost as if the PORT is getting disconnected and not reconnecting when the processor wakes up (but only when not running under the debugger).  Any thoughts would be appreciated!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Debuggers tend to keep clocks running during sleep ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Debuggers tend to keep clocks running during sleep ...

Understood.  The OSCULP32K runs regardless, so I don't think that's the issue.  But in my configuration, can you see any issue if the OSC8M stops during sleep?  Or is there something that would prevent it from restarting after sleep? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Contrary to my first post, I'm not certain that the code is still running when not in debugger mode: I *thought* I saw that the software call count had increased when I attached the debugger to the running process, but now I haven't been able to replicate or verify that's happening.

 

So this might be a simpler case of the processor not waking from sleep.  I have enabled RTC COUNT interrupts which ought to wake the processor, but I'll triple-check...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks to good old printf() statements, I found the problem, or most of it.  Just BEFORE going to sleep, I'm disabling the USART to save power, which ends up calling:

	((Sercom *)hw)->USART.CTRLA.reg &= ~SERCOM_USART_CTRLA_ENABLE;
	hri_sercomusart_wait_for_sync(hw, SERCOM_USART_SYNCBUSY_SWRST | SERCOM_USART_SYNCBUSY_ENABLE);

... but it never returns from wait_for_sync.  Evidently, some clock that's needed by the USART isn't running.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Um, someone should revoke my coding license. 

 

Put it this way: can you imagine why printf() statements might stop after disabling the USART?  Doh! 

 

Since I can't use the debugger, and I can't use printf() statements, I'll switch to using an LED to tell me what the code is up to.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have refined and re-stated the problem here: SAMD21 fails to wake from STANDBY sleep