G80 execution after deepsleep

NETMF & Gadgeteer
1

I am evaluating the G80 (G80 dev board) for a project that will suit NETMF perfectly if I can reliably test a few aspects, one of them being able to put the chip to sleep and wake up on GPIO and serial data events.

I have pulled this low power example from the docs, but I am having trouble getting it to wake properly:
[ul] the CPU seems to go into DeepSleep fine
after waking, execution continues as expected but stops at the next Thread.Sleep() and halts here for 1 minute regardless of the sleep time entered.
Same behaviour happens when in debug, release or when I boot the board completely disconnected from VS
When connected to a VS session, it seems that any activity on the debug USB port (such as setting a breakpoint anywhere) causes the Sleep call to exit and the the program execution continues until Sleep is called again.
[/ul]

Here is some output from the serial port:
06/01/2011 00:00:01
06/01/2011 00:00:01
06/01/2011 00:00:01
going to sleep
wake up
06/01/2011 00:00:03
06/01/2011 00:01:03
06/01/2011 00:02:03

Is there something I’ve missed?
If the CPU can wakeup from multiple events, is there a way to check which event woke it up? Register access maybe?

Thank for the help - I’m new to NETMF and I have been waiting for a suitable project to come along to use it!


public class Program
    {

        static OutputPort LED1;
        static OutputPort LED2;
        static OutputPort LED3;

        private readonly static InterruptPort _LDR0 = new InterruptPort(G80.Gpio.PE3, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLow);

        static bool EnableLowPower = false;
        static int SleepCountDown = 10;

        public static void Main()
        {

            Debug.Print(Resources.GetString(Resources.StringResources.String1));
            
            LED1 = new OutputPort(GHI.Pins.G80.Gpio.PE14, true);
            LED2 = new OutputPort(GHI.Pins.G80.Gpio.PE13, true);
            LED3 = new OutputPort(GHI.Pins.G80.Gpio.PE11, true);

            LED2.Write(EnableLowPower);

            _LDR0.OnInterrupt += _LDR0_OnInterrupt;


            while (true)
            {
                LED1.Write(!LED1.Read());

                Thread.Sleep(100);

                if(Enable[ul]LowPower)  
                    SleepCountDown--;

                if(SleepCountDown <= 0)
                {
                    tempString = "going to sleep\n";
                    UART.Write(UTF8Encoding.UTF8.GetBytes(tempString), 0, tempString.Length);

                    LED1.Write(false);

                    SleepCountDown = 10;

                    LED3.Write(false);
                    PowerState.WakeupEvents = HardwareEvent.OEMReserved1 ;
                    PowerState.Sleep(SleepLevel.DeepSleep, HardwareEvent.OEMReserved1 );

                    tempString = "wake up\n";
                    UART.Write(UTF8Encoding.UTF8.GetBytes(tempString), 0, tempString.Length);

                    LED3.Write(true);
                    EnableLowPower = false;
                    
                }

            }
        }



        static void _LDR0_OnInterrupt(uint data1, uint data2, DateTime time)
        {
            EnableLowPower = !EnableLowPower;
            LED2.Write(EnableLowPower);

        }
2

@ joshuaberry -

Correct, because your argument was DeepSleep (following your posted code).

[quote]after waking, execution continues as expected but stops at the next Thread.Sleep() and halts here for 1 minute regardless of the sleep time entered.
Same behaviour happens when in debug, release or when I boot the board completely disconnected from VS
[/quote]
You should use :


Instead of:

```cs]PowerState.WakeupEvents = HardwareEvent.OEMReserved1 [/code


So much different in internal system if you changed '|=' to only '=';
[quote]
When connected to a VS session, it seems that any activity on the debug USB port (such as setting a breakpoint anywhere) causes the Sleep call to exit and the the program execution continues until Sleep is called again. [/quote]
Correct, low power should not be run in USB debugger mode.
3

@ joshuaberry - Welcome to the community.

4

Great - thanks! That worked. I try not to blindly copy-and-paste too much when trying example code, but I need to read closer…

I’ve had a read through the ST datasheet about the low-power modes, change clock speed, powering down peripherals etc. Are these type of configurations possible with the SDK, or would I need to experiment with the CPU registers? I see hagster has done some work a while back with the G120, which is along the lines of what I was thinking.

5

What we provide is generic to all processors. The register access is good for specifics.