RTC not waking from Sleep in 2.2.0.6

TinyCLR OS
21

We need to know the code or hardware to reproduce. So far we could not reproduce on FEZ Portal with 2.2.0.6100.

22

It will be some arithmetic issue ;-). I’m testing on SCM20260D Dev.

Try the following, everything works:

RtcController.GetDefault().Now = new DateTime(2000, 1, 1);

Now try this, today time, the issue occurs:

RtcController.GetDefault().Now = new DateTime(2023, 10, 17, 13, 20, 15);

Wake up for example 4 seconds:

DateTime wakeupTime = RtcController.GetDefault().Now.AddSeconds(4);

The whole code with some ballast:

class Program10
{
    static void Main()
    {
        //RtcController.GetDefault().Now = new DateTime(2000, 1, 1);
        RtcController.GetDefault().Now = new DateTime(2023, 10, 17, 13, 20, 15);
        RtcController.GetDefault().SetChargeMode(BatteryChargeMode.None);

        GpioPin ledDBG = GpioController.GetDefault().OpenPin(SC20260.GpioPin.PH11);

        ledDBG.SetDriveMode(GpioPinDriveMode.Output);
        ledDBG.Write(GpioPinValue.High);
                    
        GpioPin ldr = GpioController.GetDefault().OpenPin(SC20260.GpioPin.PE3);
        ldr.SetDriveMode(GpioPinDriveMode.InputPullUp);
        ldr.ValueChangedEdge = GpioPinEdge.FallingEdge;
        ldr.ValueChanged += (GpioPin sender, GpioPinValueChangedEventArgs e) =>
        {
            Shutdown();
        };
        if (ldr.Read() == GpioPinValue.Low)
        {
            Shutdown();
        }

        Thread.Sleep(1000);

        Power.WakeupEdge = WakeupEdge.Falling;
        DateTime wakeupTime = RtcController.GetDefault().Now.AddSeconds(4);

        Power.Shutdown(false, wakeupTime);
        
        Thread.Sleep(Timeout.Infinite);

        void Shutdown()
        {
            Power.WakeupEdge = WakeupEdge.Falling;
            //Power.Shutdown(false, RtcController.GetDefault().Now.AddHours(24 * 365 * 5));
            Power.Shutdown(false, RtcController.GetDefault().Now.AddSeconds(7 * 24 * 60 * 60 + 10));
            //Power.Shutdown(false, DateTime.MaxValue);

            while (true) ;
        }
    }
}

}

23

@ Majo: With your code we were able to reproduce the issue. Thank
@ C_Born: With Majo code, seem this is firmware issue, because we can reproduce on our devices. But with your special board issue, we are still not able to reproduce yet.

We added this issue and will take a look soon.

RTC not waking from Sleep in 2.2.0.6 · Issue #1328 · ghi-electronics/TinyCLR-Libraries (github.com)

24

@Majo Great catch!

I tested with your two RTC times in our “bad” hardware, and it worked with DateTime(2000, 1, 1) and failed with DateTime(2023, 10, 17, 13, 20, 15), as you describe.

I believe what happened was the “bad” board had been running real code previously and so the RTC was at the current time, and so failed to wake.

The next test board we tried hadn’t been used, and so the RTC was invalid and Dat’s test code set it to his test time, and so it woke correctly.The same occurred with the new Fez Portal we bought for testing.

Looking forward to a fix in (2.2.0.6200 ?) ! :smiley:

25

@Dat_Tran I see you’ve had this flagged as fixed in Github for some time, how are we looking on a release date for 2.2.0.6200?
After running out of G120s we’ve started shipping boards with the SC20 modules, but as we can’t go to sleep without fear of never waking up again our battery life is pretty poor!

26

Yes, the issue RTC not waking from Sleep in 2.2.0.6 · Issue #1328 · ghi-electronics/TinyCLR-Libraries (github.com) is fixed, download 6200 and try it.

27

I mean 6200 is ready to download: Downloads (ghielectronics.com)

28

@Dat_Tran Thanks for that, I must have missed the release announcement over Christmas!

I was pretty happy to get the news of the fix, and pulled a couple of meters out of their shipping box to update. Unfortunately all did not go well, and we experienced some other problems, which I’ll describe in separate posts once I’m able to fully characterise them.

With the RTC sleep problem, we seem to have three possiblities.

  1. The board goes to sleep, it can be woken by a GPIO, or will wake at the correct time, and everything continues to work.
  2. The board goes to sleep, can be woken by a GPIO up until the programmed wake time, but at that time doesn’t wake, and can’t be woken by GPIO either.
  3. It sleeps and GPIOs wake until programmed wake-time, it wakes, but after that there are NOT IMPLEMENTED or NULL REFERENCE low level exceptions when trying to access GPIO or other device level functions, as if things have been de-allocated or garbage collected while it was asleep.

Which of these happens may be related to the RTC time when the sleep was called, I’ll try and do a minimum code example soon.

The way I have it set up now is to have the WatchDog set at 32 seconds, and the Sleep call sleeps for 30 seconds at a time, waking just long enough the pulse the watchdog and print a debug message before sleeping for another 30 seconds. Thus our standard 59 minute sleep will do this 118 times before waking properly and starting peripherals, etc.

The interesting thing is that sometimes it gets through all the short sleeps without a problem, sometimes it locks up on the first one and is pulled out by the Watchdoog, sometimes it gets part way through, no obvious reason behind it. Once I get a minimal test version I might try setting the RTC to different fixed times before the sleep call, to see if there is any pattern to it