Photon sleep mode wakeup on multiple interrupts?

Firmware
21

Hi @mdma, what you propose sounds like the Mercedes and Porsche of the backup SRAM combined. It sounds absolutely perfect! But I am really not too familiar with linker magic, so cannot judge how much effort this is. I was a bit scared about the “end of the year” figure. Without the backup SRAM the deep sleep is much less useful than it could be. That’s why I was hinting at a cheaper solution.

On the other hand, nothing apparently keeps me from accessing the backup SRAM in user code. That diminishes the urgency for me quite a bit :-). So I guess, I like your idea better… I volunteer for testing.

2 Likes
22

I lot of others have wrapped up this concept into a C++ NVRAM class that knows how to check if the locations have been initialized with some magic and has overloaded operators for common things.

1 Like
23

I can do the linker stuff in a few hours. I can squeeze that in sometime when I need a break from the high priority load. It’s the testing that takes the time.

Isn’t there a register in the STM32 that allows us to determine if this is a cold or warm boot so that we don’t need to use a location in backup ram?

24

To my mind, the backup RAM is just more RAM so we should be able to put variables in it just like with regular RAM. This will also make it accessible to everyone, and not just advanced coders. The system can take care of the common housekeeping tasks like setting initial values on cold reset, so the application just has to declare their variables just like normal but with a special modifier.

25

I can do the linker stuff in a few hours.

Great, that's the stuff which I always keep away from :smile:.

Isn't there a register in the STM32 that allows us to determine if this is a cold or warm boot so that we don't need to use a location in backup ram?

Yes:

The SBF status flag in the PWR power control/status register (PWR_CSR) indicates that the MCU was in Standby mode.

But of course that would require initialization of all SRAM at reset time. Probably not too much of a burden given the size, the speed of the CPU - and the time it takes for a full reset, anyway.

1 Like
26

Thanks for the info! I have everything I need to throw together something next week.

Totally, the ram initialization will be very quick - it only initializes the varaibles that are used.

That got me thinking, how about a dynamic heap in backup RAM? I'm not sure how to do that right now, so we'll leave that out of the MVP.

2 Likes
27

Wow, I am impressed...

28

Hey gang, because you’re all so truly awesome I spent part of my weekend throwing this together. You’ll find the implementation in this PR along with a description of how to write code to use the backup RAM - https://github.com/spark/firmware/pull/606

Take 'em for a spin and enjoy persistent variables during sleep! :smile:

6 Likes
29

Wow, amazing! Works like a charm for me, great Work! And the interface is awesome. That’s making the deep sleep so much more useful and natural to work with.

One minor point: Maybe the “System.featureEnabled(FEATURE_WARM_STATE);” should be something else. That feels a bit odd. Or was that just for testing purposes, not the final interface proposal?

30

It’s called FEATURE_WARM_START - it’s just a flag which we can use to check if the system was warm booted or not. What would be the alternative? We can wrap it up in another system method, like

System.warmStart()

or similar. Let me know what you had in mind.

31

It’s not too important. I just felt that the fact that it is in a certain state is not a feature.

I would probably add a

System.isWarmStart()

call. Or the one you proposed, that’s personal style or taste.

To be clear: I very much like the addition of the System.enableFeature(…) and System.featureEnabled(…). That will simplify adding similar things. Just for checking the status of the system it feels odd.

32

Sure, I agree, we’ll probably change this before release. But to my mind there’s not really a distinction between features and states, at least in the low level. But we will distinguish at the API level so it’s clear for users.

1 Like
33

Sounds great. Thanks for the very fast addition. And btw: I sort of understand the linker magic, now :smile:. Nice side effect for me…

1 Like
34

Very impressive, and much appreciated @mdma!

1 Like
35

@mdma Hey your Persistent Variable maintained through a deep sleep & wake up code looks great. Did this make it into the latest 0.4.7 Photon / P1 Firmware? Or does it have to be added manually for now to be used?

36

It’s in!

1 Like
37

@Stevie Sweet!

I’m wanting to use it to store variables in Persistent memory so when I put the Photon into deep sleep and then wake up again the data is still available.

From what I understand I could use the P1 and its external Flash memory to do this or on the Photon I have to use this new feature to do this.

So where exactly can I find more info on how to use this persistent memory on the Photon using the latest firmware?

38

It’s actually in the official documentation. Search for “Backup RAM” in the reference manual located at https://docs.particle.io/reference/firmware/photon/. There is an example for it.

1 Like
39

It's a long time since that statement, but I tried this

void dmy() 
{ 
  digitalWrite(D7, !digitalRead(D7));    
}

void setup() {
  pinMode(D7, OUTPUT);
  attachInterrupt(RI_UC, dmy, FALLING);
  attachInterrupt(D1, dmy, FALLING);
}

void loop() {
  static uint32_t ms = 0;

  if (millis() - ms > 60000) {
    System.sleep(RI_UC, FALLING, 20*60, SLEEP_NETWORK_STANDBY);
    ms = millis();
  }    
}

And unlike the experience from back then

This seems not (anymore) to work. But having multiple wake sources would still be desirable.
Alternatively with a new hardware revision - or at least on the E Series - having the RI_UC for wake on SMS brought out a HW button could be used to wake locally too.

(Unless someone can spot my mistake and point me to it - I'd be grateful :blush:)

40

This is scheduled this sprint, so should be part of 0.8.0, assuming this can be implemented and is supported by the hardware.

2 Likes