Skip to content

[Observation] SLEEP_DEEP no longer resets millis to zero in v2.1 of the core #410

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
PaulZC opened this issue Jul 5, 2021 · 1 comment
Closed

Comments

@PaulZC
Copy link
Contributor

PaulZC commented Jul 5, 2021

This is just an observation, I'm not looking for it to be fixed...

On OpenLog_Artemis, using v1.2 of the core, we could use millis to tell how long the Artemis had been awake since the last SLEEP_DEEP because millis was reset to zero at each sleep. In v2.1, that is no longer true...

Using the code below on a RedBoard Artemis ATP, here's what you get using v1.2 of the core:

image

millis gets reset to zero at each SLEEP_DEEP.

Here's what we get using v2.1:

image

Note how millis:

  • does not get reset to zero
  • increments after 2-4 cycles
  • when it does increment, it increments by 1431656 milliseconds - even though the sleep was only ~1 second!

Recommendation: don't trust millis after a SLEEP_DEEP !

Cheers,
Paul

Code to reproduce:

extern "C" void am_stimer_cmpr6_isr(void)
{
  uint32_t ui32Status = am_hal_stimer_int_status_get(false);
  if (ui32Status & AM_HAL_STIMER_INT_COMPAREG)
  {
    am_hal_stimer_int_clear(AM_HAL_STIMER_INT_COMPAREG);
  }
}

void setup() {
  Serial.begin(115200);
  Serial.println(F("Apollo3: millis after deep sleep test"));
  Serial.flush();
}

void loop() {

  //We use counter/timer 6 to cause us to wake up from sleep but 0 to 7 are available
  //CT 7 is used for Software Serial. All CTs are used for Servo.
  am_hal_stimer_int_clear(AM_HAL_STIMER_INT_COMPAREG);  //Clear CT6
  am_hal_stimer_int_enable(AM_HAL_STIMER_INT_COMPAREG); //Enable C/T G=6

  //Use the lower power 32kHz clock. Use it to run CT6 as well.
  am_hal_stimer_config(AM_HAL_STIMER_CFG_CLEAR | AM_HAL_STIMER_CFG_FREEZE);
  am_hal_stimer_config(AM_HAL_STIMER_XTAL_32KHZ | AM_HAL_STIMER_CFG_COMPARE_G_ENABLE);

  //Setup interrupt to trigger when the number of ms have elapsed
  am_hal_stimer_compare_delta_set(6, 32768); // Sleep for 32768 clock ticks = 1 second at 32768Hz

  //Power down cache, flash, SRAM
  am_hal_pwrctrl_memory_deepsleep_powerdown(AM_HAL_PWRCTRL_MEM_ALL); // Power down all flash and cache
  am_hal_pwrctrl_memory_deepsleep_retain(AM_HAL_PWRCTRL_MEM_SRAM_384K); // Retain all SRAM

  //Enable the timer interrupt in the NVIC.
  NVIC_EnableIRQ(STIMER_CMPR6_IRQn);

  //Deep Sleep
  am_hal_sysctrl_sleep(AM_HAL_SYSCTRL_SLEEP_DEEP);

  //Turn off interrupt
  NVIC_DisableIRQ(STIMER_CMPR6_IRQn);
  am_hal_stimer_int_disable(AM_HAL_STIMER_INT_COMPAREG); //Disable C/T G=6

  // Power up SRAM, turn on entire Flash
  am_hal_pwrctrl_memory_deepsleep_powerdown(AM_HAL_PWRCTRL_MEM_MAX);

  //Go back to using the main clock
  am_hal_stimer_config(AM_HAL_STIMER_CFG_CLEAR | AM_HAL_STIMER_CFG_FREEZE);
  am_hal_stimer_config(AM_HAL_STIMER_HFRC_3MHZ);

  Serial.print(F("Millis: "));
  Serial.println(millis());
  Serial.flush();
}
@Wenn0101
Copy link
Contributor

Closing this issue.

As noted this is different from the v1 core, but I don't know if it is an "issue" that needs to be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants