Just upgraded to 2.2.0.6, full app seems to be working and great that switching between USB Client & MassStorage mode works, but after going to Power.Sleep things are locking up requiring a firmware erase/reload to get going.
This is on a SC20260 with debug over standard COM port.
Has anything changed in the API for Power.Sleep() that could cause this?
I’ve reduced to a minimal example, based on the documentation, which breaks out of the Sleep on button press, but not on the RTC.
using System;
using System.Diagnostics;
using System.Threading;
using GHIElectronics.TinyCLR.Pins;
using GHIElectronics.TinyCLR.Devices.Gpio;
using GHIElectronics.TinyCLR.Devices.Rtc;
using GHIElectronics.TinyCLR.Native;
namespace TinyCLRApplication7
{
internal class Program
{
public const int RLedFader = SC20260.GpioPin.PB1;
private static GpioPin RLed;
static void Main()
{
var rtc = RtcController.GetDefault();
if (rtc.IsValid)
{
Debug.WriteLine("RTC is Valid");
// RTC is good so let's use it
SystemTime.SetTime(rtc.Now);
}
else
{
Debug.WriteLine("RTC is Invalid");
// RTC is not valid. Get user input to set it
// This example will simply set it to January 1st 2023 at 11:11:11
var MyTime = new DateTime(2023, 1, 1, 11, 11, 11);
rtc.Now = MyTime;
SystemTime.SetTime(MyTime);
}
var gpio = GpioController.GetDefault();
RLed = gpio.OpenPin(RLedFader);
RLed.SetDriveMode(GpioPinDriveMode.Output);
RLed.Write(GpioPinValue.Low);
var ldrButton = GpioController.GetDefault().OpenPin(SC20100.GpioPin.PE3);
ldrButton.SetDriveMode(GpioPinDriveMode.InputPullUp);
ldrButton.ValueChanged += ldrButton_ValueChanged;
for (int i = 0; i < 4; i++)
{
Debug.WriteLine("System is going to sleep...");
RLed.Write(GpioPinValue.High);
Power.Sleep(DateTime.Now.AddSeconds(10)); //Will wake up after 10 seconds.
//Power.Sleep();
RLed.Write(GpioPinValue.Low);
Debug.WriteLine("This will print after system wakeup");
Thread.Sleep(1000);
}
}
// An event is needed to activate the interrupts internally
private static void ldrButton_ValueChanged(GpioPin sender, GpioPinValueChangedEventArgs e) { }
}
Hi we have checked your issue, the problem is your code.
You need to update system time by rtc time after wakeup, because after you sleep system time is paused while rtc is still runing. After wakeup, if you still use system time.add 10 seconds without update, rtc time won’t see it because it is the past, that why it doesn’t work for you.
Second, your application does sleep quickly after boot, wakeup and sleep again and never wakeup from second time as explained above, that cause you think crashed, you don’t need to erase firmware, just hold APP button and hit reset that allowes you deploy again.
We tried here with modified your code, seems work perfectly. Make sure the RTC cap is charged as well.
using GHIElectronics.TinyCLR.Devices.Gpio;
using GHIElectronics.TinyCLR.Devices.Rtc;
using GHIElectronics.TinyCLR.Native;
using GHIElectronics.TinyCLR.Pins;
using System;
using System.Collections;
using System.Diagnostics;
using System.Text;
using System.Threading;
namespace Rtc_sleep_crashed
{
internal class Program
{
public const int RLedFader = SC20260.GpioPin.PH11;
private static GpioPin RLed;
static void Main()
{
var rtc = RtcController.GetDefault();
if (rtc.IsValid)
{
Debug.WriteLine("RTC is Valid");
// RTC is good so let's use it
SystemTime.SetTime(rtc.Now);
}
else
{
Debug.WriteLine("RTC is Invalid");
// RTC is not valid. Get user input to set it
// This example will simply set it to January 1st 2023 at 11:11:11
var MyTime = new DateTime(2023, 1, 1, 11, 11, 11);
rtc.Now = MyTime;
SystemTime.SetTime(MyTime);
}
var gpio = GpioController.GetDefault();
RLed = gpio.OpenPin(RLedFader);
RLed.SetDriveMode(GpioPinDriveMode.Output);
RLed.Write(GpioPinValue.Low);
var ldrButton = GpioController.GetDefault().OpenPin(SC20100.GpioPin.PE3);
ldrButton.SetDriveMode(GpioPinDriveMode.InputPullUp);
ldrButton.ValueChanged += ldrButton_ValueChanged;
RLed.Write(GpioPinValue.High);
while (ldrButton.Read() == GpioPinValue.High) ;
Thread.Sleep(1000);
do_sleep:
Debug.WriteLine("System is going to sleep...");
RLed.Write(GpioPinValue.Low);
SystemTime.SetTime(rtc.Now);
Power.Sleep(DateTime.Now.AddSeconds(10)); //Will wake up after 10 seconds.
while (true)
{
RLed.Write(GpioPinValue.Low);
Debug.WriteLine("This will print after system wakeup");
Thread.Sleep(1000);
RLed.Write(GpioPinValue.High);
Thread.Sleep(1000);
if (ldrButton.Read() == GpioPinValue.Low)
{
while (ldrButton.Read() == GpioPinValue.Low) ;
goto do_sleep;
}
}
}
// An event is needed to activate the interrupts internally
private static void ldrButton_ValueChanged(GpioPin sender, GpioPinValueChangedEventArgs e) { }
}
}
Hi Dat,
Thanks for your quick response.
I’ve just tried using your modified code, but it still doesn’t wake unless the button is pressed
I get
This will print after system wakeup
This will print after system wakeup
This will print after system wakeup
This will print after system wakeup
System is going to sleep...
And then nothing unless I press the button again.
RTC is powered from battery and is valid.
Same hardware works using the 2.2.0.5 firmware, so I don’t think that is the problem.
I basically recompiled our main app for 2.2.0.6, and everything worked except for this, (the Sleep code in the main app does reset the RTC after waking), I then tried to make a minimal example based on the documentation, which doesn’t reset the RTC.
I’m going to be away for a couple of days, I can try again on another board once I get back just in case it is a specific hardware issue, but it seems unlikely.
And let the board runs without debug attached, look at the led to see their state. The debugger is disconnected after enter sleep or hibernation and no reconnect then, so nothing print out.
Yes, that’s why I added the LED output. I’ve also attached the COM port to TeraTerm and TinyCLR Config to watch the debug messages when debugger isn’t attached.
I’m wondering if this could be a hardware issue? My board is identical to the G120 based version which has many running successfully in the field, using the SC20 as a drop-in replacement as advertised. The only changes were to the UART port used for debugging, and I think one GPIO due to interrupt requirement, and then 3 resistors needed to be added as pullups due to the difference in startup configuration. Even the solder stencil is identical.
You will recall I had problems with the RTC wakeup on the SC20 version and firmware 2.2.0.5, with wakeup inconsistent depending on how long it had slept for. To me this sounds like a floating line issue of some sort. As we now seem to be seeing different behaviour on our boards (yours and mine) running the same software on firmware 2.2.0.6, it points in the same direction. Is it possible there are still more changes required for a “drop-in” replacement, such a a line needing to be tied to ground or a capacitor with the SC20 that wasn’t needed on the G120, or perhaps some other component value issue needing adjustment?
I’m back and have done some more testing, as follows:
Firmware and libs 2.2.0.6.
I installed your exact code, cut & paste.
It goes to sleep, but never wakes on timer, only on button-press. Quite repeatable.
Built a new project using the 2.2.0.5 libs, still your exact code.
Loaded it onto the same hardware, still with 2.2.0.6 firmware. It actually installed without complaining about mismatch, which surprised me.
Result was exactly the same. Sleep would not wake unless button pressed.
Used TinyCLR Config to install the previous 2.2.0.5 firmware.
Kept the same app as in test 2, built using the 2.2.0.5 nuget/libs
NOW it works! Goes to sleep,wakes up after 10 seconds
Repeatable, if I long-press the button so it goes to sleep, it wakes after 10 seconds
So this is definitely some change introduced in the 2.2.0.6 firmware.
If it works on your hardware and not on mine I’m happy to send you my schematic for review. As mentioned previously I relied on the GHI documentation saying the new board is a drop-in replacement for the G120, and have already had to make one alteration as that was not quite correct. Could be a component value needs tweaking, or a line needs to be tied low or high?
Exactly, there must be a hardware difference somewhere with an unexpected side-effect.
Your dev boards use a lot of things (LCD display, USB host, etc) that ours don’t, which why I was thinking perhaps a floating pin?
We are linked to use the COM port for debugging, if that could make a difference?
I have a couple of our first run of SC20 based boards (the ones with the patched in pull-ups) here for testing, all the second run ones are out in the field, mostly in Iceland. I have a bunch of SC20 modules ready to go into boards once we get this issue sorted out.
Apart from that the only GHI SitCore based board I have is a Fez Flea, and that is so small I have’t been able to find it!
I’ve emailed you the schematic of our board, and ordered a Fez Portal from Digikey, that being the closest to our board. They typically arrive in less than a week.
I’m expecting code on the Portal to behave in the same way as in your tests though, so not sure how much that will tell us.
Knowing the changes between 2.2.0.5 and 2.2.0.6 in code areas related to RTC and Power.Sleep should help to clue you in on what hardware settings could let it work on the older build but not on the newer though?
The main project uses “Extend Heap”, but not the test projects we are using to debug this problem, and the setting was cleared when we uploaded the newer firmware.
Interesting, I had the problem with one of my two (supposedly identical) development boards, but not on the other, or on the Fez Portal I bought for testing.
I put it down to a hardware fault on one of my modules, but if you are seeing it too there may be more to it. Next question, hardware (say a batch with a faulty part) or software (configuration, a setting not being cleared, etc)?
I’ve put an update package with the new firmware and app up on our distribution site, haven’t heard anything back fromour users yet. They generally take a while to install updates though…
I think it’s a problem with FW 2.2.0.6X, with previous versions waking up from RTC worked. Even now when I go back to older FW with the same HW, wake up from RTC works. And the problem occurs for me with or without SDRAM.
Yes the issue occurs in both .61 and .60 versions. Although in version .61 the “Fixed wakeup issue when enable external RAM” issue was supposedly removed.